My CAN Device is Failing to Communicate or is Inconsistent at High Baud Rates

Updated Apr 18, 2024

Reported In


CAN industrial communications devices

Issue Details

My CAN device can communicate properly at low baud rates, but when I increase the baud rate it only communicates intermittently or fails to communicate altogether.

I am receiving CAN errors: Form Error, CRC Error, Bit Error or Stuff Error.


These errors may be a result of improper CAN termination.

This article discusses proper termination for each form of CAN communication.

Additional Information

The CAN specification (ISO 11898) requires proper termination of the CAN bus at each of the two extreme ends of the CAN network, usually at the controller node and the "farthest device" node. It is sufficient to place a 120-ohm resistor between CAN_H and CAN_L, which are pins 2 and 7 on NI-CAN DB-9 interfaces. See Related Link below entitled: Proper Termination for NI-CAN Hardware for a more precise treatment of how to terminate a CAN network. Without proper termination, attempting communication may yield one of the following undesired behaviors:
    • Successful communication at low baud rates, but failure at high baud rates (the baud rate at which failure will occur will depend on a number of factors including the length of the CAN network, the data associated with the frame - this can change the highest frequency component of a given transmission, electromagnetic interference near the network, and more). One test summarized in the following table illustrates this:
      CAN Baud Rate - Termination Test
      Baud RateCable Properly Terminated?Port to Port Communication Successful?

      Notice that communication is always successful with proper termination, but at a low baud rate of 40K was successful despite not using termination and therefore not complying with the CAN ISO 11898 specification.
    • CAN Errors - Form Error, CRC Error, Bit Error, Stuff Error, and some others can result from improper termination. For more information on CAN errors, see the NI-XNET Product Documentation: Error Detection linked in the Related Links section below. 
    An example of a CAN error that can be explained by improper termination (and is a defined error condition based on the CAN ISO 11898 specification) is a Stuff Error. A Stuff Error occurs whenever 6 consecutive bits of equal value are detected on the bus. Whenever a transmitting device detects 5 consecutive bits of equal value, it automatically inserts a complemented bit into the transmitted bit stream. This stuff bit is detected and automatically removed by all receiving devices. 

    This bit stuffing scheme is used to guarantee enough edges in the bit stream to maintain synchronization within a frame. If a listening device detects 6 bits of the same value, then it must have been the case that synchronization was lost and what was received was NOT what was sent. This is precisely what can happen with improper termination. Some bits in the frame are transmitted and received correctly, but the entire frame (and the integrity of all the bits in that frame) is not maintained and received at the listening CAN interface. 

    The reason for this is that a CAN network, in general, defines a transmission line. Transmission line theory dictates that sufficiently high-frequency components will not be transmitted successfully along the length of a given transmission line without proper termination at the receiving terminal. This termination is often referred to as a matching network, where termination is often chosen for maximum power transfer to the load (the receiving CAN interface in this case) by using the complex conjugate of the impedance seen looking back into the network (in practice, many applications use slightly different termination to account for noise performance and other considerations). 

    The good news is, that the CAN ISO 11898 specification has been made such that proper termination on an entire CAN network (that indeed complies with this CAN standard) is as simple as placing two 120-ohm resistors at the "extreme ends" of the network.