How should I interpret this CAN bus protocol - J1939

Question

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?

Answer 1

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.