Are J1939 messages really that simple?
Not completely: The above is a bit simplified as the J1939 29-bit identifier can be broken further down. 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).
For more on this, we host a popular online converter that lets you convert CAN IDs to PGNs - and see the formulas behind the PGN sub component calculations. This is quite educational and also useful if you're interested in J1939 DBC files.
Check it out!
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:
The SPNs of a J1939 message reflect parameters - such as speed and RPM.
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. 0x68 and 0x13. 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.
Using a DBC to Convert J1939 Raw Data
In practice, you won't sit and lookup the J1939-71 docs!
Rather, most utilize software that can load J1939 "DBC" files to convert logged or streamed J1939 data.
In a DBC context, PGNs are often 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.
Further, if you lack an up-to-date J1939 DBC file, you can get a low cost up-to-date version below:
Advanced: J1939 Request & Multi-Packet Messages
The SAE J1939 protocol supports a number of more advanced operations. These include requests, multi-packet messages, multiplexing and more. For a light intro to these concepts, click to expand the below:
Most J1939 messages are broadcast to the CAN bus, but some need to be requested. This is achieved using the ‘request message’ (PGN 59904), which is the only J1939 message with only 3 bytes of data. It has priority 6, a variable transmit rate and can either be sent as a global or specific address request. The data bytes 1-3 should contain the requested PGN (Intel byte order). Examples of requested J1939 messages include the diagnostic messages (DM). As for OBD2, you can use our Transmit feature to set up SAE J1939 request messages.
The PGN & SPN examples are based on a J1939 message of 8 data bytes, which is the size of most messages.
However, two other possible sizes exist: The 3 bytes request message above - and variable size messages.
The latter allows communication of data packets beyond the usual 8 bytes limit of the CAN bus format.
These are referred to as J1939 multi-frame or multi-packet messages. The J1939 protocol specifies how to deconstruct, transfer and reassemble the packets - a process referred to as the Transport Protocol (cf. J1939-21). Two types exist:
- The Connection Mode (intended for a specific device)
- The BAM (Broadcast Announce Message) which is intended for the entire network.
In simple terms, the BAM works by the transmitting ECU sending an initial BAM packet to set up the transfer.
The BAM specifies the multi-packet PGN identifier as well as the number of data bytes and packets to be sent. It is then followed by up to 255 packets of data. Each of the 255 packets use the first data byte to specify the sequence number (1 up to 255), followed by 7 bytes of data. The max number of bytes per multi-packet message is therefore 7 bytes x 255 = 1785 bytes. The final packet will contain at least one byte of data, followed by unused bytes set to FF. In the BAM type scenario, the time between messages is 50-200 ms. Finally, a conversion software can reassemble the multiple entries of 7 data bytes into a single string and handle it according to the multi-packet PGN and SPN specifications.