Structure of a CAN Frame
The CAN Basics Training Course provides a practical approach to understanding how CAN works. By giving real world examples, common practices, and an in-depth look at DBC files, Bryan Hennessy gives a real-world walkthrough of CAN.
Presentation by Bryan Hennessy. Recorded as part of a ‘live’ training session in January 2019.
Video Transcript:
Bryan Hennessy: [00:00:01] So the structure of a CAN frame. This is moving from the physical layer to the data link layer. We now know and how very comfortable with getting 1’s and 0’s across the network reliably between devices and how that wiring is hooked up and how it’s all done.
Now we’re going to talk about the frame, how does device A know how to package those 1’s and 0’s and how to understand what they mean when device B sends them a whole block 1’s and 0’s. It’s beyond 1’s and 0’s at this point. We’re into the CAN frame or what’s called the data link layer.
This is a diagram stolen from a Kvaser training on the Kvaser website. This shows what we call Classic CAN 2.0A and 2.0B. I’m not going to get into a lot of the history on it but I will say 2.0A is simply a [00:01:00] CAN frame with an 11-bit identifier and 2.0B is a CAN frame with a 29-bit identifier. A lot of standard J1939 almost always have a 29-bit identifier. CANopen always uses an 11-bit identifier. They define and break that identifier up differently depending on prioritization and source of drafts and things like that that we will get into to answer your question earlier.
So, after the identifier, there’s some other bits in here that I’m not going to get into real specifically because they’re involved with history and other stuff and you don’t really need to understand them to understand the basics of CAN. In a more advanced course we could talk about every single bit in the CAN frame, but some of these single bits I’m not going to get into right now. So I’ll talk about, in general, the arbitration field and then I’ll talk a little bit about how the arbitration field may be broken down by J1939 [00:02:00] just as an example.
Again, it’s different CANopen. I’ve been recently studying CANopen and I could talk about the arbitration field and CANopen as well. I haven’t prepared anything on that. I’ll talk a lot about the data field, a little bit about the control field as well and tell you what’s in there, which is basically the DLC, the data length code. Talk about the data field. Then I’ll mention the CRC without getting into great detail on how a CRC works. I’ll tell you at least what it does. Then there’s some closeout stuff. There’s an acknowledge bit that we can understand, it’s pretty easy to understand. Then there’s an end of frame sequence. Then you’re done with your CAN frame. That’s it.
So, the one thing to understand about CAN frames in general is, a lot of times a CAN bus will be floating, will be just nobody transmitting anything. You’ll be out here somewhere. As we’ve seen one or more devices could decide, “Hey, I got a CAN frame to transmit. I’m going to take control of this bus and send it.” The first thing they send, as I said earlier, is the start of frame bit. [00:03:01] So if you go back to my bit-wise arbitration slide, that’s where both device A and device B decided they’re going to go from recessive to dominant with the start of frame bit and then they start sending the beginning bits of their identifier. If two devices or more are on the network, you have an arbitration situation where we’re arbitrating for the bus.
We’re done with arbitration, and an important thing to know about arbitration is, when you get done with this arbitration field, by definition, by design locked in stone, there’s only one device transmitting on the bus. One device has one arbitration when you get down with the arbitration field. If you still have two devices that think they want arbitration, you got a faulty bus. You got a problem. That doesn’t exist. It can’t happen because, at least, in J1939 every device is a different source address. We’ll get more into that in a little bit. But different standards have different ways of making sure that only one device has one arbitration by the time arbitration is over.
Then you get data CRC. [00:03:59] We’ll talk more about that in a minute.
Here’s some CAN data. Makes sense? You know what that is, yes? Easy to read. Well, by the end of the day it will be. You’ll be able to take something out of that data stream and know precisely what it means because I’ll show you how to do that. That’s what I call taking the mystery out of CAN. This is a mystery. This is gobbledygook. Nobody knows what this is. I can tell you in great detail what every single bit in that pattern is and show you how to read it. Hopefully, I’m going to do that in pretty short order.
So this is a grab of data I got from CANKing which is Kvaser’s free bus monitor. In our download section I can show you that, that all of you should, maybe, grab and get somewhat familiar with. But it’s a pretty simple tool. It just shows you what’s on the canvas. It doesn’t care what the data is; it just shows it to you.
So what we have out here is the channel. [00:05:01] This is a single channel network. CANKing can read from more than one channel if you have more than one CAN bus going at the same time. But here we’re just using channel 0. This is identifier and in this case this is a 29-bit identifier. Now you might say we got one, two, three, four, five, six, seven, we got eight, so we got four bytes, so 4 x 8 is 32. So, well, no you got 32 bits, not 29. Well, no, we have 29 because this one here… listen, you’re only going to see it as a 0 or a 1. That’s the only way we can represent it. You don’t have a clean way in hexadecimal of representing 29 bits. So you got to just say, well, that’s going to be a 0 or a 1. That’s only 1-bit and the rest of these are 4-bit characters. So that’s 29 bits. So that’s a 29-bit identifier.
This flag says that it’s an extended identifier. It’s 29 bits as opposed to 11. [00:06:00] This is your DLC. This is your data length code. If you go back to the previous slide, this is transmitted, or I’ll show you on the next slide, this is transmitted in control field. That’s transmitted after arbitration. They need extra data. Depending on the standard, and again I’ll refer to J1939, you can have anywhere from zero to eight data bytes, eight is the maximum that you can have in here. So what are we going to do if we need to send a message more than eight? Well, that’s an applications question, and that’s going to be transport protocol.
This is a timestamp. This is never on the data bus. This is applied by CANKing depending on what time that particular frame comes in. This simply says that this frame was received by the Kvaser device as opposed to transmitted. So that’s, in a nutshell, what everything on that whole diagram means, there’s no mystery there. I will later, in the presentation, [00:07:01] show you how to identify and take apart any piece of this data. I’ll also show you exactly what this identifier means and how to take that apart depending on what application or what industry you’re in and what high-level protocol you’re in. I’ll show you based on J1939 mostly but I just don’t have time to go into each one of them differently. But you’ll get the meaning. You’ll get the gist of it from J1939 as an example.
A lot of this training here, as I mentioned, is training by example because I can’t teach everything in two hours. There’s no way. But I can pick an example, I can explain generally how those works in different industries and then I can dive in and show you the very details in one particular example. Hopefully, you can apply that example and understand that enough to apply it to other areas.
So the whole idea of this is just to make you much more comfortable with the fact that hey, I can [00:08:00] look at this data that previously meant absolutely nothing, that’s gobbledygook and I actually can understand how to trace that to something meaningful, all the way from the voltages on the wire to a meaningful signal is where we’re going today.
Here’s a blow-up, again based on J1939, or actually NMEA 2000 I think this one is, I’m not sure, but they’re both pretty much the same. Yes, this is J1939 of the arbitration field. So bus arbitration is done here. This is the arbitration field. Then we get to the control field which I said has a couple bits, we’re going to ignore, and the data length code. Data length code just tells you how many data bytes you are going to have in that frame. So it’s zero to eight.
Without getting into what a parameter group number is or how it breaks down, I should say, into these because this gets pretty specific to J1939, I’m just going to say this is the parameter group number. So we have start of frame, [00:09:00] we got priority. Priority is 3 bits. Every message in J1939 has a priority. Zero is the highest[edited] priority. We now know why because of bit-wise arbitration.
You got a recessive bit. I’m not going to get into here. Then, basically, you got a parameter group number. A parameter group number is an identifier for the data that’s going to follow. A particular parameter group number is going to say this parameter group number in J1939, you’re going to build a reference suspect that tells you exactly what the data is and how it’s broken down by knowing what this parameter group number is.
Following that, you’re going to get a source address. That’s who’s transmitting the data. Every single frame has one and only one device transmitting it on the network and has one or more, possibly all of the devices, wanting or listening to that data. Now, as we know a network consists of two wires. [00:10:00] Any device sends a message on that network and every device hears that message. Can’t be otherwise. That’s just the fact. That’s one of the beauties about CAN for control systems, is everything on the network has access to all of the same information by nature, by the way it’s wired. We can’t change that. We don’t want to change that. That’s a beauty of CAN.
So, priority, parameter group number, source address. If two devices or more are transmitting messages of the same priority, arbitration continues. If two devices or more are transmitting messages with the same priority and the same parameter group number, we get all the way out to here and we still have two devices on the bus thinking that they want arbitration.
At least in J1939 and the protocols based on J1939, [00:11:01] every device has to have a unique source address. So in that case where everything else is the same, the device with the lowest source address is going to win arbitration. By the time we get here in time, only one device is going to be on the network transmitting. We’re going to transmit a DLC code, all the receivers know what the parameter group number is, so they know what to look for in the data and they’re going to read the data. So that is the data link layer. That’s the essence of the data link layer.