The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss.

The main document describing the J1939 message format is SAE J1939/21 – Data Link Layer. J1939/21 defines the use of the CAN data frame (29-bit identifier, Parameter Group Numbers – PGN, etc.) and the transport protocol functions, i.e. a definition of how messages longer than the standard CAN data length (8 bytes) are transmitted in a J1939 bus network.

Without further ado, the J1939/21 document, assuming that the reader has already studied all applicable publications and knows what Parameter Groups are, jumps immediately into the detailed architecture of Parameter Group Numbers. It is like explaining the function of an automobile by starting with the details of the gas injection system. The document is poorly written and lacks any structure.

For instance, the mere fact that some J1939 messages may be longer than the standard CAN message of 8 bytes is mentioned in numerous chapters without offering any substantial details on how the messages are packetized. In the same spirit, topics like, for instance, PDU Format are explained repeatedly, spanning over several chapters.

Most irritating, however, is the fact that the SAE engineers who created the standard are inconsistent with the use of the unit of time, “ms” or “msec” (milli-seconds). Instead they used mS, which is officially milli-Siemens (electric conductance, equal to inverse Ohm - Ω). The argument that milli-Siemens is part of the metric system does not stick, since the SAE J1939 standard uses metric units, for instance, for speed (km/h).

Extended Message Identifier

J1939 uses only the CAN 29-Bit message identifier (In fact, the CAN standard was extended from 11 to 29 bit per request by the SAE in order to support J1939). J1939 uses the identifier, among other features, to identify the source and, in some cases, the destination of data on the bus.

The CAN standard in itself does not support node (ECU) addresses, only message IDs. The sender of message is not concerned with who receives the data, while the receiver does not know who sent the data. The receiver knows the meaning of the data by looking at the message ID. The SAE J1939 Standard ingeniously uses the 29-Bit message identifier to include a source address and, depending on the operating mode, the destination address.

The 29 bit message identifier consists of the regular 11 bit base identifier and an 18 bit identifier extension. The distinction between CAN base frame format and CAN extended frame format is accomplished by using the IDE bit inside the Control Field. A low (dominant) IDE bit indicates an 11 bit message identifier, a high (recessive) IDE bit indicates a 29 bit identifier.

An 11 bit identifier (standard format) allows a total of 2¹¹ (= 2048) different messages. A 29 bit identifier (extended format) allows a total of 2²⁹ (= 536+ million) messages.

The above picture shows a comparison between a standard CAN data frame with an 11-Bit identifier and a CAN data frame in extended format (29-Bit identifier). Both frames contain an Identifier Extension Bit (IDE), which is at low level for the standard frame and at high for the extended data frame. CAN controllers must be designed in a way that they check the IDE in order to distinguish between the two possible frame formats.

While the standard J1939 protocol utilizes the CAN 29-Bit identifier, it nevertheless does allow the sharing of the network with devices that support the standard CAN 11-Bit message identifier. As a matter of fact, this feature is not specific to J1939, but the CAN protocol. SAE J1939 does, however, not provide any further definition on the use of the 11-Bit identifier.

Note: Both formats, Standard (11 bit message ID) and Extended (29 bit message ID), may co-exist on the same CAN bus. During bus arbitration the standard 11 bit message ID frame will always have higher priority than the extended 29 bit message ID frame with identical 11 bit base identifier and thus gain bus access.

In case where an application needs to use both formats, it is recommended to assign a specific priority to all 11-Bit ID messages that is not being used by the 29-Bit ID messages. This will prevent that any 11-Bit message overrides a 29-Bit message and (in the spirit of the overcautious SAE requirements) eliminate any potential for transmission failures.

Note: The Extended Format has some trade-offs: The bus latency time is longer (minimum 20 bit-times), messages in extended format require more bandwidth (about 20 %), and the error detection performance is reduced (because the chosen polynomial for the 15-bit CRC is optimized for frame length up to 112 bits).

SAE J1939 ECU Simulator Board With USB Port

The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. It allows any host device with a USB COM port to monitor SAE J1939 data traffic and communicate with the SAE J1939 vehicle network.

The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). It is also supported by an extensive programming interface for Windows and Linux/Ubuntu applications, including full C/C++/C# source code for short time-to-market developments.

The strength of the board lies in the fact that the entire SAE J1939 protocol, including all timing requirements, is stored on-chip, thus taking the burden off the main system. The board uses a USB COM port to communicate with the main system, i.e. all data transfer is handled through a standard COM port access. 

The communication protocol between the board and the main system is well documented and thus allows a porting to any computer system with a USB connection. Working source code libraries exist for Windows (C# under Visual Studio 2012/2013), Linux and its derivatives (C++ using Code::Blocks), and Raspberry Pi (C using the standard gcc compiler).

More Information...