J1939 is a CAN protocol defined by SAE (Society of Automotive Engineers) and is the basis for some other standards such as NMEA2000 for GPS data on CAN and ISO 11783 in agricultural machinery. It is also widely used in "off-the-shelf" Diesel engines.

The protocol consists of the following main elements:

•unique identification of each participant on the bus

•standardized message and number format for many automotive use cases

•means to transfer data > 8 bytes (i.e. longer than one CAN message)

These main components are described in the following sections.

Based on these definitions there are more pages describing

•basic settings to use J1939,

•creation of J1939 ECUs and variables and

•PGN mappings

in GUI tool to use J1939 on target display.

J1939 is defined to run on a CAN 2.0B network at 250 kBit/s i.e. it uses long (29 bit) CAN identifiers.

J1939 describes each signal (i.e. each value to be transmitted) as an SPN (Suspect Parameter Number).

Many SPNs are combined into a PGN (Parameter Group Number) which gets a unique number and describes what is actually transmitted on CAN bus.

Each PGN can be identified by the CAN identifier which has the following format (source: Wikipedia)

The last byte of this CAN ID always lists the source address of the message i.e. it identifies the ECU which sent this message.

The first three bits are always  considered priority based on CAN interpretation i.e. the lower value indicates higher priority.

Located between these two is the 18 bit PGN value consisting of

1.Bit 25 was "reserved" in the past but is meanwhile considered "Extended Data Page" (0 for most predefined PGNs)

2.Bit 24 defines the "data page"

   *not supported by our devices

3.Bits 23 ... 16 define the "PDU Format": If "PDU format" is less than 240 then "PDU specific" is 0 in the PGN definition and is replaced by the destination address in the CAN identifier (PDU1). If "PDU format" is greater or equal to 240 then "PDU specific" just extends the PGN number.

4.Bits 15 ... 8 are "PDU specific" and either define the destination address (PDU1) of the message or just extend the PGN number (PDU2).

Please note that the definitions above limit the number of valid PGNs:

PGN 0x000712 (==1810) is invalid since 0x07 == 7 is less than 240 and therefore the last byte has to be 0.

A valid PGN would be 0x000700.

Another side effect of the above definitions is that all PGNs with "PDU format" >= 240 are broadcasts because there is no room for a destination address in their CAN identifier.

J1939 typically transmits all values as unsigned with offset in metric units e.g. most temperatures are transferred in one byte with -40°C offset and 1°C/bit resolution. This means 50 is sent on CAN to indicate +10°C.

For most number formats the higher range is reserved and in almost every case "all bits set" indicates "invalid" or "don't care". I.e. in the example above one could not transfer temperature 215°C since the respective value on CAN would be 255 == 0xFF where all bits are set.

Value transmission of all standardized PGNs happens in "little endian" format i.e. "least significant byte first". Nevertheless some manufacturers use "big endian" format in their proprietary messages.

Every ECU on a J1939 network has to claim its own address. The address consists of one byte and either uses predefined suggestion from SAE, e.g. 0x00 for the engine ECU or is dynamically negotiated at runtime.

In static networks addresses can be pre-configured but should nevertheless be claimed. The tool allows to configure ECUs with static addresses where only the address is defined.

Alternatively addresses can be claimed dynamically i.e. each ECU claims an address and if there should be conflicts the one with the lower J1939 name wins.

J1939 name is a 64 bit number which is supposed to uniquely identify each ECU (at least on the network they are all connected to). It is sent as the data bytes of the address claim PGN 0x00EE00 == 60928. Since the fields of this 64 bit number are not byte aligned the address claim PGN can be considered a "worst case" scenario for little endian transmission.

J1939 transport protocol is used whenever the amount of data exceeds 8 bytes so that more than one CAN message is required to transfer them. J1939 transport protocol supports transferring up to 1785 bytes.

Our program automatically handles the transport protocol but requires all data transferred to be byte aligned in this case.