CAN Bus Communications Decoded: Message Structure
Watch This Course
$199 USD $99.50 USD
-OR-
Or
8 easy payments of only $12.44
Instant access. Easy checkout. No fees.
Message Structure
08.53
| 00:00 | - With all the devices on our network now agreeing on what voltage levels on the CAN high and CAN low mean, and the speed that we're transmitting those 1s and 0s at, we need to define the structure that determines what all those 1s and 0s actually mean. |
| 00:14 | This structure is called a frame as it sets up the framework which lets us decipher what all the individual bits of data mean. |
| 00:22 | A small caveat here, we're going to go into some detail in this section about how a frame is structured as it's important knowledge to have a handle on. |
| 00:29 | But the reality is that once we're interfaced with a CAN bus correctly, all the deciphering of those 1s and 0s into frames is handled for us by the tool or device that we're using. |
| 00:40 | For this reason, we won't do a complete deep dive into what every single 1 and 0 transmitted on the bus could mean because this complexity is handled for us by the devices we're using. |
| 00:51 | I can't think of a scenario where it would be required to manually decipher a CAN frame from the raw 1s and 0s but an overview of how a frame is structured is important in making sure all of our devices are correctly configured. |
| 01:04 | A CAN frame is broken up into 6 main sections being start of frame, arbitration, control, data, CRC and end of frame. |
| 01:13 | We'll go through each of these in order and discuss why they're important and the function they serve. |
| 01:19 | So let's start with the start of frame. |
| 01:21 | This is pretty self explanatory, when the CAN bus is idle, meaning no data is being transmitted, the bus will be sitting there in the recessive state, meaning CAN high and CAN low are at the same voltage. |
| 01:33 | When a device wants to transmit on the bus, it drives the bus into the dominant state. |
| 01:38 | Every other device on the bus will detect this change and start listening for the next part of the frame transmission. |
| 01:45 | The arbitration section is next and is arguably the most critical of the frame. |
| 01:50 | During this section the transmitting device transmits the parameter ID or PID for short of the frame. |
| 01:57 | Every other device on the bus reads this PID and uses it to determine if this is a frame that it is interested in. |
| 02:05 | Or if it can ignore the rest of the transmission. |
| 02:08 | The key thing to remember here is that the CAN network is a broadcast network. |
| 02:13 | Where all the connected devices can read all the data. |
| 02:16 | However most devices on the bus will only be interested in specific pieces of data so each frame needs an ID that the device can use to determine if it needs to listen up or not. |
| 02:27 | An example of this would be an engine ECU that's transmitting engine coolant temp data in a particular frame. |
| 02:33 | The heater ECU in the vehicle would absolutely be interested in this data so we'll be listening out for a frame ID it knows that that data is within. |
| 02:41 | But a door control ECU is not likely to care what the engine coolant temp is so it will likely be ignoring these frames. |
| 02:48 | After the arbitration section, comes the control section. |
| 02:51 | In this section the transmitter defines how long the data section of the frame will be. |
| 02:57 | CAN frames can vary in length and will contain a minimum of 1 or a maximum of 8 data bytes. |
| 03:04 | If the engine ECU we talked about before was only transmitting engine coolant temp data on that frame PID, this is likely to be an 8 bit value so it could be sent with just a single data byte. |
| 03:16 | The ECU will transmit a 1 in the control section of the frame to let all other listening devices know that there is only a single byte of data available. |
| 03:24 | Alternatively to this, the ECU might be transmitting engine coolant temp, fuel temp and oil temp all on the same frame PID. |
| 03:32 | If these were all 8 bit values it would transmit a 3 in the frame control section, letting all the listening devices know that there will be 3 bytes of data available. |
| 03:42 | The data section is also pretty self explanatory. |
| 03:45 | In this section, the transmitter will transmit exactly as many bytes of data as it has said it will in the control section. |
| 03:52 | This is the meaty part of the message and the stuff we're often really looking for. |
| 03:57 | If we're decoding the data on an OEM CAN bus, this is the part of the message we'll spend all of our time with, determining whether those bytes are read individually as 8 bit numbers, combined into 16 bit numbers or read as flags or something completely different. |
| 04:11 | We refer to the bytes of data in this section by their byte position, being byte 0 to byte 7. |
| 04:18 | The CRC section is next, CRC stands for cyclic redundancy check. |
| 04:23 | This section of the frame is 15 bits long and mathematically constructed from all the frame sections that have come before it. |
| 04:30 | This is a proofing section as every receiving device will calculate what the CRC section should equal and compare it to the received value. |
| 04:40 | If the calculated and received values match, then the frame is declared valid and assumed to have been transmitted correctly. |
| 04:46 | If the 2 values do not match then something must have gone wrong with the transmission and the receiver knows not to trust that frame data. |
| 04:55 | This CRC checking is hugely helpful and really important for mission critical data. |
| 04:59 | A good example of this would be on a modern vehicle with an electronically controlled throttle. |
| 05:03 | It's possible the accelerator pedal position is being read by a different ECU to the one that's controlling the throttle motor. |
| 05:10 | If the CAN frame containing the accelerator pedal position was corrupted somehow in transit, the ECU controlling the throttle motor could mistakenly open the throttle which would be a very unsafe outcome. |
| 05:22 | Instead, the ECU controlling the throttle motor would compare the received and calculated CRC values, see that they don't match and ignore the data. |
| 05:31 | Likely it would log an error and put the vehicle into some sort of limp mode as well. |
| 05:35 | While it's theoretically possible that a CAN frame could be corrupted in such a way that the data in the CRC values still match, the chances of this happening are vanishingly small so if you see data on the bus that has passed a valid CRC check, you can be completely confident that this was the actual data that was transmitted. |
| 05:56 | The end of frame section is another self explanatory section and contains 7 bits where the transmitter lets the bus fall back into the recessive state. |
| 06:05 | Once every device has seen the bus recessive for this period, it knows that the bus is once again open for transmission. |
| 06:12 | There are other parts to a CAN frame but for the purposes of creating your own CAN bus in a performance automotive application, or reverse engineering and decoding the data on an existing CAN bus, knowing about just these sections is going to be more than adequate. |
| 06:26 | One last point to touch on around CAN frame structure and PIDs in particular is that of frame priotity. |
| 06:33 | It is possible that 2 devices on the bus will start to transmit their frames at essentially the same time. |
| 06:40 | This is called a bus collision as the 2 frames collide with one another on the bus and the data gets scrambled. |
| 06:47 | The most common method for dealing with this situation in a network protocol is called CSMA/CD or carrier sense multiple access with collision detection. |
| 06:57 | This involves each device monitoring the state of the bus as it's transmitting and if it detects a collision it will cease transmission immediately, wait a random but small amount of time and then try again. |
| 07:09 | The CAN protocol has a much smarter way of dealing with frame collisions however, which ensures frames of a higher priority are transmitted cleanly. |
| 07:17 | The frame PID also serves as a priority level with a lower value PID, meaning a higher priority message. |
| 07:26 | As each device transmits on the bus it also monitors the state of the bus. |
| 07:30 | If during the frame arbitration stage, a device tries to let the bus fall back into the recessive state which is transmitting a 1, but the bus remains at the dominant state because another device on the bus is driving it to the dominant state, transmitting a zero, the first device will immediately cease transmission, allowing that second device to continue. |
| 07:53 | Because of the way the data transmission works, the device transmitting the lower PID will always win this arbitration and continue transmission. |
| 08:01 | The exact logic of how this works isn't important to understand but it's important to be aware of a lower PID value meaning a higher priority frame. |
| 08:09 | Particularly in the case of decoding an OEM CAN bus data stream. |
| 08:13 | We've covered quite a lot in this section so let's just have a quick recap. |
| 08:16 | Data on our CAN bus is sent in individual frames, each of these frames has 6 important sections. |
| 08:23 | Start of frame, arbitration, control, data, CRC and end of frame. |
| 08:28 | Decoding the raw 1s and 0s on the bus into the sections of a data frame is not something you should need to do because the device or tool that you're using to interface with the bus will do this for you. |
| 08:39 | The most important sections of the frame are the parameter ID, which we call the PID and of course the data sections which contain the information we're either wanting to transmit or decode. |
