J1939 DBC file discussion
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:05] It’s an example, an arbitrary example, I think originally pulled from the Internet somewhere, of transport protocol. In the case of automotive work, you sometimes want to be able to send the Vehicle Identification Number on the CAN bus. Vehicle Identification Number is more than eight bytes, so how are we going to send that? CAN frame will only send eight bytes of data. Well, we’re going to send it in four different bytes. I’m going to give a real world example of this that I had actually pulled off of a truck, but this will go through some of the concepts here. So, there’s a lot of overhead associated with transport protocol. Overhead is 11 bytes in order to send 21 bytes of data. So there’s 11 bytes at overhead. That’s a lot of overhead. So you lose some efficiency in transport protocol. In this diagram, I have the 11 bytes of overhead, highlighted in red. So those are just overhead. The data, in this case, [00:01:05] just 1, 2, 3, up to hexadecimal number 11, I have just used a counter here. So we’re sending this four different CAN frames.
So, at least in J1939 transport protocol, priority for every one of these frames is seven. It’s the lowest priority, and that’s just part of the definition, and it’s a disadvantage of transport protocol in J1939, because if you got a high priority message that’s over 8 bytes, you don’t have any options, you just send it as priority seven. NMEA 2000 fixed that. You can prioritize within the transport layer.
Total of four frames in order to transmit, again, 21 bytes of data, that’s a lot of overhead. This particular example is the Vehicle Identification Number PGN 65260. [00:02:05] This is a hex conversion of the PGN, the PGN number in transport protocol is actually varied within the first byte of that transport protocol, so the PGN is right here, FEEC. Remember, you got to reverse some, the INTA [sic], motor, all the thing? Yes, it’s going to haunt us.
I’ll go through all of this, but your VIN ends with an asterisk, so you know it ended, and that’s just transferred into an ASCII number.
Yes, the PGN identifier is buried within the data. This is a PGN number. By J1939 standard, this is actually a PGN. Defined it as a PGN.
So the PGN 60160 is actually the data to transfer and it contains [00:03:05] the actual data payload, so the data payload is just another way of saying the data. So the transport protocol on J1939 only uses two different PGN numbers. Two different PGNs. The first one is the control PGN, that says hey, I got a transport protocol message, I’m going to send it. It consists of this number of bytes of data, I’m going to send it in this many frames. This is the PGN that’s going to be buried within it. Here it comes.
The spec also says that you got to send them 50 milliseconds apart, minimum. Because the theory is that devices receiving it have to crunch it and process it, so you can’t be sending them back to back, because there maybe eight bit processors trying to receive it and they can’t move that fast. So the spec says yes, you got to wait 50 milliseconds between each frame transmission.
So these are the basics of J1939 transport protocol there.
Let’s look a real world example. I don’t want to spend too much time on a fictitious example. [00:04:05] Here’s a real world example, so I cut this out of a data series. I eliminated all of the data in between, because if you look at this, there’s a lot of time in there, from a computer standpoint. There’s a heck of a lot of time in there. There’s actually 70 milliseconds between that message and that one, so if this is running at 250K, there could be 140 messages in between. So I cut them out. I got them out. I’m only showing what’s relevant to my transport protocol. But it’s important to realize that these messages are pulled out of a very large dataset that was collected.
This is a request message. I told you this, that most of the J1939 PGNs are eight data bytes. Well, this is the request message that I set I was going to show you, that’s actually three data bytes. So it’s only three data bytes long. In the advanced course that I showed, that specific that I called J1939 Fundamentals, [00:05:05] we can go on and take every single bit apart and show you what everything means here. I’m not going to do it in this course because it’s a little bit too lengthy a time, but I will say that it’s only three data bytes. This is the 29-bit header. 1, 2, 3, 4, 5, 6, 7, 8 x 4, that’s for per character, it’s 32, but remember, I said this one can only be 1 or 0. You’ll never see that on the left, so that’s 29-bit header, and three data bytes here, and down here, eight data bytes. So how do we take this apart? So this particular device tells you how many bytes are in your frame, so there’s 7 and then there’s 12, and each one of these. I’ve highlighted all of the overhead and I’ve left the actual VIN as white here.
This particular tool reassembles this PGN, FEEC PGN, [00:06:05] which is a transport PGN. It reassembles it. It says this is a J1939 PGN that I have reassembled at this time, which happens to exactly matched the time it received the last frame. It couldn’t reassemble it before it received that frame, because it didn’t have all the information. So I’ve reassembled this VIN based on these frames, at this time, and it’s now 22 characters long, and here it is, and this is an actual VIN of a truck I worked on at PACCAR. If you take these as ASCII numbers – and we know ASCII but ASCII is a standard that allows you to send characters via hex data – if you take these numbers, I think that’s an A, I think, and 41 is an A; I can’t remember what 31 is. I think it’s the number one. Each one of these represents a character, and if you decipher that, [00:07:05] you have the VIN. When you look at under the windshield, it better match the VIN that’s on the truck, because that’s the purpose. So that’s transport protocol in a nutshell. It’s a perfect example of why you need it and how you do it.
Again, it’s not going to be used. I had a dotted line in that one drawing. It’s not going to be used if you’re just transmitting eight-byte PGNs. But in this case, we’re transmitting a 21-byte PGN.
Question?
Unidentified Man: Can you have [inaudible 00:07:33] in the DBC file?
Bryan Hennessy: Well, I haven’t done that. I haven’t set up an example. I’d have to look at our DBC file editor and see if it supports transport protocol. I don’t think it does. I don’t think ours does, but in a DBC file in general…
Unidentified Man: So you can’t go and have 64 bits and signal that?
Bryan Hennessy: It’s a good question. [00:08:05] How do you do that? I need to look at that. It’s a good question.
Unidentified Man: It’s what the J1939 is going to do. You’re taking your free messages and you’re piecing it together to 22 bytes.
Unidentified Man: How does DBC file know that?
Bryan Hennessy: Well, the J1939-73 specification defines what we called diagnostic messages, and the -71 defines all PGNs, but it doesn’t define them as a byte PGNs. It defines them as whatever they need to be, and it relies on the transport layer to take them apart. But it’s a great question, as to how that’s represented in the DBC file, because I don’t know that. I’ll check that out. We might be able to pull up a DBC file editor and just take a look at that. I’d like to have that answer. Thanks for asking.