CAN bus requires two wires for CAN H and CAN L signals, It is a multi-master serial bus standard for connecting devices known as nodes. Multiple devices can be connected to the bus. The nodes can be a simple I/O device or a complex embedded computer. The node may be a gateway to other standard buses like Ethernet or USB.
CAN bus physical layer is specified in ISO 11898-2:2003. It defines voltage, current and the number of conductors. The exact voltages for a logical 0 or 1 depend on the physical layer used, typical values are given below. Optical isolation is sometimes used to provide protection from overvoltage transients between the CAN bus cable network and the nodes connected to it. Isolation also eliminates ground loops in the network, reduces signal distortion and errors, and provides protection from voltage/ground mismatches.
CAN bus must be correctly terminated. The high speed bus is terminated into a 100 ohm load and the low speed bus into a 120 ohm load. The CAN bus has no clock line; data is transmitted in an asynchronous format.
Logic 1 is called the Idle, or recessive state, is typically biased at +2.5 V for both CAN H and CAN L.
Logic 0 is called the active, or dominant state, is typically driven down to +1.5 V for CAN L and up +3.5 V for CAN H.
Data is transferred in blocks called frames. Each message starts with an ID identification. The ID must be unique for each node on any defined network otherwise errors will occur due to transmission beyond the end of the arbitration field.
All nodes on a CAN network must operate at the same nominal bit rate; since no separate clock line is provided a means of synchronizing the nodes is necessary. Synchronization is important during arbitration since the nodes in arbitration must be able to see both their transmitted data and the other nodes transmitted data at the same time. Synchronization starts with the first recessive to dominant transition after a period of bus idle, this is the start bit.
To monitor and find faults on a CAN bus it is important to have an oscilloscope with deep memory to capture a large time window with several frames of data. For example this screenshot shows a 50 ms window of acquired data. The instrument can then process the acquired waveform and zoom in to analyze the data packets. It is recommended the instrument has a bandwidth of ten times the CAN baud rate, to analyze rise times and any fault conditions. PicoScope will give a warning on the screen if the sample rate is set too low to correctly decode and analyze the acquired data.
Errors can occur due to inductors, coils and power devices which can cause large voltage spikes, noise and ringing. An increasing number of embedded computers and devices are being added to automobile CAN buses and as more nodes are added the available bus time becomes more occupied. When the traffic reaches around 40% of the bus time errors can start to occur. At this point an oscilloscope may be required to debug the network.
The first step is to acquire the CAN data signal of interest using the PicoScope.
Connect Channel A probe to the CAN L signal and the Channel B probe to the CAN H signal.
Open the PicoScope 6 application, turn on channels A and B and set both to Auto. Set the buffer memory to 1 MS and the timebase to 10 ms/div.
Now capture some data then select stop. The display should be similar to the screenshot here.
Select Serial Decoding from the tools menu, click Create, select CAN. Select Channel > Data > A and Configuration Low. PicoScope will automatically calculate the optimum threshold, hysteresis and baud rate but these values can be customized if necessary.
In the display menu tick Graph, untick Table, select format Hex and click OK.
Click Create, select CAN. Select Channel > Data > B, Configuration High, and click OK.
Errors can occur on CAN buses due to inductors, coils and power devices which can cause large spikes, noise and ringing, or a faulty node.
This example displays a captured error condition. A second node on a CAN H line starts randomly transmitting a message and corrupting the data packets. The first packet corrupted in this example is number 508. This can be found by zooming in then turning on the table display. The CRC error is highlighted in red.
You can use the Search controls to look for a CRC Valid field equal to 0 and thus search for bus errors.