CAN Bus Analyzer Workbench

Inspect Classical CAN arbitration, frame fields, ACK/error behavior, and bus-load tradeoffs.

Interactive CAN bus analyzer workbench showing dominant/recessive arbitration, standard and extended identifiers, data frame structure, bit stuffing, CRC and ACK checks, error frames, and approximate bus-load calculations.

Classical CAN Analyzer Arbitration Error Handling

CAN Bus Analyzer Workbench

Watch two nodes contend for a shared CAN bus, inspect the exact arbitration bits that decide priority, and connect frame fields, CRC/ACK behavior, bit stuffing, and bus load to what a real protocol analyzer reports.

Winning frame Brake ECU 0x080

Bus state Dominant arbitration

Wire time 0.23 ms

Estimated load 12%

1

Find the priority

Lower CAN identifiers have higher priority because dominant 0 bits overwrite recessive 1 bits during arbitration.

2

Read the frame

The analyzer separates SOF, arbitration, control/DLC, data, CRC, ACK, EOF, and intermission so the wire is not a mystery.

3

Spot faults

Inject CRC, ACK, or stuff errors to see why a node aborts a frame, sends an error flag, and retries later.

4

Judge bus load

Change payload, bitrate, and frame rate to estimate how much airtime the message consumes on a shared bus.

Brake message wins arbitration

A safety-critical brake frame starts at the same time as a body-control frame. The lower identifier keeps transmitting; the losing node sees a dominant bit while sending recessive and backs off without corrupting the winning message.

Healthy bus

Transmitter A Brake ECU 0x080 Data frame, 4 byte payload

Transmitter B Body Control 0x420 Backs off after arbitration

Receiver Instrument Cluster ACK slot Drives ACK dominant when the frame checks out.

Analyzer Protocol Tap 500 kbit/s Decodes fields and flags errors.

CAN_H

dominant

CAN_L

dominant

Arbitration Bit Inspector

Decision bit Bit 1

Dominant rule 0 beats 1

Arbitration loss Body Control

Non-destructive arbitration

The lower identifier keeps the bus because its dominant bit appears while the competing node is sending recessive. The losing node stops and retries after the bus becomes idle.

Decoded Frame and Trace

Frame format Standard 11-bit

Payload 4 bytes

Stuff estimate +12 bits

Control the capture

Choose a scenario, step through frame phases, then change bitrate, payload, frame rate, and injected faults.

Scenario

Bitrate 125 kbit/s 250 kbit/s 500 kbit/s 1 Mbit/s

Payload bytes:

4

Classical CAN data frames carry 0 to 8 data bytes. CAN FD is intentionally outside this workbench.

Frame rate:

600

frames/s

Injected fault None: clean frame CRC error: receiver rejects frame ACK error: no receiver acknowledges Stuff error: six identical bits Bus-off: transmitter is isolated

CAN Quick Reference

Use these segments to decode what the analyzer is showing without hunting through a protocol manual.

ID

Identifier is priority

CAN arbitration compares the identifier bit by bit. Numerically lower IDs usually win because they place dominant 0 bits earlier.

0/1

Dominant beats recessive

Dominant 0 overwrites recessive 1 on the shared bus. A transmitter that sends 1 but reads 0 loses arbitration.

11

Standard frame

Classical base format uses an 11-bit identifier and a data field from 0 to 8 bytes.

29

Extended frame

Extended format adds identifier extension bits for a 29-bit ID. With the same base ID, a standard data frame wins over an extended frame.

DLC

Payload length

The DLC announces how many data bytes follow. In Classical CAN this workbench limits payload to 0 through 8 bytes.

CRC

Frame integrity

Receivers check the CRC sequence before acknowledging. A bad CRC causes an error frame and retransmission later.

ACK

Receiver confirms

The transmitter sends recessive in the ACK slot. Any receiver that accepts the frame drives the slot dominant.

LOAD

Airtime matters

Long payloads, low bitrate, and high message rate consume bus capacity and increase latency for lower-priority traffic.

Learning Support

These checks turn the animation into a self-study tool for students who have not used a hardware CAN analyzer before.

What to watch first

• Look for the first arbitration bit where the two frames differ.
• The node that tried to send recessive but read dominant stops transmitting.
• The winning frame continues without a collision-recovery delay.

Common beginner trap

• CAN IDs are message priorities, not destination addresses.
• Nodes decide whether a message matters by filtering IDs.
• Many receivers can accept the same broadcast frame.

Error interpretation

• CRC and stuff errors indicate a bad frame on the wire.
• An ACK error often means no receiver accepted the frame.
• Repeated transmit errors can push a node toward bus-off.

Design question

• Give safety and control loops lower IDs than comfort telemetry.
• Keep bus load below the point where low-priority messages wait too long.
• Use separate buses or gateways when traffic classes conflict.

Technical Accuracy Notes

This workbench models Classical CAN/CAN CC behavior for teaching. The frame-time readout is an analyzer-style estimate: fixed frame fields plus payload bits plus an approximate stuffing allowance. It is suitable for comparing scenarios, not for replacing bit-exact timing analysis.

The terminology follows the ISO 11898 CAN family and CAN in Automation descriptions of Classical CAN, CAN FD, and CAN XL, plus the Bosch CAN specification for arbitration, frame fields, error handling, and bit stuffing. Sources: CAN in Automation CAN CC, CAN in Automation ISO 11898 series overview, and Bosch CAN Protocols.