SAE J1939 is a well-known protocol used in heavy-duty vehicles to define the way Electronic Control Units (ECUs) communicate through the CAN bus. The SAE J1939 protocol has gained wide acceptance due to its excellent performance, reliability, and ability to handle complex data transmission.
Similar to our previous post on the Controller Area Network (CAN) bus, we want to clarify how the SAE J1939 protocol works and give you all of the necessary details, regardless of whether you are new to it or looking for further information.
In this article, we will look at the difference between J1939 and CAN, as well as the benefits of employing the J1939 protocol. We will also go over the technical aspects of J1939, such as its code and performance data.
For your convenience, we have tried to make the explanation brief and uncomplicated. And at the end of this guide, you should be able to understand the purpose of J1939, how J1939 logging works, and how to decode data.
Additionally, we have added an SAE J1939 getting started guide at the bottom of this article.
What is J1939?
SAE J1939 is a protocol that was developed by the Society of Automotive Engineers (SAE) to standardize communication between ECUs in heavy-duty vehicles. It defines how these units communicate with one another and exchange information over the CAN bus.
One of the J1939 protocol's key advantages is its ability to handle complicated data transmission. It establishes a common protocol for data transmission across multiple ECUs, making it easier for engineers to create and incorporate new technologies into vehicles. Moreover, J1939 is extremely dependable and can resist the harsh environments found in heavy-duty vehicles.
When compared to other protocols like CANopen, the J1939 protocol is more advanced and provides a higher level of functionality. It supports a wider range of data rates from 250 kbps to 1 Mbps and uses a 29-bit identifier, which provides a larger address space for identifying different messages.

Key facts about SAE J1939
-
Used in heavy-duty vehicles
-
Uses 29-bit extended CAN identifier
-
Developed by the Society of Automotive Engineers (SAE)
-
Data rate from 250 kbps to 1 Mbps
-
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 numbers (SPNs)
J1939 vs. CAN: Which is Better?
While J1939 is a more advanced protocol than CAN, there are still some situations where CAN may be a better choice. For example, in applications where data transmission requirements are not as complex, CAN may provide sufficient performance at a lower cost.
Additionally, CAN is often used in applications where the network size is smaller and where reliability is less of a concern.
However, in most heavy-duty vehicle applications, J1939 is the preferred protocol due to its advanced functionality and reliability. J1939 can handle complex data transmission requirements, while also providing the necessary performance and reliability to operate in harsh environments.
J1939 Code and Performance Metrics
As we mentioned before, J1939 uses a 29-bit identifier that includes several fields for controlling messages' priority and destination.
The first 3 bits of the identifier control message priority during arbitration, with the highest priority having a value of 0. Typically, high-speed control messages are given higher priority, such as the torque control message from the transmission to the engine. Messages with lower priority values are those that are not time-critical, such as road speed.
The next 1 bit of the identifier is reversed for future use and is set to 0 for transmitted messages. After that, the next 1 bit is the data page selector, which expands the number of Parameter Group Numbers (PGNs) that can be used.
The Protocol Data Unit (PDU) format determines whether the message is transmitted with a destination address or as a broadcast message. The PDU-specific (PS) field is used to address messages and changes according to the PF value. If the PF is between 0 and 239, the message is addressable (PDU1) and the PS field includes the destination address. If the PF is between 240 and 255, the message can be broadcast (PDU2), and the PS field includes a group extension.
The J1939 protocol supports several message types, including broadcast, point-to-point, and global messages. Broadcast messages are sent to all ECUs on the network, while point-to-point messages are sent directly between two ECUs. Global messages are used to configure and control the network itself.
The J1939 protocol also supports several types of message filtering, including source address filtering, message ID filtering, and parameter group filtering. These filters help to reduce the amount of data traffic on the network, improving overall performance and reducing the risk of data collisions.
J1939 performance metrics include message latency, which is the time it takes for a message to be transmitted and received, and bus utilization, which is the percentage of time that the network is being used for transmitting data.
By understanding these metrics and using appropriate filtering techniques, it is possible to optimize the performance of a J1939 network.
SAE J1939 request message: How to retrieve diagnostic data on heavy-duty vehicles
While most J1939 messages are broadcasted via the CAN bus, some are only sent upon request. These "on request" data typically include J1939 diagnostic trouble codes (DTCs).
To send a J1939 request via the CAN bus, a special request message is used (PGN 59904). This is 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, which also includes J1939 DM2 diagnostic messages.
The J1939 request message is used to request information from an ECU that has the requested information available. This message is typically sent by a diagnostic tool or a monitoring system. When an ECU receives a request message, it checks if it has the requested information. If it does, the ECU responds with the requested information in a separate message, using the PGN specified in the request message.

