How to Diagnose a Controller Area Network (CAN)

Apr 29, 2022 9:00:00 AM / by Gary Marrs posted in CAN networks, CAN protocol, CANbus, PCAN


In 1991, the Mercedes-Benz W140 was the first production vehicle to feature a CAN (Controller Area Network) based wiring system. By 2008 almost all passenger cars and light trucks sold in the U.S. used CAN bus networks.



 courtesy of CSS Electronics



Before CAN bus gained popularity, vehicle wiring harnesses could contain miles of copper wire which significantly added to the cost and weight of the vehicle. CAN bus was originally designed to minimize copper wiring in automobiles by multiplexing electrical signals over a simple two wire network. By using a high-speed twisted pair cable, the amount of wire necessary to allow sensors, actuators and controllers to communicate was greatly reduced.

When people talk about CAN, there are really 2 main but distinct areas that make up a CAN bus network.

  • The lower-level CAN bus network
  • The CAN Protocol used to pass messages

The lower-level CAN bus

The lower-level CAN bus is a two-wire, half duplex, high-speed network system. The CAN standard defines the lower-level details (the physical layer) of the CAN bus. The physical layer is responsible for bit timing and synchronization, message framing, arbitration, acknowledgement, error detection and signaling, and fault confinement. 1

There are basically 2 versions of the CAN standard that cover the lower layers, CAN 2.0 and CAN FD.

CAN 2.0 was published in 1991. This specification has two parts (Referred to CAN 2.0A and 2.0B);

  • part A is for the standard format with an 11-bit identifier
  • part B is for the extended format with a 29-bit identifier

The CAN FD protocol was released in 2012 and increases the effective data-rate by allowing longer data fields (up to 64 bytes per frame compared to the 8 bytes of CAN 2.0).

Think of the lower layer of CAN bus as bits transmitted at defined speeds on the wire itself.


The CAN Protocols

While the CAN standard defines the physical layer a higher layer protocol is required to manage the communication messages on the CAN bus. The higher layer protocol handles details such as node addresses, flow control, fragmentation of data messages larger than 8-bytes, and establishment of communication among other things. Think of the higher layer protocol as the way the messages (data) are formatted, transmitted and received.

Currently, there are many higher layer protocols for the CAN bus. The most common ones are listed below:

CANopen - Industrial automation
  • IEC 61375-3-3 (use of CANopen in rail vehicles)
  • DeviceNet Industrial automation
  • EnergyBus - battery–charger communication
  • ISOBUS - Agriculture
  • NMEA 2000 - Marine industry
  • SAE J1939 - In-vehicle network for buses and trucks

All of these CAN protocols communicate over the CAN bus.


CAN Bus Diagnostics

Diagnosing CAN bus problems can be challenging. Even so, with a little practice you don’t have to be highly technical to perform basic diagnostics on a CAN bus network. Grid Connect sells a wide variety of tools from Peak Systems to help analyze and troubleshoot CAN networks.


Troubleshooting a CAN Bus network

Here are some of the most common CAN bus failures: 2

  • Device configuration settings
  • Missing termination resistors
  • CAN Hi and CAN Low wired backwards
  • Damaged CAN port due to lightning or welding

It is possible to manually troubleshoot the lower-level CAN bus. This can be done using a little vigilance and a multimeter to test and verify. All modules on a CAN bus network need four things to function properly: power, ground, a CAN data connection, and a proper device configuration.

Here are some simple things to investigate:

  • Check the CAN Device configuration. Make sure the baud rate of the CAN communications is the same as all other devices on the CAN bus.
  • Check the CAN bus termination resistance. A CAN bus has to be terminated on both ends with a 120-ohm resistor to prevent reflections from interfering with the data transmissions. In some cases, the termination resistor may be located inside the CAN device.
    • Turn Power off
    • Measure resistance between CAN Hi and CAN Low. Should be around 60 ohms.

  • Check the CAN bus voltages and ground connection.
    • Disconnect all CAN devices from the CAN bus except for the device being tested.
    • Power on the CAN device to be tested.
    • Measure voltage between CAN HI and Ground. The voltage should be between 2.5 and 3.0Vdc.
    • Measure voltage between CAN LOW and Ground. The voltage should be between 2.5 and 2.0Vdc

  • Check / Verify ground connection
    • Turn Power off
    • With the meter on the lowest resistance scale, measure the ground wire to earth ground. The meter should read less than the minimum 0.1 ohm that most meters can read.

  • CAN Transceiver Resistance Test – you can test the CAN port on a device to see if it is damaged by measuring resistance to ground. Damage from lightning or transients typically causes a short to ground on one or both CAN lines.
    • To test, disconnect the device (under test) from the CAN bus.
    • Make sure power is off to the CAN device under test.
    • Measure resistance from CAN HI to Ground and from CAN LOW to Ground. The result should be Mega ohms or open. If it is lower than this range, the CAN transceiver is probably faulty.

