YTread Logo
YTread Logo

J1939 Explained - A Simple Intro (2020)

Jun 04, 2021
SAE J1939 is a key protocol in CAN bus data logging; However, it is difficult to find a really


and understandable


duction to J1939. But we've added the secret sauce: we've asked one of our non-engineers to write this article, and if he gets it, you'll get it! In this article, we cover: J1939 basics and applications Interpreting J1939 messages (PGN, SPN) Five practical considerations for logging J1939 data After this, you should be ready to log and convert J1939 raw frames into machine-readable data. humans. Let's dive in! WHAT IS SAE J1939? As evident from our


duction to the CAN bus, virtually all current vehicles use the Controller Area Network (CAN bus) protocol as the basis for communication between ECUs.
j1939 explained   a simple intro 2020
However, the CAN bus simply provides a communication tool (i.e. like a telephone), not a "language" that allows more complex operations. On most commercial vehicles, this language is the SAE J1939 standard defined by the Society of Automotive Engineers (SAE). In summary, J1939 provides a higher layer protocol (HLP) that uses CAN as a physical layer base. In


terms, this means that J1939 offers a standardized method for communication between ECUs, i.e. one language for all manufacturers. In contrast, passenger cars often rely on manufacturer-specific protocols. Heavy vehicles (e.g. trucks and buses) are one of the most well-known applications.
j1939 explained   a simple intro 2020

More Interesting Facts About,

j1939 explained a simple intro 2020...

