Technical guide

How CAN Bus Load Is Estimated

Understand Classical CAN overhead, bit stuffing, identifier formats, and the limits of bus-load estimates.

Capacity is consumed by complete frames

CAN traffic includes arbitration, control, CRC, acknowledgement, delimiters, payload, and intermission. This toolkit models 47 base bits for an 11-bit identifier frame or 67 for a 29-bit identifier frame, then adds eight bits per payload byte.

load % = frame bits × frames/second ÷ bit rate × 100

Bit stuffing makes length data-dependent

CAN inserts a complementary bit after five consecutive equal-polarity bits through the stuffed region. The actual count depends on the transmitted pattern. The calculator therefore reports an unstuffed baseline and a simple planning estimate adding 20% and rounding up; neither should be presented as an exact trace.

Worked example: a 500 kbit/s Classical CAN stream

Scenario and inputs

An 11-bit standard-identifier Classical CAN data frame carries 8 data bytes and is sent 1,000 times per second on a 500 kbit/s bus. This is a theoretical capacity estimate, not a bus-analyzer measurement. The frame-length convention below includes the minimum 3-bit intermission.

Formula and substitution

  1. Unstuffed frame estimate = 47 base bits + (8 bytes × 8 bits/byte) = 111 bits. The 47-bit base includes SOF, arbitration/control, CRC/ACK/EOF fields and the 3-bit intermission used by this calculator.
  2. Unstuffed frame time = 111 bits ÷ 500,000 bit/s = 222 μs.
  3. Unstuffed load = 111 × 1,000 ÷ 500,000 × 100 = 22.2%.
  4. Planning allowance = ceil(111 × 1.20) = 134 bits; conservative time = 134 ÷ 500,000 = 268 μs; conservative load = 134 × 1,000 ÷ 500,000 × 100 = 26.8%.

The 20% figure is this site's deliberately simple planning allowance, not a protocol-defined strict worst-case bound. Actual dynamic stuffing depends on the transmitted bit pattern and applies only to the stuffed portion; retransmissions, error frames, arbitration delay, overload handling, and other traffic are not included. This example is Classical CAN only and does not use CAN FD fields or formulas.

Conditions, limits, and references

Use the baseline only for an early estimate with the stated standard frame and minimum intermission convention. For a detailed schedule, include every message stream and perform priority/response-time analysis. Bosch's CAN Specification 2.0 describes the frame fields, interframe spacing, and bit-stuffing rule; CiA's CAN CC overview confirms the 8-byte Classical CAN data field and 3-bit intermission.

Average load is not latency

High-priority frames win arbitration, and bursts or error recovery can delay low-priority traffic even when average load is below 100%. Select an operating target from message deadlines and worst-case response analysis, not a universal rule of thumb.

Validate the design

Sum every periodic and event-driven stream, include diagnostics and boot traffic, then measure a stressed network with a CAN analyzer. Use a message-level timing analysis for safety-relevant systems.

Open the CAN calculator

Check your source documentation. These equations are useful models, but hardware modes and protocol conditions can add constraints not represented in a general guide.