J1939 Data Link Volvo

[Timothee Cazares]

Ihave a listen-only device plugged into SAE J1939 data link in Volvo FH440 (2014). So far I managed to collect HRLFC, TCO1 and some other, but no Dash Display (PGN 0xFEFC). I collected data in stationary conditions (no vehicle motion, ignite on), so far I had no opportunity to collect them during motion, but judging by the fact that other PGNs are reported normally I would expect this one too.

Been working with similar model Volvos, but with the body builder module outputI had a quick look and DD is part of the FMS standard, however volvo doesn't always broadcast all of the values they specify, (the FM/FH seem to have 3 different groupings of what is available with no clear reasoning why)

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

Why I use a calculator to troubleshoot a J1939 data link, yes I said a calculator. Working for a major fleet as a Technician Instructor I have taught many courses. I have to teach everything on the vehicle from bumper to bumper, which could be 3 axle alignments to troubleshooting a data link. One of the most valuable things I will teach technicians is how to use a calculator to troubleshoot the J1939 in my Advanced Data Link and Fault Code Diagnostics Course.

This troubleshooting method will work for all truck makes but I will use a Freightliner Columbia in my example. The J1939 data link has two 120 ohm resistors in parallel in the data link. When the data link is in good condition the total resistance will be approximately 60 ohms on pins C and D of the 9 pin data link connector. When checking the J1939 on pins C and D make sure the ignition is off and no modules are communicating when you check the resistance.

What I see all the time are inactive codes in the ABS for J1939 time outs on Freightliner Columbia. The trucks that were checked had measurements that were about 65 to 68 ohms on pins C and D of the 9 pin data link connector. In most data link troubleshooting text books this is an acceptable measurement and falls within the 60 ohms + or - 10 ohms. My experience tells me there is a problem in the J1939 data link.

I have used this diagnostic method on many trucks: Volvo, ProStar and Freightliner. I would practice this on a good truck and you will see that using a calculator to calculate the resistance should match what your multi-meter shows you. You will repair many data link problems if you learn this method.

As explained in our CAN busintro, most vehicles today use the Controller Area Network (CAN) for ECU communication. However, CAN bus only providesa "basis" for communication - not a "language" for conversation.

The J1939-13 standard specifies the 'off-board diagnostic connector' - also known as the J1939 connector or9-pin deutsch connector. This is a standardized method for interfacing with the J1939 network of most heavyduty vehicles - see the illustration for the J1939 connector pinout.

As evident, the J1939 deutsch connector provides access to the J1939 network through pins C (CAN high)and D (CAN low). This makes it easy to interface with the J1939 network across most heavy duty vehicles.

Many of today's heavy duty vehicles have 2 or more parallel CAN bus networks andin some cases at least two of these will be available through the same J1939 connector. This also meansthat you will not necessarily have gained access to all the available J1939 data if you've onlyattempted to interface through the 'standard' pins C and D.

Note that the J1939 deutsch connector comes in two variants: The original black connector (type 1) andthe newer green connector (type 2), which started getting rolled out in 2013-14. Type 2 connectors arebackwards compatible.

J1939 type 2 femaleconnectors are physically backwards compatible, while type 1 female connectors only fit type 1male sockets. The type 2 connector was designed for the SAE J1939-14 standard, which adds support for500K bit rates. The purpose of "blocking" type 1 connectors is to ensure that olderhardware (presumably using 250K bit rates) is not connected to type 2 500K bit rate J1939 networks.Specifically, the physical block is through a smaller hole for pin F in the type 2 male connectors.

The J1939 PGN comprises an 18-bit subset of the 29-bit extended CAN ID. ThePGNserves as the unique frame identifier within the J1939 standard - meaning that the rules for decoding rawJ1939 dataare specified at PGN level, rather than 29-bit ID level.

Notice how EEC1 is PDU2 as the PDU Format is 240, while HVESP3C1 is PDU1 as the PDU Format is 44 (and hence below240). For EEC1, the PDU Specific (PS) field is 4 throughout, which will be the case for any 29-bit CAN ID thatmapsto the EEC1 PGN. Here, the value 4 reflects the Group Extension. In contrast, the PDU Specific (PS) field variesacross the three 29-bit CAN IDs that map to theHVESP3C1 PGN. The different PS values reflect different destination addresses.

Distinguishing between PDU1 and PDU2 is e.g. relevant when using J1939 PGN masks in the configuration of CANedgeIDfilters. Here, a mask of 3FFFF00 can be used for PDU2, while a mask of 3FF0000 must be used for PDU1.

