Quote from Wilfried Voss on July 13, 2026, 5:28 pm

When engineers troubleshoot a CAN network, they usually focus on the messages flowing across the bus. They check identifiers, decode data bytes, and verify timing. While that is certainly important, there is another source of diagnostic information that is often overlooked—and in many cases, it provides the fastest path to the actual problem.

The newest release of our JCOM1939 Monitor Software now displays the CAN controller's error status and error counters in real time.

This seemingly small addition can dramatically reduce troubleshooting time because the CAN controller continuously evaluates the health of the network. If something is wrong with the wiring, termination, signal quality, or another node on the bus, the controller knows long before you can spot the problem by looking at CAN messages.

Instead of spending hours guessing where the fault might be, the controller's error status immediately tells you that a problem exists.

---

The CAN Controller Is Constantly Monitoring the Network

Every CAN controller implements sophisticated error detection mechanisms defined by the CAN protocol.

Unlike many communication protocols, CAN does not simply transmit data and hope for the best. Every transmitted bit is monitored and verified.

The controller continuously checks for:

• Bit errors
• Stuff errors
• CRC errors
• Form errors
• Acknowledgment (ACK) errors

Whenever one of these errors occurs, the controller updates its internal error counters.

These counters provide a real-time indication of the overall health of the CAN network.

Think of them as the controller's "stress level." A healthy network keeps the counters at zero. A faulty network causes them to increase.

---

Understanding the Two Error Counters

Every CAN controller maintains two independent counters:

• Transmit Error Counter (TEC)
• Receive Error Counter (REC)

Each counter serves a different purpose.

Transmit Error Counter (TEC)

The TEC increases whenever the controller encounters errors while transmitting a message.

Typical reasons include:

• Missing bus termination
• Short circuits
• Open CAN_H or CAN_L wires
• Incorrect baud rate
• No acknowledgment from another node
• Severe bus disturbances

If the network is disconnected, for example, every transmitted frame will eventually generate an ACK error because no other controller acknowledges the message.

The TEC rapidly increases.

---

Receive Error Counter (REC)

The Receive Error Counter increases whenever errors are detected while receiving frames.

This often indicates:

• Electrical noise
• Poor wiring
• Reflections caused by missing termination
• A malfunctioning node transmitting corrupted frames

Unlike the TEC, the REC generally increases more slowly because receive errors tend to be less severe than repeated transmission failures.

---

The Counters Also Recover

One of the most interesting characteristics of CAN is that the counters do not only increase—they also decrease again when communication returns to normal.

Each successfully transmitted or received frame reduces the accumulated error count.

This makes the counters an excellent indicator of intermittent problems.

For example:

A loose connector may cause occasional bursts of errors.

Instead of permanently remaining at a high value, the counters may briefly increase before gradually returning toward zero.

Observing this behavior immediately tells the engineer that the network suffers from an intermittent physical problem rather than a permanent failure.

---

CAN Controller Error States

The CAN specification defines several operating states that depend on the values of the error counters.

Error Active

This is the normal operating condition.

• TEC below 128
• REC below 128

The controller participates fully in bus communication and actively reports errors when they occur.

This is exactly where every controller should remain during normal operation.

---

Error Passive

When either counter reaches 128, the controller enters the Error Passive state.

At this point, the controller has experienced a significant number of communication problems.

It continues operating but behaves more cautiously to reduce disruption of the network.

An Error Passive controller can still transmit and receive messages, but persistent communication errors should now be investigated.

If your network reaches this state, something is already wrong.

---

Bus Off

If the Transmit Error Counter reaches 256, the controller enters the Bus Off state.

At this point, the controller completely disconnects itself from the CAN network.

This behavior protects the remaining nodes from a faulty controller that might otherwise continuously disrupt communication.

Typical causes include:

• Wrong baud rate
• Broken wiring
• Missing termination
• Defective transceiver
• Severe electrical interference

A Bus Off condition should never be ignored.

It indicates a serious network problem requiring immediate attention.

---

What Causes Error Counters to Increase?

Many physical network problems immediately appear in the error counters, including:

• Missing 120 Ω termination resistors
• Incorrect wiring
• Reversed CAN_H and CAN_L
• Loose connectors
• Damaged cables
• Excessive cable length
• Incorrect baud rate
• Defective CAN transceivers
• Electrical interference
• Rogue or malfunctioning CAN controllers

In many cases, simply watching the counters while disconnecting or reconnecting individual nodes quickly identifies the faulty device.

---

Why This Feature Matters

Most CAN monitoring software focuses entirely on the CAN messages themselves.

That is only part of the picture.

The controller's error status provides information that cannot be obtained by analyzing CAN frames alone.

Consider a network where communication appears normal most of the time.

Occasionally, messages disappear.

Without access to the error counters, you may spend hours examining message timing, arbitration, and data contents.

The error counters, however, immediately reveal whether the controller is experiencing communication errors.

This dramatically narrows the search.

Instead of asking:

"Which message is wrong?"

you begin asking:

"Why is the controller reporting communication errors?"

That is often the right question.

---

Selecting a CAN Interface? Don't Ignore This Capability

Not every CAN interface driver exposes the controller's internal error counters to application software.

Unfortunately, this important diagnostic capability is often overlooked when selecting CAN hardware.

If the driver does not provide access to:

• Transmit Error Counter (TEC)
• Receive Error Counter (REC)
• CAN controller state

your diagnostic software cannot display them, regardless of how capable the application itself may be.

For professional diagnostics, access to these values should be considered an essential requirement—not an optional feature.

When evaluating CAN interfaces, always verify that the driver allows software to read the controller's error counters and error state.

Without them, you are effectively troubleshooting with one eye closed.

---

New in JCOM1939 Monitor

The latest version of the JCOM1939 Monitor Software now displays:

• Current controller state
  • Error Active
  • Error Passive
  • Bus Off

This information is updated continuously, allowing you to observe the condition of the CAN network as it changes.

Whether you are commissioning a new system, diagnosing intermittent wiring problems, evaluating a third-party ECU, or hunting down an elusive communication fault, the CAN controller's error status provides immediate insight into what is happening on the network.

Sometimes the fastest way to diagnose a CAN problem is not by looking at the messages—it is by listening to what the CAN controller is trying to tell you.