How to Decode CAN Bus Error Frames and Voltage Readings

by Grid Connect Team

In industrial automation and automotive engineering, knowing that a CAN bus is down is only half the battle. The real work begins when you have to determine why. While basic connectivity tests are a start, true experts look at the electrical signals and protocol responses to find the root cause.

Decoding CAN bus voltages and CAN bus error frames allows you to move past trial-and-error and start performing precision diagnostics. This guide will show you how to interpret the data coming off your multimeter and your analyzer software to get your network back online.

Decoding the Physical Layer: How to Read CAN Bus Voltages

A Controller Area Network is a differential bus. This means it doesn’t rely on a single voltage level but rather the difference in potential between two wires: CAN High (CAN_H) and CAN Low (CAN_L). To decode what is happening on the wire, you must understand the two states of the bus.

1. The Recessive State (Logical 1)

When the bus is idle, both wires sit at the same voltage.

Reading: Both CAN_H and CAN_L should measure approximately 2.5V relative to ground.
Decoding the Data: If your CAN bus multimeter shows exactly 2.5V on both lines, the bus is electrically healthy but quiet, meaning no nodes are currently transmitting data.

2. The Dominant State (Logical 0)

When a node transmits, it drives the wires apart.

Reading: CAN_H rises to ~3.5V, and CAN_L drops to ~1.5V.
Decoding the Data: On a standard multimeter, these spikes happen too fast to see. Instead, you will see an average active voltage. Typically, CAN_H will read 2.7V to 3.0V, and CAN_L will read 2.1V to 2.3V.

Interpreting Abnormal Voltage Readings

If your readings deviate from these norms, the bus is sending you a decoded message about a physical failure:

CAN_H is 0V, CAN_L is 5V: You likely have a wiring swap or a severe short to power.
Both lines are 0V: The network has no power, or both lines are shorted to ground.
Both lines are 12V/24V: A short to the DC power supply has occurred, likely damaging the transceivers.

Decoding Protocol Failures: Understanding CAN Bus Error Frames

When the physical voltages look correct but data isn't flowing, you must look at the CAN bus error frames. In the CAN protocol, nodes don't just fail silently. If a node detects an issue, it broadcasts an error frame, which is a specific bit sequence that tells every other device to ignore the previous message.

How to Identify an Error Frame

Using a tool such as PCAN-View, you will see "Error Frames" appear in your status window. These are generated by a violation of the Bit Stuffing rule. Normally, a CAN frame can never have more than five bits of the same polarity in a row. An error frame intentionally sends six consecutive dominant bits, forcing every node to acknowledge that the bus is in an error state.

Decoding the Node's Internal State

Every CAN controller has an internal "Error Counter." How a node reacts to errors depends on its current state, which you can decode through your diagnostic software:

Error Active: The node is healthy. It can send a dominant error flag that stops all other traffic.
Error Passive: The node has seen too many errors (>127). It can still talk, but it sends recessive error flags, meaning it can no longer stop other nodes from communicating. If a node is in this state, it’s likely the source of your problems.
Bus Off: The node has exceeded 255 errors and has logically disconnected itself to prevent the entire network from crashing.

Troubleshooting Guide: Decoding Common Error Types

When your software reports specific CAN bus error frames, use this guide to decode the technical terminology into a physical fix.

Bit Errors

The Decode: The node sent a "1" but saw a "0" on the wire.
The Fix: This almost always points to a hardware issue. Check for a short circuit between CAN_H and CAN_L, or a failing transceiver that is "stuck" in a dominant state.

Acknowledgement (ACK) Errors

The Decode: A transmitter sent a valid message, but no other node on the network acknowledged it.
The Fix: This occurs if you only have one node powered up, if the baud rates don't match, or if the cable is physically broken between the sender and the rest of the network.

CRC Errors

The Decode: The mathematical checksum at the end of the frame didn't match the data sent.
The Fix: This is usually caused by external electromagnetic interference (EMI). Ensure your CAN twisted-pair cable is shielded and that the shield is grounded at only one end to avoid ground loops.

Form and Stuff Errors

The Decode: A bit appeared where it shouldn't have, or the bit stuffing was incorrect.
The Fix: This is often a sign of signal reflection. When you are diagnosing CAN bus issues of this type, check your termination resistors. You must have exactly 60 ohms across the bus (two 120-ohm resistors).

Using a CAN Bus Multimeter for Decoding

As mentioned in a previous post, you can use a CAN bus multimeter for decoding. To decode a mystery fault, follow this logical progression:

Resistance Check: With power off, measure across CAN_H and CAN_L. If you don't see 60 Ohms, your physical signal will be distorted by reflections, leading to constant CRC and Form errors.
Ground Offset Check: Measure from CAN_L to Ground and CAN_H to Ground. If the ground potential between two nodes is too high (more than 2V difference), the transceivers cannot reliably decode the differential signal.
The "Isolation" Method: If you are seeing constant CAN bus error frames, disconnect nodes one by one. If the error frames disappear when a specific node is removed, you have decoded the source of the noise or the faulty hardware.

Coming Up with a Solution Based on the Diagnosis

Solving a CAN bus failure isn't about luck; it’s about a systematic decoding of the network's health. By following this three-tiered approach, you can isolate whether your problem is electrical, architectural, or logical.

1. Electrical Validation

Before looking at data, use your CAN bus multimeter to verify the physical layer.

The Check: Check the difference between CAN_H and CAN_L
The Decode: If you’re consistently finding 0V during operation, your transceivers aren't driving the bus. If it’s stuck at 2V, you have a short.
The Solution: Correcting physical shorts or ground offsets ensures the pipes can actually carry the signal.

2. Architectural Validation

Reflections and signal noise are the potholes of a CAN network.

The Check: With power off, measure resistance across the data lines.
The Decode: You are looking for exactly 60 Ohms. 120 Ohms means a terminator is missing; 40 Ohms means you have too many.
The Solution: Standardizing your termination ensures that the electrical waves don't bounce back and create ghost bits that trigger CAN bus error frames.

3. Logical Validation

Once the electricity is clean, use a diagnosing CAN bus tool such as the PCAN-USB combined with PCAN View or PCAN Explorer software to monitor the protocol.

The Check: Monitor the Error Counter and the specific types of error frames (CRC vs. ACK).
The Decode: High ACK errors mean the node is shouting into a void (nobody else is on the bus). High CRC errors mean the "language" is being corrupted by outside interference.
The Solution: By identifying the specific error type, you can decide whether to replace a cable (CRC error) or check a node's power supply and baud rate (ACK error).

By mastering both the voltage levels and the error frame logic, you reduce downtime from hours of guessing to minutes of measuring. Whether you’re maintaining a heavy-duty truck or a robotic assembly cell, this dual-layer decoding ensures your modern control systems remain stable, reliable, and understandable.