# How should I interpret this CAN bus protocol - J1939

I have been using J1939-21(Data link layer) many times, but now I'm confused.

First I know that a J1939 protocol is build up from a data frame and that data frame looks like this in practice.

<ID> <DATA OF 8 BYTES>


The rest handels the CAN-bus controller.

The ID describes what type of message it is and where it comes from and where it want to arrive.

The DATA describes 8 bytes of different 8-bit values from 0x00 to 0xFF. That's all! Super simple!

But how should I interpret this table with a J1939 protocul from this Scania site? https://til.scania.com/w/bwm_0001161_99

If we begin with the ID. Here we can see that the meaning if this message is 19FF and the message goes from 4A and want to arrive at 85. So the ID message is 0x19FF85FA in hex.

Now to the data. As I know, every CAN-bus message have 8-bytes. So I assume that I would see something like this:

[Byte0, Byte1, Byte2, Byte3, Byte4, Byte5, Byte6, Byte7]


Example:

But I'm isint! Instead, I'm seeing this. What does this mean? First, I know that this message are going to the ECU - Eletrical Control Unit, e.g PLC or controller. So this message is a R e c i e v e r message.

Then we have the bytes. Here I can see that we have different bytes such as byte 1 and byte 1. What??? I cannot understand this.

So here are some questions:

• Is B y t e column only the index in [Byte0, Byte1, Byte2, Byte3, Byte4, Byte5, Byte6, Byte7] and Byte1 is acctully Byte0 in this indexing?

• What is B i t ?

• How can the message TelecomConnectionStatus (Telecom Connection Status) have the length 4 but 4 TelecomNetworkTechnologyInUse (Telecom Network Technology In Use) looks like it have more lengths because it has more rows?

I don't understand this. Do you?

This is what happens when incompetent non-programmers are allowed to document raw binary data...

All programmers in the world, as well as the CAN standard, as well as the J1939 standard, all enumerate both bits and bytes starting with 0. But the incompetent person who wrote this document did not. They even managed floating point notation here and there.

Now how do we know that they name MSB bit 7 (or 8) rather than 1? Since we already established that they aren't using standard or engineering praxis, we don't...

As far as I remember, J1939 also requires little endian for word-sized chunks, but whether or not that applies here, we can't know either, since the document just writes 0xFE00 etc and we can't know if this is the raw byte dump from the bus or the numeric value after little endian has been applied.

So this so-called documentation will ultimately have to be accompanied with trial & error and a live bus listener.

We can only guess that they meant to say something like this:

• Given the first byte of the payload, called byte 0 by the CAN standard and by engineers (1 in the document) lets say you have something like for example 0x02.
• The 2 in that byte is called bit 0-3 to by engineers (maybe 1-4 in the document? we can't know). A guess is that this would represent TelecomConnectionStatus = Connected.
• Then the MS nibble 0 called bit 4-7 by engineers (bit 5 in the document, maybe?) and represents TelecomNetworkTechnologyInUse = gsm.

You have to verify that this is so by connecting to a live bus. Then hopefully the document is consistent across multiple packages.

• Not sure if I can agree with this assessment. "non-programmers" - possible. But hardly "incompetent". The J1939 standard was introduced almost 30 years ago and CAN was not a part of it until 6 years later. It was designed by automotive engineers and is so widely used nowadays they must have done something right. Considering that "competent programmers" still disagree about the right way to index arrays after 70 years of 3GL I'd say we should not criticize them much. Mar 10, 2021 at 16:33
• So what is Operation data range? 13 is smaller than 0x0F, which is 15.
– DanM
Mar 10, 2021 at 17:44
• @Maple If you actually bother to read the question & answer, I'm not criticising the J1939 standard, but the specific OEM documentation about a specific J1939 implementation, which this question is about. Mar 11, 2021 at 7:53
• @DanielMårtensson It appears to describe how much of the data that's to be regarded as values and how much of it that's to be regarded as status messages. The TelecomConnectionStatus stored in a nibble, has possible values 0-15 and has status messages with values 14 and 15. So everything which isn't status goes into 0-13. This is consistent with the 65023 value further down. (But again, we don't know endianess - though to make sense of it we might have to assume it's the value after reading as little endian.) Mar 11, 2021 at 7:57