Troubleshooting the CAN Protocol

For troubleshooting the CAN protocol and communication message issues it gets more complicated. There are software and diagnostic tools that range from free software with basic functionality to expensive tools that provide very detailed data and analysis.

To start out, a simple solution is to use a USB to CAN bus adapter to connect to the bus and Windows based software tool to monitor CAN traffic. In this example, we use the Peak System PCAN-USB adapter with their free Windows software for displaying CAN and CAN FD messages (called PCAN-View). 3

pcan usb diag 2


pcan view1


pcan view2


For this example, we use the following equipment and devices.

  • Laptop running PCAN View (free download)
  • PCAN-USB adapter to connect to and monitor a CAN bus network
  • At least one CAN device talking on a CAN bus Network, in this example we used an Arduino board with a CAN-BUS Shield V2 from Seeed Studios. (Recommended that CAN bus be terminated with 120-ohm resistors on each end).

The PCAN-USB plugs into a USB port on the laptop. You need to download and install the USB driver from Peak. 

One minor limitation of this method is that the data rate of the CAN network must be known and the PCAN-USB has to be configured with this information. The Peak PCAN-Diag 2 can be used to determine the data rate on the CAN bus. (see below for an overview of the PCAN-Diag 2)

To start the connection to the CAN bus, click on the link icon in the top left of the window. 

PCAN view 7

This will bring up the configuration page.


PCAN view 4



To set the CAN bus data rate, click on the dropdown box and select the correct bit rate. In this case, we selected 125 kbps.


PCAN view 5

Then select the OK button. You should start to see packets arriving.


PCAN view 6

Here, we are seeing some packets from CAN ID 0x01. With PCAN-View there is quite a lot of functionality that can assist with monitoring and troubleshooting a CAN Bus. Here are some of its monitoring and diagnostic capabilities:

  • Displays all received CAN messages with ID, Data Length, and data bytes in a list.
  • Data messages or Remote Request frames can be transmitted on the CAN bus. These messages can either be transmitted manually, automatically in fixed time intervals, or as answers to received Remote Request frames.
  • Error Frames on the CAN bus are detected and shown.
  • Contains a Tracer (data logger) that can be used to record and store the data communications on a CAN bus.



download full CAN Diagnostics Guide


Handheld CAN Bus Diagnostics Unit

For more powerful trouble shooting there are hand held units that provide a lot more information that is very helpful when diagnosing a problem on the CAN bus. 


PCAN-Diag2_Catalog2011-1 PCAN-MiniDiag FD_Banner PCAN-Diag-FD_Manual-Title
PCAN DIAG 2 - Handheld Diagnostic Tool

MPN :  IPEH-002069-V2

PCAN MiniDIAG FD - Handheld Diagnostic Tool 

MPN : IPEH-003070

PCAN DIAG FD - Handheld Diagnostic Tool for CAN FD Networks

MPN : IPEH-003069


An integrated handheld CAN diagnostics unit can provide a wide range of functions to allow investigation of a CAN bus, such as:

  • Auto detection of the CAN bit rate
  • Bus load measurements displayed by a time diagram, including a switchable display of error frames

Diag screen 1

  • The termination resistance measurement even while the system is running. Also measures Voltage for all pins on the CAN Bus (connected to handheld unit)
  • Receives and displays the CAN messages on the network

Diag screen 2

  • Send / transmit either individual messages or entire sequences of them to the network. In addition, the internal memory card allows tracing and playback of the CAN traffic.
  • The integrated two-channel oscilloscope enables visualization of CAN signals.

Diag screen 3


  • The CAN frames can be decoded from the recorded packets to help detect errors in the frame.

One of the biggest benefits of a handheld tool is that it can analyze the CAN bus network at both the lower-level physical layer as well as the protocol level. This saves time and helps to get to the source of the error quickly.



