Today’s equipment is loaded with electronics. Tractors, trucks, harvesters – just about everything communicates through data exchange between electronic control units (ECUs). This is done through a system called the CANbus.
Whether it is agriculture, transportation, or production, understanding how CANbus works is no longer the sole province of electrical engineers. Mechanical engineers who want to stay current must learn the language these machines speak.
This article explains how to decode CANbus messages – specifically, how to transform a CAN message into a human-readable parameter.
CAN (Controller Area Network) is a communication protocol that allows ECUs to talk without a central computer. It enables real-time data sharing between ECUs, such as engine control, transmission, ABS, instrument cluster, etc.
The system uses two twisted wires – CAN High and CAN Low – to minimize electromagnetic interference and electrical noise. The network also requires two terminators to stabilize the communication among control units. These resistors are occasionally built into the ECUs, so they may not be physically evident.
Voltage levels on the CAN lines behave as follows:
Let’s walk through how to decode CANbus messages using a real-world example – John Deere 6105R tractor.
The CANbus in this setup runs at 500 kb/s. Knowing this value is essential when using a CAN sniffer tool to analyze network communication. One of the most commonly monitored parameters in this context is engine speed, which is especially relevant for those working with this tractor model.
To trace how engine speed information reaches the instrument cluster, starting at the source – the crankshaft sensor is useful. A magnetic sensor detects the movement of a reluctor wheel attached to the crankshaft and produces an analog signal. This signal reflects rotational speed and is used to determine engine speed. The calculation considers a full 720-degree crankshaft rotation divided by the number of cylinders. Here, the engine is a 4.5-liter, 4-cylinder configuration.
Following CANbus sniffing and referencing the SAE J1939 protocol, the message ID containing the engine speed parameter was identified – 0CF00400 in this case.
The PGN (Parameter Group Number) for this specific message ID is F004 in hexadecimal and 61444 in decimal. Within the SAE J1939 protocol, PGNs are listed in decimal format only, so conversion from hex to decimal is necessary during analysis.
The engine speed value is located in the fourth and fifth bytes of the message. In this instance, those bytes are C6 and 26, both represented in hexadecimal format.
To calculate the RPM, the two relevant bytes must be combined using the little-endian format, where the least significant byte comes first. In this case, C6 (hex) equals 198 (decimal), and 26 (hex) equals 38 (decimal), confirming that C6 is the first byte in the sequence.
It’s crucial to perform byte concatenation, not byte addition – adding the values instead of combining them will lead to incorrect results. Using little-endian order, the concatenated value becomes 26C6 (hex), which equals 9926 in decimal.
The final step is multiplying this value by 0.125, yielding 1240 RPM.
Lets enable the CAN interface and select Custom. We already know that the CAN line is with 500 baud rate – select baudrate to 500.
Lets open next table – CustomCAN „Config“:
We can select the destination from any available. Lets choose the CustomCAN IO 1201.Since we have enabled the CAN1, interface will be CAN1.
Messaage type have 3 options available. Standard – CAN Ids are in range from 0x0 to 0x7FF. Extended – CAN Ids in range from 0x0 to 0x1FFFFFFF. J1939 – looking only into middle bytes. Example 0x18F00300. According to J1939 we need to identify only 0xF003.
After filling the custom CAN with our values:
For further details, refer to SPN (Suspect Parameter Number) 190 as defined in SAE J1939-17. This parameter provides engine speed data from 0 to 8,031.875 RPM.
The image above shows how engine speed fluctuates during CANbus sniffing. This SPN was transmitted every 100 milliseconds. Other parameters were also sent, such as byte 2, representing the driver’s demand engine torque, and byte 3, indicating actual engine percent torque.
The image below presents the message 0CF00400 F1 FF A9 C6 26 FF FF FF as visualized through a logical analyzer, offering a more precise breakdown of its structure and values.
When the signal line is high (vertical line up), the CANbus is dominant, representing a bit value of 0. When the line is low (vertical line down), the bus is in the recessive state, indicating a bit value of 1. For example, the byte FF consists of 11111111, which means all bits are in the recessive state.
Δ