Site Information

 Loading... Please wait...

Blog

SAE J1939 Transport Protocol (TP) Functions

Posted by Wilfried Voss on

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

A Comprehensible Guide to SAE J1939

Even though extremely useful in passenger cars and small industrial applications, CAN alone was not suitable to meet the requirements of truck and bus communications, mainly since its communication between devices is limited to only 8 bytes per message. However, it is possible to extend the size of a CAN message by implementing additional software, i.e., so-called higher layer protocols. J1939 is such a higher-layer protocol, and it supports up to 1785 bytes per message.

To support a size of more than 8 bytes, the message needs to be packaged into a sequence of 8-byte size messages. Consequently, the receiver of such a multi-packet message must re-assemble the data. Such functions are defined as Transport Protocol (TP) Functions, and they are also described in SAE J1939/21. The two major parts of the TP Functions are Message Packaging & Reassembly and Connection Management. Also, the Transport Protocol Functions handle flow control and handshaking features for destination-specific transmissions.

Message Packaging and Reassembly

Certain parameter groups may require more than the 8 data bytes supported by the CAN standard. The SAE J1939 standard, namely the Transport Protocol Function, supports message lengths up 1785 bytes. In case a program group requires more than 8 data bytes (9…1785 bytes) and is defined as multi-packet capable, the data will be packaged into a series of CAN data frames.

In order to package CAN messages into a sequence of up to 1785 messages (as well as to re-assemble the CAN frames into one data package) the J1939 Transport Protocol defines the following:

  1. Each multi-packet message is being transmitted by using a dedicated Data Transfer PGN (60160, TP.DT = Transfer Protocol Data Transfer), i.e. all message packets will have the same ID.
  2. The flow control is managed by another dedicated PGN (60146, TP.CM = Transfer Protocol Communication Management).
  3. The message length must always be 8 bytes (DLC = 8).
  4. The first byte in the data field contains a sequence number that ranges from 1 to 255.
  5. The remaining 7 bytes are filled with the data of the original long (> 8 bytes) message.
  6. All unused data bytes in the last package are being set to FFhex.

The actual total message length is defined by the corresponding Parameter Group (See also chapter Multi-Packet Broadcast).

The method of using a sequence number plus the remaining seven data bytes yields a total of (255 packages times 7 bytes/package) 1785 bytes per multi-packet message.

The following pictures demonstrate the use of the CAN data field, including the sequence number and the packaging of multiple CAN messages.

CAN Data Frame with Sequence Number

CAN Data Frame with Sequence Number

Example of Multi-Package Sequence

The data packages are re-assembled in the order of their sequence number and the final data package can then be passed to the application layer.


SAE J1939 ECU Simulator Board With USB Port

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...

SAE J1939 Programming with Arduino – RTS/CTS Session Message Timing

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Note the time stamps from line 3 through line 5 of the screen shot (look at the last four numbers indicating the time in tenth of milliseconds; for instance 352.4 milliseconds in line 3). SAE J1939/21 requires a packet frequency between 50 [...]

Read More »


SAE J1939 Programming with Arduino - Transport Protocol – RTS/CTS Session (SAE J1939/21)

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Test items include: Basic function Timing controlNaturally, for the RTS/CTS session we will need two SAE J1939 nodes. In my setup that means communication between the Arduino Uno and the Mega 2560 ECUs. [...]

Read More »


SAE J1939 Programming with Arduino - BAM Session (SAE J1939/21)

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Test items include: Basic function Timing controlThe initial test of the BAM session requires only one ECU, in this case I am using the full protocol running on the Arduino Mega 2560 [...]

Read More »


SAE J1939 Programming with Arduino - Sending and Receiving Messages

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Proving the capability of the most basic task of sending and receiving regular 8-byte (CAN) messages must be seen as an unnecessary test, since that had already taken place in previous chapters. Things change, however, with the transmission and reception of J1939 [...]

Read More »


SAE J1939 Programming with Arduino - Multi-Packet Peer-to-Peer (RTS/CTS Session)

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. The communication of destination specific (peer-to-peer) multi-packet messages is subject to flow-control. Connection Initialization – The sender of a message transmits a Request to Send message. The receiving node responds with either a Clear [...]

Read More »


SAE J1939 Programming with Arduino - SAE J1939/21 - Transport Protocol (TP)

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Even though extremely effective in passenger cars and small industrial applications, the CAN Bus technology alone was not suitable to meet the requirements of truck and bus communications, especially since its communication between devices is limited to only 8 bytes per message. [...]

Read More »


SAE J1939 Programming with Arduino - Multi-Packet Broadcast (BAM Session)

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. In order to broadcast a multi-packet message, a node must first send the Broadcast Announce Message (BAM), which contains the following components: Parameter Group Number (PGN) of the multi-packet message Size of the multi-packet message Number of packagesThe BAM message allows all [...]

Read More »


SAE J1939 Programming with Arduino - The Two Elements of the SAE J1939 Protocol Stack

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Any SAE J1939 hardware must support SAE J1939/1x and SAE J1939/21, otherwise they’re useless, because these standards describe the CAN Bus physical layer and the basic protocol features. That part is sufficiently covered (i.e. for demonstration purposes) by our CAN Bus [...]

Read More »