That seems simple enough, right?
Note, however, that the above is a bit simplified as the J1939 29-bit identifier can be broken further down into sub components. Specifically, the ID comprises the Priority (3 bits), PGN (18 bits) and Source Address (8 bits). Further, the PGN can be broken into four parts: Reserved (1 bit), Data Page (1 bit), PDU Format (8 bits) and PDU Specific (8 bits). However, this level of detail is less critical from a data logging perspective and will not be covered here to avoid confusion.
SUSPECT PARAMETER NUMBER (SPN)
You may be wondering: "Are the PGNs the data parameters I'm looking for?"
Not exactly. That's where SPNs come in:
Let’s assume we’ve identified a PGN (e.g. 61444) based on a raw 29 bit message ID (e.g. 0x0CF00401).
For a given entry of this message ID, we also logged 8 bytes of raw data - now, how do we interpret and convert this?
Here we need to look at the SPN, which reflects the ID of a specific parameter contained within the data bytes of a given PGN.
For example consider SPN 190, Engine Speed, mentioned in the previous example (cf. below).
For simplicity, let’s assume we’re only interested in converting and analysing this particular parameter.
In that case we see from the PGN info that relevant data is in byte 4 and 5, i.e. 0x6813. Taking the decimal form of 0x1368 (Intel byte order), we get 4968 decimal. To arrive at the RPM, we conduct a scaling of this value using the offset 0 and the scale 0.125 RPM/bit.
The result is 621 RPM.
Note how some data bytes in the above are FF or 255 decimal, i.e. not available. While the PGN may support SPNs in this range, this specific application does not support these parameters.
In practice, one will of course not do manual lookups in the J1939-71 documentation!
Rather, most use software that can load J1939 DBC files for converting logged or streamed data. In a DBC context, PGNs are called “Messages” and SPNs are called “Signals”. For more on this, check out our DBC conversion article which uses SAE J1939 as a case example.
SOUNDS EASY! ISN’T J1939 MORE COMPLEX?
The SAE J1939 protocol supports a number of more advanced operations. These include requests, multi-packet messages, multiplexing and more. Below we cover some of these.