However, many other key industries today take advantage of SAE J1939, either directly or through derived standards (e.g. ISO 11783, MilCAN, NMEA 2000, FMS): Forestry machinery (e.g. delimbers, forwarders, skidders, .. .) Mining vehicles (e.g. bulldozers, draglines, excavators,...) Military vehicles (e.g. tanks, transport vehicles,...) Agriculture (e.g. tractors, combine harvesters,...) Construction (e.g. e.g. mobile hydraulic systems, cranes,...) Fire and rescue (e.g. ambulances, fire trucks,...) Many others (e.g. ships, pumping, power generation,...) From a From a data logging perspective, SAE J1939 provides an overlay for CAN that includes a set of standardized messages and conversion rules that apply across a wide range of vehicles within the aforementioned areas.
j1939 explained   a simple intro 2020
For this reason, a good understanding of J1939 is essential, e.g. Building fleet management systems. In terms of the history of J1939, the original top-level SAE J1939 document was published in 2000, although some of the underlying documents were already published in 1994 (J1939-11, J1939-21, J1939-31). The SAE J1939 standard has replaced the old SAE J1708 and SAE J1587 standards. Today, we see massive growth in IoT (Internet of Things) and transportation will be a key area of โ€‹โ€‹application. This can likely be achieved through scalable fleet solutions using affordable WiFi data loggers, but the heart of such applications will be the SAE J1939 protocol.
j1939 explained   a simple intro 2020
In other words, the importance of the standard will only grow in the future. PLEASE EXPLAIN THE BASICS OF J1939 MORE. Let's get a little more technical: To understand a higher layer protocol like J1939, think that the CAN standard provides only the basic physical layer and the data link layer, that is, the two lowest layers in the seven-layer OSI. model. Together they offer the basic means of communicating small packets over the CAN bus, but not much more than that. So what is a higher layer protocol? A higher layer protocol is required to enable communication across large, complex networks, for example. vehicle manufacturers.
Let's take an example: SAE J1939 specifies how to handle multi-packet messages, that is, when data larger than 8 bytes needs to be transferred. Similarly, it specifies how data should be converted into human-readable data. It does this by providing a family of standards. For example, J1939-71 is a document that details the information needed to convert a large set of standardized J1939 messages between manufacturers into human-readable data (more on this below). There are several other examples of CAN-based upper layer protocols, incl. CANopen, DeviceNet, Unified Diagnostic Services and more. They typically offer some level of standardization within their respective industries, although all can be expanded upon by manufacturers.
In comparison, the passenger cars mentioned above have unique standards per manufacturer. In other words, you can use the same J1939 database file to convert e.g. engine speed on two trucks from different manufacturers, but you cannot, for example, read data from an Audi A4 using the same ID and scaling parameters as for a Peugeot 207. Before continuing, it is worth noting some key features from SAE J1939: The speed is usually 250 kbit/s, although recently with support for 500 kbit/s J1939 uses CAN 2.0B, that is, a 29-bit extended identifier. Messages are identified by PGN (Parameter Group Numbers), which comprise 18 of the 29-bit identifiers.
Therefore, a PGN will contain several SPNs (Suspicious Parameter Numbers) in The 8 bytes of data reflecting parameters (e.g. RPM) J1939 includes a wide range of standard PGNs, although PGNs 00FF00 to 00FFFF are reserved for proprietary use. . A data byte of 0xFF (255) reflects N/A data, while 0xFE (254) reflects an error Multibyte variables are sent least significant byte first (Intel byte order) J1939 supports PGN with up to 1785 bytes using one protocol transport HOW TO READ THE J1939 MESSAGE FORMAT? If you are using this article, your ultimate goal is likely to analyze SAE J1939 data converted to a human-readable format.
To do so, it is key to understand how to interpret raw SAE J1939 packets; here we provide the basics including. PGN and SPN. PARAMETER GROUP NUMBER (PGN) Let's start with the SAE J1939 identifier, the PGN: A PGN acts as a unique identifier to look up the function of a J1939 message and the associated data parameters (i.e., SPNs). You can find this information in the SAE document J1939-71, which provides lists of PGN and SPN, as well as information on how to interpret and convert the data. For an illustration of what the different PGN names might look like, cf. our J1939 PGN list.
One caveat: you can't match PGNs to the full 29-bit CAN identifier. Instead, you need to separate the 18-bit PGN as shown below. Tip: If in doubt, use our online J1939 PGN converter to parse a full 29-bit J1939 message ID and get the PGN in decimal format. Example: Suppose we log a J1939 message with the extended identifier 0x0CF00401. To obtain the PGN, we create the ID starting at bit 9 with length 18 (indexed from 1), or apply the HEX mask 0x03FFFF00, which leads to the same result. The result is PGN 0x0F004 or in decimal 61444. Looking for this in the SAE J1939-71 documentation, we see that it is Electronic Engine Controller 1 - EEC1.
Additionally, the document will have details about the PGN, including priority, baud rate, and a list of associated SPNs. For this PGN, there are seven SPNs (e.g., engine speed, RPM), each of which can be searched in J1939-71. documentation for more details. That seems simple enough, right? However, note that the above is a bit simplified as the 29-bit J1939 identifier can be broken down into subcomponents. Specifically, the ID comprises Priority (3 bits), PGN (18 bits), and Source Address (8 bits). In addition, the PGN can be divided 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 recording perspective and will not be discussed here to avoid confusion. SUSPICIOUS PARAMETER NUMBER (SPN) You may be wondering, "Are PGNs the data parameters I'm looking for?" Not quite. That's where SPNs come in: Let's say we've identified a PGN (for example, 61444) based on a 29-bit raw message ID (for example, 0x0CF00401). For a given entry of this message ID, we also record 8 bytes of raw data. Now how do we interpret and convert this? Here we must 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 example above. For simplicity, let's assume that we are only interested in converting and parsing this particular parameter. In that case, we see in the PGN information that the relevant data is in bytes 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 scale this value using offset 0 and scale 0.125 RPM/bit. The result is 621 RPM. Please note that some data bytes in the above are FF or 255 decimal, i.e. not available. While the PGN can support SPNs in this range, this specific application does not support these parameters.
In practice, of course there will be no manual searching of the J1939-71 documentation! Rather, most use software that can load J1939 DBC files to convert recorded or transmitted data. In a DBC context, PGNs are called Messages and SPNs are called Signals. For more information on this, see our article on DBC conversion using SAE J1939 as a case example. IT SOUNDS EASY! ISN'T J1939 MORE COMPLEX? The SAE J1939 protocol supports several more advanced operations. These include requests, multi-packet messages, multiplexing, and more. J1939 REQUEST MESSAGES Most J1939 messages are transmitted to the CAN bus, but some must 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 baud rate, and can be sent as a global or specific address request. Data bytes 1 through 3 must contain the requested PGN (Intel byte order). Examples of requested J1939 messages include diagnostic messages (DMs). As for OBD2, you can use our Broadcast function to configure SAE J1939 request messages. J1939 MULTIPACKET MESSAGES The PGN and SPN examples above are based on a J1939 message size of 8 bytes of data, which will be the case for most messages. However, there are two other possible sizes: the 3-byte request message above and variable-size messages.
The latter is used in the J1939 standard to allow communication of data packets beyond the usual 8-byte limit of the CAN bus format. These are known as multi-frame or multi-packet J1939 messages. J1939 specifies how to deconstruct, transfer, and reassemble packets, a process called the Transport Protocol (cf. J1939-21). There are two types: Connection Mode (intended for a specific device) and BAM (Broadcast Announcement Message) which is intended for the entire network. In simple terms, BAM works when the transmitting ECU sends an initial BAM packet to set up the transfer. The BAM specifies the multi-packet PGN identifier as well as the number of bytes and data packets to be sent.
This is then followed by up to 255 data packets. Each of these 255 packets uses the first byte of data to specify the sequence number (1 to 255), followed by 7 bytes of data. Therefore, the maximum number of bytes per multipacket message is 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 to 200 ms. Finally, a conversion software can reassemble the multiple 7-byte data entries into a single string and handle it according to multi-packet PGN and SPN specifications. HOT TIPS FOR J1939 DATA LOGGING In closing, this section provides five considerations for choosing a J1939 data logger solution for your J1939 application.
Logger vs. Interface: First, consider whether you need a logger or an interface. Standalone CAN bus based J1939 data loggers allow you to collect data e.g. weeks or months of driving, depending on the size of the SD card. In contrast, a J1939 interface requires a PC to transmit or track data from the CAN bus in real time. The interface is e.g. useful for diagnostic purposes or event-based analysis. Some J1939 data loggers, such as the CLX000 CAN logger, function as interfaces to provide a two-in-one solution. Adapter cable: To connect your CAN bus analyzer to an SAE J1939 application (for example, a truck), you will need the appropriate adapter cable.
For the CLX000 CAN logger, we offer a D-SUB 9 to J1939 connector (Deutsch connector, 9 pin). WiFi โ€“ For vehicle fleet management at scale, WiFi can be a useful upgrade to allow remote access to recorded data and/or send the data to an ftp/cloud server for further processing. If the objective is to analyzeJ1939 data from, p. a large fleet of trucks on a daily or weekly basis, a WiFi solution is ideal (e.g. CAN logger CL3000). However, in cases where the J1939 registrar acts as e.g. If there is a black box and data recovery is rarely necessary, a more affordable solution may work (e.g.
CL2000 CAN logger). Software: When recording or transmitting J1939 data, software for post-processing is key. In particular, the software must support DBC-based data conversion to enable rapid access to human-readable data. Our free CANvas software allows DBC conversion of, for example, DBC files. J1939, while the free Wireshark plugin allows DBC conversion of live streamed data. Advanced Features: To optimize J1939 data logging, several features may be useful. For example, cyclic logging allows you to automatically overwrite old log files. This is practical, e.g. purpose of black box recorder where the J1939 data logger may need to continue recording for months or years until a problem occurs.
Another useful feature is message filtering, which allows you to avoid logging specific parameters to save space. Finally, to access request-dependent J1939 messages, the J1939 logger must be able to transmit message requests. The CLX000 CAN logger supports these functions along with e.g. heartbeat signal, runtime register control and more. After all, J1939 is usually related to the registration of commercial vehicle fleet data. What does this imply? This makes price a fundamental factor. The CLX000 series CAN logger is a powerful solution for J1939 applications, but also one of the most affordable options. Price starts at 169 EUR with free shipping and free software.
If you are interested, please see our product page for more information. In case you are looking for more articles on CAN bus, OBD2, J1939, DBC and more, check out our Intel page. If you have any questions, please contact us; We aim to respond to you within 24 hours.

If you have any copyright issue, please Contact