Since its emergence in the late 1980s as a burgeoning serial-data protocol for the automotive market, the controller area network (CAN) bus has been the go-to networking standard for vehicles worldwide. The CAN bus enables electronic control units (ECUs) within the vehicle to communicate with various subsystems, such as safety systems, airbags, infotainment systems, and much more.

Modern vehicles can have dozens of ECUs, which appear on the CAN bus as nodes, and each node can communicate with the entire network without complex dedicated wiring. As automotive electronics gained complexity, a variant of the CAN bus, controller area network with flexible data-rate (CAN FD), appeared in 2011 to achieve higher data rates on the bus. In this article, we’ll discuss some of the basics of the CAN bus before delving into some of the fine points of taking measurements and debugging network functionality with an oscilloscope.

CAN bus basics

CAN bus is a differential signaling protocol using two dedicated wires, CAN High and CAN Low, for communication. When the CAN bus is in idle mode, both lines carry 2.5V. When data is being transmitted, the CAN High line increases to 3.75V and the CAN Low line drops to 1.25V, resulting in a 2.5V differential between the two (Figure 1). The voltage difference between CAN High and CAN Low comprises the CAN bus signal. The advantage of differential signaling is that if the bus is subjected to common-mode interference such as external noise or crosstalk from other systems, the noise content is subtracted out and the CAN High/CAN Low difference will likely cancel out most, if not all, of the spurious noise.

CAN High CAN Low wiresFigure 1 The CAN bus uses two dedicated wires called CAN High and CAN Low.

The CAN bus can transmit over 250 m at a data rate of 250 kbits/s. The maximum bus length with a bit rate of 10 kbits/s is 1 km; the minimum bus length with a data rate of 1 Mbits/s is 40 m.

Figure 2 depicts the CAN bus standard message structure with a data field of from 0 to 64 bits. The ID field contains up to 11 bits (part A of the 1991 CAN 2.0 specification) or up to 29 bits (part B of the same specification). The CAN FD structure differs in that there is an optional high bit-rate portion of the data field, enabling users to get more data into the same amount of space and thus achieve higher-speed data transfers. CAN FD permits speeds up to 8 Mbits/s while CAN ranges up to only 1 Mbit/s.

Figure 2 The CAN bus standard message frame structure has typical fields such as start of frame, control, data, and CRC.

Acquiring and decoding CAN bus

The basics for decoding CAN bus traffic begin with acquiring the CAN High and CAN Low lines with single-ended probes on separate oscilloscope input channels. Then, using the oscilloscope’s difference math operator, we can subtract CAN Low from CAN High and arrive at the differential waveform (Figure 3).

differential CAN bus signalFigure 3 After acquiring the CAN High and Low lines on Ch 1 and 2, respectively, the oscilloscope’s difference math operator produces the differential CAN bus signal (F1).

That’s one way to arrive at the CAN bus differential signal. Another way is to use a differential probe. There are, however, pros and cons to both approaches. For one thing, single-ended probes are much less expensive than differential probes. They also provide independent views of the CAN bus lines, which gives you some visual confirmation that you’re probing the right signals.
On the other hand, differential probes will yield a better common-mode rejection ratio (CMRR) than can be achieved with channel subtraction. They also occupy only one oscilloscope input channel, leaving more channels for acquisition of other signals.
Many oscilloscopes can decode the CAN bus. Decoding includes trigger/decode (TD) and trigger, decode, measure/graph, and eye diagram (TDME). Figure 4 is a screen capture of a CAN bus waveform with hexadecimal decode applied.

CAN bus hexadecimal decode waveformFigure 4 Shown is a hexadecimal decode of a CAN bus waveform.

A more informative approach is symbolic decode, which will provide a good deal more information about the actual content of CAN bus traffic. Symbolic decode is conveyed in a DBC file, which is the industry standard file format. In Figure 5, we see a symbolic decode of the hex values from Fig. 4. Now we can determine that we have a message with power in kilowatts and cam speed in revolutions per minute. Another message shows coolant temperature and pressure.
Symbolic CAN bus decodes can be much more complex, with messages being transmitted from air bag sensors, cruise control, the brake circuit, engine control, tire pressures, and the like. Some devices will also put out CAN bus and CAN FD bus messages simultaneously, and these can be decoded in the same acquisition. Not only that, but it’s also possible for vehicles to contain multiple CAN buses, or buses other than CAN bus such as the LIN, FlexRay, SPI, I2C, or UART protocols.

symbolic decodeFigure 5 A symbolic decode of CAN bus traffic conveys much more information than a hexadecimal decode as seen in Fig. 4.

The CAN standard specification includes the concept of bit stuffing to prevent DC bus bias. The CAN bus is not a clocked system, but rather uses a phase-locked loop (PLL) to determine the boundaries between logic 1s and 0s. The transceiver needs to see a modicum of transitions, so it can recover the implied clock from the data itself. Thus, to prevent the PLL on the transceiver from losing lock on long strings of 1s or 0s, the standard forces the CAN bus signal to periodically insert a stuffed bit, or a bit of opposite polarity from the ongoing string (Figure 6). After five consecutive bits of the same polarity, a stuff bit is inserted to break up the string. Otherwise, the frame in which a sixth consecutive bit would cause an error. The receiver removes the stuffed bit.

stuff bitFigure 6 After any five consecutive bits of the same polarity, a stuff bit of opposite polarity is inserted into the CAN bus message.

[Continue reading on EDN US: CAN bus decode filtering]

Mike Hertz is a Field Applications Engineer and David Maliniak is Technical Marketing Communications Specialist, both at Teledyne LeCroy.