Download PDF version



Download CAN Diagnostics Guide


  1.   Wikipedia,
  2.   CAN BUS Troubleshooting Guide (with Video), Enovation Controls.
  3.   Peak System PCAN-View software
  4.   Peak System PCAN-USB module,
Read More

CAN FD – The Next Big (Fast) Thing

Oct 26, 2015 8:52:30 AM / by Brittney Borowicz posted in arbitration process, automotive, automotive industry, CAN, CAN 2.0, CAN FD, CAN protocol, CANbus, CANopen, Classic CAN, DeviceNet, engines, factory automation, Fast Data, Flexible Data, General, Germany, hardware, in-vehicle communication, internal machine communication, ISO 11898, J1939, PEAK, Peak-System, Products, protocol, software, Technical Support, vehicle, White Papers



The CAN protocol (ISO 11898) has remained relatively unchanged since it was introduced in 1993 as CAN 2.0 A/B. In the last few years, CAN FD (for Flexible Data rate or “Fast Data” as we like to call it) was introduced and is now defined as ISO 11898-1. The CAN FD protocol is backward compatible. Any CAN FD device can understand CAN 2.0 frames (now known as “Classic CAN”). However, the opposite is not true. If a Classic CAN node encounters a CAN FD frame, it will destroy the packet with an error frame.

Classic CAN has been the de facto standard for in-vehicle communication for the automotive industry since the 90s. CAN has also been used as the lower-layer protocol for a number of other “higher-layer” protocols such as CANopen, J1939, DeviceNet and more. This has resulted in the CAN protocol being widely deployed in factory automation, heavy-duty vehicles and engines, and internal machine communication – such as elevators and medical equipment.

The automotive industry is the main driver behind the adaptation of CAN FD. The complexity of software in automobiles has increased over time, and the number of systems that communicate with each other via CAN bus has also increased. Between 1990 and 2000, the number of in-vehicle bus nodes went from about 10 nodes to more than 40 systems. This trend has continued into the 21st century, as in-vehicle communication demands have put further and further strain on vehicle design, causing an ever increasing number of CAN bus networks in the vehicle. Through the adaption of CAN FD, in-vehicle communication architectures will be able to accomplish more with less!

The basic idea of CAN FD is to speed up the bit rate during the “payload” part of a CAN frame. In this way up to 8 times more payload (64 bytes vs. 8 bytes) can be delivered in the same amount of time. So the beginning and end of the frame are transmitted at “Classic CAN” speeds, and the CAN transceivers just flip a switch and speed up for the payload part of the message. When you consider that the rest of the frame is at slower speeds, the overall increase in speed is about 6 times faster. Not all messages need 64 bytes of data of course, so the diagram below shows how a CAN FD message of 8 bits and 64 bytes compare to a Classic CAN frame of 8 bytes.


The question is why didn’t CAN FD just speed up the whole message? Why just the payload? The answer requires a slightly deeper understanding of the CAN protocol. A basic element of the CAN protocol is its arbitration process. When two nodes transmit at the same instant, their messages “collide” and they must both “back-off” and retransmit at different intervals according to priority. Another basic element of the protocol is that nodes on a bus must be reached within a “bit time” during this arbitration. The notion of a “bit time” has implications on the length of the bus – the actual cable, since electrical signals have a finite propagation speed. Therefore, a CAN bus running with 1 Mbit/s has a maximum length of 40 meters by rule of thumb. If CAN FD sped up the whole bus, the higher bit rates would shorten the bus cable to unsuitable lengths.

The automotive industry is readying itself to start initial implementation of CAN FD in its designs for 2016, with vehicles hitting the market with CAN FD hardware the following year. As this industry ramps up and more and more ECU’s (in-vehicle “Electronic Control Units) and sensors and actuators also adapt CAN FD, more companies with ties to automotive (suppliers, service companies, dealers, OEMs, etc.) will need CAN FD-capable interfaces. Luckily, Peak-System from Germany is one of the first companies to introduce a CAN-FD interface, (PCAN-USB-FD), and it has been fully tested to the standard. Additional hardware and software supporting CAN FD are on the way. Grid Connect has Peak’s CAN FD products in stock now – we are ready for the next big (fast) thing!

> Click here to download the complete CAN FD White Paper

Read More

Subscribe to Email Updates

Lists by Topic

see all