Suspect Parameter Number (SPN) in CAN Networks
SPN is a term commonly used in the field of vehicle diagnostics and CAN bus communication. It is an identifier for CAN signals that are contained in the data bytes of a CAN message. In the context of J1939, SPNs are grouped by Parameter Group Numbers (PGNs) and are used to represent various data such as engine speed, temperature, oil pressure, etc.
The SPN is used to identify a specific data signal, and can be described by its bit start position, offset, unit, and bit length. This information allows the receiver to properly interpret the data and extract the relevant information from the CAN message.

Understanding PGN Message Board in SAE J1939
The PGN (Parameter Group Number) is a unique frame identifier in the SAE J1939 standard, which is used to group related data parameters and optimize message transmission. It composes an 18-bit subset of the 29-bit extended CAN ID.
The PGN can be broken down into four parts:
-
Data page (1-bit).
-
Reserved (1-bit).
-
PDU format (8-bit).
-
PDU specific (8-bit).
The PGNs are listed in SAE J1939/71 and ensure reliable and efficient communication between heavy-duty vehicles and their electronic systems.
PGN message boards message the transmission of J1939 messages over the network, ensuring messages are delivered to their intended recipients and maintaining network stability. By grouping related parameters into PGNs, it is possible to optimize message transmission and reduce network traffic.

Unlock the Power of Fleet Management with AutoPi Cloud
Discover the advantages of a comprehensive solution for remote vehicle monitoring, control, and optimization. Streamline your operations and enhance your bottom line by using real-time data tracking and automated software updates.
Start your journey to a smarter, more efficient fleet now!

SAE J1939 DBC Files for Heavy-Duty Vehicle Data Decoding
A J1939 DBC file is typically used to decode data across heavy-duty vehicles. Raw J1939 data can be recorded using a CAN bus data logger and then analyzed in software that supports DBC conversion. These files provide a standardized format for interpreting J1939 data and can help identify and troubleshoot issues with vehicle electronic systems.
The conversion of vehicle data using a DBC file typically results in a 40-60% conversion rate. The rest of the data requires reverse engineering, as it is OEM-specific and proprietary.
Understanding J1939 Connector Pinout
The J1939 connector has a specific design, with a round shape and 9 pins, and requires proper wiring and the right connector to connect an embedded system into a vehicle. Understanding the J1939 connector pinout is critical for anyone working with heavy-duty vehicles and their electronic system.
The J1939 connector pinout can be broken down as follows:
-
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, a new model of the J1939 connector has been introduced in a green color to replace the older version in black. The newer model comes with a higher reading capability of 500 kb/s to prevent any unnecessary damage to truck adapters and scanning tools, which was a high risk in the older version.
In addition to the connector, the J1939 protocol also includes a transport protocol for the transmission of large messages that are too big to fit into a single message frame. J1939's message filtering system allows ECUs to filter out unwanted messages and receive only relevant messages for their specific functions, which reduces the data traffic on the network and improves performance.

J1939 Transport Protocol (J1939 TP) and its Applications
As we have already determined, the SAE J1939 protocol is commonly used in heavy-duty vehicles for communication between electronic systems. And while the most common examples are PGN and SPN, there are also J1939 multi-frame messages that are sent through the J1939 transport protocol.
The J1939 transport protocol defines how to deconstruct, transfer, and reassemble packets across frames. There are two types of J1939 TP:
-
Broadcast Announce Message (BAM) for an entire network
-
Connection mode for a specific device
When transmitting data, the transmitting ECU sends an initial BAM packet to arrange a data transfer. The BAM defines the PGN identifier for the multi-packet message, the number of data bytes, and packets to be sent. It is followed by up to 255 packets of data, with each packet using the first data byte to define the sequence number. The maximum number of bytes per multi-packet message is 7 bytes times (x) 255 = 1785 bytes.

Logging J1939 data is common in heavy-duty vehicles, especially for fleets, to improve efficiency and reduce costs. Live stream diagnostics can be performed using J1939 data, allowing technicians and mechanics to diagnose vehicle performance in real-time. Vehicle performance can be monitored via Wi-Fi CAN loggers, which gives the possibility to predict breakdowns using the J1939 protocol and data. J1939 TP can also be used as a vehicle Blackbox.
History of SAE 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 the J1939 standard
-
2001 - Former standards 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 SAE J1939 to SAE J1939 FD.
Do you operate within logging heavy-duty vehicles and are you looking for an additional team player? We can help you with SAE J1939 logging data and your project. Contact our sales department to get in touch with us.