The same as we did in the CAN Bus article, we will try to explain how J1939 works and give you all the information you need, no matter if you are hearing about J1939 for the first time or you know exactly what it is, but want to get some additional info.
We have tried to write it in a very simple way, in order to make it as easy as possible for you. After reading the article, you will be able to understand what is J1939, how J1939 logging works and how to decode the data.
What is j1939?
J1939 or also known as the Society of Automotive Engineers (SAE) J1939 is a set of standards used in heavy-duty vehicles. The standard defines how ECUs communicate through the CAN bus.
Most of the heavy-duty vehicles use Controller Area Network for ECU communication, which is a basis of the communication, but not more than that. The actual language or system for conversation is the SAE J1939.
The J1939 uses the 29-bit identifier, which is described within the CAN 2.0B protocol. The J1939 also provides a higher layer protocol (HLP), which is based on the CAN physical layer.
Key facts about J1939
Used in heavy-duty vehicles
Uses 29-bit extended CAN identifier
Developed by the Society of Automotive Engineers (SAE)
Speed is usually 250 kbit/s or 500 kbit/s
Higher-layer protocol, built on CAN
Uses shielded twisted pair wire
J1939 messages identified by 18-bit parameter group number (PGN)
J1939 signals are called suspect parameter number (SPN)
J1939 message format
As we mentioned before, J1939 uses a 29-bit identifier. The first 3 bits of the identifier are being used to control priority of the message during the arbitration process. The highest priority has a value of 0.
Typically, high speed control messages are given higher priority. One of the examples can be the torque control message from the transmission to the engine. On the other side, messages that are given lower priority values are the ones that are not time critical, such as road speed.
The next 1 bit of the identifier is reserved for the future use and is set to 0 for transmitted messages. After that, the next 1 bit of the identifier is the data page selector, which expands the Parameter Group Numbers (PGNs).
The PDU format (PF) decides if the message can be transmitted with a destination address or the message is transmitted as a broadcast message.
The perception of the PDU specific (PS) field is changing according to the PF value. The message is addressable (PDU1) and the PS field includes the destination address if the PF is between 0 and 239.
On the other side, the message can be broadcast (PDU2) and the PS field includes a group extension if the PF is between 240 and 255.
The group extension enlarges the number of parameter groups that can be served by the identifier.
See the picture of a 29-bit identifier below.
Parameter group number (PGN)
The PGN is a unique frame identifier in the J1939 standard. The J1939 PGN composes an 18-bit subset of the 29-bit extended CAN ID.
The PGN can be broken into four parts:
Data page (1 bit)
Reserved (1 bit)
PDU format (8 bits)
PDU specific (8 bits)
Suspect parameter number (SPN)
The SPN is the identifier for the CAN signals that are contained in the databytes. Suspect parameter numbers are grouped up by parameter group numbers. They can be described based on their bit start position, offset, unit and bit length.
J1939 DBC file
A J1939 DBC data is typically used to decode data across heavy-duty vehicles. Raw J1939 data can be recorded with the help of CAN bus data logger and then analyzed in a software that supports DBC conversion.
The conversion of the vehicle data will be around 40-60%. The rest of the data requires reverse engineering being OEM specific proprietary.
J1939 request message
J1939 messages are typically broadcasted via CAN bus. However, some of them are only sent on request. Those ‘on request’ data usually include J1939 diagnostic trouble codes (DTCs).
A special request message is used (PGN 59904), when you want to send a J1939 request via CAN bus. That’s the only J1939 message with only 3 bytes of data and it has priority 6. The data bytes 1-3 should include the requested PGN that also includes J1939 DM2 diagnostic messages.
The J1939 connector has a quite specific design - round shape and 9 pins. In order to connect your embedded system into a vehicle, you need to have proper wiring and the right connector.
The actual picture of the J1939 connector pinout can be seen below with its pinout explanation.
Pin A - Battery -
Pin B - Battery +
Pin C - Can_H
Pin D - CAN_L
Pin E - CAN_SHLD
Pin F - SAE J1708 +
Pin G - SAE J1708 -
Pin H - Proprietary OEM use or implement bus CAN_H
Pin J - Proprietary OEM use or implement bus CAN_L
Since 2016, there is a new model in a green color. The previous older version was in a black color and in order to differentiate it, the newer model comes in a green color. If you have a black cable, it will not fit in the green J1939 connector.
The main reason to have the new version (green connector) is that not all truck adapters and scanning tools are capable of reading 500 kbs and there was a high risk of damaging the tool, truck or even both.
This new solution should in theory prevent any unnecessary damages and therefore, reduce costs.
We can basically compare it to the similar scenario with CAN bus. Classical CAN bus is slowly being replaced with faster CAN FD.
J1939 transport protocol (J1939 TP)
The most common examples are PGN and SPN that are based on J1939 messages with 8 data bytes. However, there are also >8 data bytes J1939 multi-frame messages that are sent through the J1939 transport protocol.
How does the J1939 transport protocol work?
Now, we are going to take a closer look at the process called J1939 transport protocol. The J1939 protocol defines how to deconstruct, transfer and reassemble packets across frames. We know two types of J1939 transport protocol (TP):
The Broadcast Announce Message (BAM) that is designed for an entire network
The connection mode that is designed for a specific device
Let’s imagine a scenario. A transmitting ECU will send an initial broadcast announce message (BAM) packet, to arrange a data transfer. The BAM will define the PGN identifier for the multi-packet message, number of data bytes and packets to be sent.
Afterwards, it is being followed by up to 255 packets of data and each of the 255 packets uses the first data byte, in order to define the sequence number.
It is then followed by 7 bytes of data and therefore, the maximum number of bytes per multi-packet message is 7 bytes times (x) 255 = 1785 bytes.
There are multiple common applications when it comes to logging of J1939 data. We will mention 4 of the most common applications below.
It is commonly used in heavy-duty vehicles, especially fleets, which can lead to improving efficiency and reducing costs.
Logging J1939 data also comes in handy when doing live stream diagnostics, which helps technicians and mechanics to do real-time diagnostics on vehicles.
Another example is that vehicles can be monitored via wifi CAN loggers, which gives them the possibility to predict breakdowns, with help of J1939 data.
It can also be used as a vehicle blackbox
History of J1939
1994 - First released docs were J1939-11, J1939-21 and J1939-31
2000 - The top level document was published
2000 - CAN became a part of J1939 standard
2001 - Former standards SAE J1708 and J1587 being replaced by J1939
We have seen an increase in the usage of heavy-duty telematics and we expect to increase even more. As manufacturers will most likely shift from a classical CAN bus to CAN FD, they will also shift from J1939 to J1939 FD.