The datafield, the DBC field, scaling and offsets
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] We got the physical layer. We understand the voltages on the wire. We understand bit-wise arbitration, which is key. Now we understand the CAN frame or the data link layer. We understand, at least in J1939 and some of the others, exactly how the identifier is broken down in the arbitration phase. So we got the data link layer down. That’s clear to everybody. Any questions on those two concepts?
So now we’re going to move on to data. We got to know what the data is. The whole purpose of CAN is to get data from Device A to Device B, or more. So we can’t get reliable data that means something. We’ve just explained the overhead at this point, the data is the real value in CAN. So we’re going to talk much more about data now.
When you talk about data, you got to talk about a DBC file because that is the key, that is what explains to the systems what the data is. [00:01:01] So the data field, how is the data represented, as I call it. So CAN frames includes zero to eight data bytes. A classic CAN frame can’t be more than eight data bytes. I covered this, 99% of them, at least in J1939, have eight data bytes. There are some control frames in J1939 that use three data bytes, and I’ll show on.
Here’s another example of some data similar to what I showed you before captured with a different tool, so it looks a little different, but it’s the same data. So this particular tool that captured this data is called a J1939-84 tool. It was made for the purpose of doing -84 work, which is what I did at PACCAR. But it shows you the same data. The timestamp is on the beginning instead of the end. Big deal. It shows you the channel. Here we call that 1. Before we call it a 0. Big deal. [00:02:01] Shows you the identifier, and this identifier is shorter because the last two bytes aren’t shown because of the source address. We got flag, so it says it’s received. This is just a received byte. We know a DLC code. Each one of these frames has eight bytes of data. There’s our data for each frame. Doesn’t mean anything yet. We got our frame counter.
It’s just a little bit different twist on what I showed you before when it comes to raw data. The common theme here is we don’t know where this is. This is just a bunch of hexadecimal numbers that don’t mean anything to us. That’s what we’re going to explain with the DBC file and showing you how to break this down and understanding the data.
[00:03:42] I pulled up CANKing, which is Kvaser’s free bus monitor that’s on our website to download. You go to our website to the home page, you find the downloads section which is on the right. Where is that, I can actually do it here and show you. So you would go over here and you’d say Support, this is our main home page, Kvaser.com, Support, Kvaser downloads. I’ll let that load. Takes a second to load, we’re not Google yet. Give us time.
First thing you always need with a Kvaser device in your network are the drivers. One driver runs any Kvaser device you can get or plug-in. CANlib SDK, we’ll talk about that later. You just probably don’t need that. [00:04:42] If you’re going to do t-programming, you will but for now we’ll skip CANlib. So there’s CANKing, third one down, CANKing. You download that in your download area, you load it. You have a basic bus monitor at that point. Hook up any Kvaser device to any CAN bus, configure it for the right bit rate, set it up over here and go over here and click Start Run and, oh my gosh, I got a CAN data. This is live CAN data. Where’s it coming from? This is a compass. This is an electronic compass that my first day as a Kvaser employee I realized, “Hey, I’m a hands-on guy, I want to learn this stuff by looking at it.” So I went to my garage, I saw those in the marine business before, I found this leftover and I grabbed it and made my own CAN bus. So it’s not a J1939 device. I wish it was. But since NMEA 2000 is based on J1939, it’s very similar. I can talk about it as if it’s [00:05:42] J1939, and I will.
It’s putting this data on the bus. I can’t make any sense of this data. This is just gobbledygook. There’s only one device on this bus right now. It’s the only device. I didn’t bring my other devices. I usually have a GPS and some other devices on the bus. But I had limited packing space because I had to carry ski boots to this trip, so.
First thing I can do to make sense of this data is I can go over here to this data field that I can right click and I got this option, a fixed position right here. I’ll check fixed position. There’s only two different CAN frames on this bus right now. What fixed position does in CANKing is, if it’s the same identifier, which we know exactly what that is, 29 bits worth, we understand that, if it’s the same identifier, it just repeats it in the same fixed position. That’s what all fixed position mode does. There’s the data changes and the timestamp changes.
Each time it [00:06:42] receives that frame, it updates that timestamp and it updates the data. Each time it receives that frame, it updates that timestamp and it updates that data. I can see that data change. I happen to know that this is the heading, and my heading is actually contained in those two bytes, and I can see that data change when I move my compass. It’s still just hex data, it doesn’t mean anything. Well, I’m going to show you what exactly it means. I’m going to use that as an example to show you what a DBC file does and how to take it apart. I’m going to make that ugly hex data that means nothing into a true meaningful value.
Now, rate of turn, this next byte is rate of turn. I won’t get into that. Don’t have time to do a bunch of them but it’s the same principle. There’s a lot of other information in these frames that I didn’t really take apart. I didn’t even really define in my DBC file. But it’s there. It means other things. You can [00:07:42] research it if you want and learn what that is. That’s all defined in a true DBC file. The DBC file I’m using is a hacked DBC file that I created, that I made in order to understand how would they do and how they do. So it’s a very simple one. It just defines a little bit of the data, not all of it. But truth be known, heading is only two bytes in here and I got eight bytes in one frame. There’s a lot of information. At first glance, you’ll think, “Oh, a CAN frame is only eight bytes, that’s not very much data.” Now we’re dealing with gigabytes now in our PCs. There’s a lot of information in an eight byte. You could put a lot of information down the tube in eight bytes. You can put a lot of frames down the tube.
This CAN bus is running about 2% full. I can run this CAN bus, and I will today if you want me to because I can do it with a t-program, a little sneaky method I made. I can crank this bus up to 100% full just like that, and it will still get data through.
Now, [00:08:42] you put too much data, there is a limit to how much data that goes on the bus and you will get what’s called dropped frames. The system is set up so that some frames might not get through, and that’s kind of a decision that’s made up of the application. If you just can’t get it through, you just give up after a while. The application gives up. So is my bus is too full, I can’t get that through. Doesn’t cause an error on the CAN frame. It doesn’t cause any problem on the CAN frame. It’s just frame is too busy. If there’s too many people in the room talking, nobody’s going to understand me, so. A frame never gets through in some cases. But we can do that a little bit later.
I just wanted to show you, this is real stuff, this is real data. I have this data right here and we’re going to get more into that in a second.
Let me go back to the presentation. So we’re on this slide when we took a break. This again is representative of some data captured by a different tool. I was getting in it. I explained what each of one [00:09:42] the blocks of data are so there’s no mysteries here. Now we’re going to talk about the data itself. We’re going to get into understanding what that data is.
So let me go to the next slide. So the data field, how is the data represented? This is what I call a raw data. It is a difficult thing to interpret. It’s not made for humans to interpret it or understand it because the text code is made for computers to interpret. They speak that language. That’s what computers do. That’s their native language, hacks or binary. For J1939, at least the key is the specification. That really tells you what the data is. We specify what’s called PGNs and SPNs and we’re constantly on the J1939 committee assigning new SPNs for new pieces of data that aren’t yet standardized, that different manufacturers want to put on the data bus, things for automated vehicles or target on the right-hand side [00:10:42] behind the bumper, or whatever. Different companies come to us. The Standards Committee, they say, “I need an SPN for this.” Well, that’s the data. We’re defining different data and we’re defining it by changing the J1939 specification, one of the specifications. There’s many of them. There’s one or more J1939 specification for each layer of the communications.
So as an example, J1939-11 is the physical layer specification for 250K physical layer. J1939-14 is the physical layer specification for the 500K physical layer, which is different. You go all the way up, J1939 -73 or -71 is a applications layer that defines some of the applications data. Anyway, the spec is the key. How that key is communicated, how that information is [00:11:42] communicated to a computer is by something called a DBC file, a very important file. It describes what the data is and what the CAN is in the DBC file.
It’s an industrial standard. For those programmers in the room, it is based on an XML format, which is just another standard that just defines how you make a file that different computers understand, write to or read to, whatever. A DBC file is fixed for any given CAN network. It changes as the network revolves but at any given time when it’s running it’s a fixed thing. Boom, you’ve got a DBC file. Most computers use the DBC file. They don’t write to it. We actually have a DBC file editor that’s free on our website. You can download it. You can look at a DBC file. I will use it as an example. You can find meaning and find what the DBC file means. You can change a DBC file, if you want, with our DBC editor. [00:12:42] That’s free on our website.
Basically, when it comes to the data, the biggest thing a DBC file does is it labels the data, it defines the data within the data structure of a CAN frame, and then it sets scaling and offsets of that data. It defines what type of data it is, floating-point data, signed integer data, unsigned integer data, whatever, and then none of them tells you where it is, what it is but how to scale it and offset it to get to the number, the meaningful number that you want from that data. That’s a DBC file.
Here’s a graphical representation I made to help explain how a DBC file works. Now, probably the most important thing to understand on this is not all CAN networks even have a computer on them. When I use the term computer, I specifically said are embedded processor or embedded system. [00:13:42] A CAN network, sometimes, it’s a completely closed network that nothing’s monitoring or seeing other than small little smart devices and they’re communicating data and making decisions and controls based on that data. So this could be an 8-bit processor using a very rudimentary form of a DBC file that we wouldn’t even recognize as a DBC file. In a computer, it’s a dot DBC file, but that doesn’t mean in every application it has to be able to read a file of that type. But in a computer, you’ve got a computer application, this may be ATI VISION or one of the other partner softwares that we deal with from other partners, for an application or maybe an industry specific application, it’s going to reference the DBC file when it’s used in that form to understand what the data is.
So, we got a network, we all know what a network looks like now. We’re all very comfortable with the voltages on that network and how it’s structured. The other Kvaser interface plugs into that network [00:14:42] and we got a USB. This is a simple Kvaser interface and we got a USB cable, in this case coming to a computer. What does the Kvaser interface do? What layers does it handle?
This is the first thing that Troy told me when I got hired on Kvaser about understanding what Kvaser interface is. It delivers CAN frames here. That’s all it does. It has no idea whether that’s J1939 or CANopen or NMEA 2000, it’s just delivering the data here. Everything else that’s done with the data is done in the application, or the embedded processor or embedded system out here. So it’s really quite simple. It’s a very reliable device that just delivers the raw data to the USB port.
In the case of a data logger, it stores and saves their all data and it’s much more complicated system because it’s configured from an application and all that. But that’s the function of it. Deliver that raw data. In this particular example, I threw a display up here, or an instrument or something, just as [00:15:42] generally when you got something out on a CAN bus it’s doing something, controlling something, displaying something, sensing something, it’s got a purpose on the CAN bus, it’s not just there for the hell of it. In this case I just threw a display up there, or an instrument or something, to indicate that, yes, this data is going to be used for something. So that’s my DBC file explanation graphically.