The J1939 SPN serves as the identifier for the CAN signals (parameters) contained in thedata payload. SPNs are grouped by PGNs and can be described in terms of their bit start position, bitlength,scale, offset and unit - information required to extract and scale the SPN data to physical values.

At CSS Electronics, we collaboratewith SAE to transform the J1939 DA into a J1939 DBC file with 1,800+ PGNs and10,000+ SPNs. This conversionis done quarterly with each new J1939 DA revision. The J1939 DBC file can be used in CANsoftware/API tools to enable easy decoding of raw J1939data.

To send a J1939 request via the CAN bus, a special 'request message' is used (PGN 59904),which is theonly J1939 message with just 3 data bytes. The data bytes contain the requested PGNin Intel byte order.

To show how this works, let us consider a real-life example. Here, an engineer is using the CANedge torequest dataon the PGN HOURS (0xFEE5 i.e. 65253), which includes the SPN 'Engine Total Hours of Operation' (often usedin e.g.telematics).

In practical applications, you will typically not know the source address of the ECU you're looking to requestdata from. For example, if you are looking to extract HOURS across 5 different heavy-duty trucks, the simplestsolution is to simply use the 0xFF global request - at least during initial exploration.

Many practical J1939 buses use fixed source addresses, meaning that you can use a two-step process: First youidentify the source address of the responding ECU(s) via the global request - and once the address is known, youswitch to the specific request method. This can be preferable, e.g. if multiple ECUs respond with identical datawhen you perform the global request. Here, using specific requests helps reduce busload and log file size.

Note also that we use a source address of 0xFA for the CANedge in the trace example. This is somewhat arbitrary:Industry conventions typically recommend that 3rd party tools use a source address in the 'upper range' (e.g.0xFA-0xFF), though the J1939 standard does not dictate a specific address. The source address used in therequest ID will not affect the results, but it is considered good practice to use a unique source address ifpossible.

Sending request messages is typically key to requesting J1939 codes and thus J1939 diagnostics. Onechallenge, however, is that J1939 loggers are often required to have a contactless connection to theJ1939 data link, meaning that they're unable to interact with the CAN bus and transmit J1939 requestframes. The restriction is often related to warranty compliance as some vehiclemanufacturers do not allow direct access by 3rd party devices via the J1939 connector.

In some cases, it is required that the J1939 analyzer is "physically" contactless, e.g. via a contactlessCANreader. In other cases, it is sufficient that the J1939 logger operates in "configurable"silent mode. The latter makes it easier to perform ad hoc requests for J1939 fault codes, either viaamanual configuration update or via an over-the-air update for the CANedge2.

Some message payloads exceed 8 bytes - for example ECU software updates, vehicle configurations or diagnostic troublecodes (DM1). Tocommunicate such payloads it is necessary tosplit the data across multiple CAN frames. The receiving node must then subsequently reassemble the individual datapackets.

The transmitting node initiates a connection via a Request To Send (RTS) message. Subsequent communication iscontrolled by the receiver through Clear To Send (CTS) messages, ending with a End of Message Acknowledge(EoMA) message.

The transmitting node initiates the communication with a Broadcast Announce Message (BAM, PGN 0xEC00 i.e.60416) followedby a number of Data Transfer (DT, PGN 0xEB00 i.e. 60160) messages. The receiving node does not exert anycontrol.

The TP.CM payload contains a control byte that differs depending on the type of message (it is e.g. 0x20for the BAM message). The payload also contains the number of databytesandpackets to be sent and the PGN of the multi-packet message (Intel byte order)

In the BAM protocol, the TP.CM message is followed by up to 255 packets of data in TP.DT messages. The TP.DTmessageusesthe 1st byte as a sequence counter (1 to 255), while the remaining 7 bytes contain the segmented datapayload. As a result, a single J1939 TP sequence can carry up to 7 x 255 = 1785 data bytes.

Above, the last 3 bytes of the BAM equal E3FE00. When reordered, these equal the PGN FEE3 aka EngineConfiguration 1 (EC1). Further, the payload is found by combining the the first 39 bytes across the 6 datatransfer packets/frames.

Note: The last 3 data payload bytes in this practical example happen to be FF, yet we still include theseinthe payload as the BAM message specifies the data length to be 39. The final 3 FF bytes in the 6thpacketare unused/invalid.

3a8082e126