As with PicoScope 7 Automotive's other Serial decoding tools, the CAN J1939 serial decoder converts CAN bus voltages to a readable form (typically hexadecimal but binary, decimal or ASCII formats are possible). However, the J1939 decoder is specifically built for decoding J1939 CAN protocol messages, specifically the ID.
What makes J1939 deserves its own decoder comes down to how the ID is formed and the amount of information contained within. To begin with, we need to understand how the message ID of a J1939 message is made up. The message header, ID, contains 29 bits which when translated into HEX giving us 4 bytes. These 4 bytes hold key information about the data contained within the CAN message payload. This ID can be broken down into 3 sections, Priority, Parameter Group Number (PGN) and the source address.
The PGN gives you a reference to the SAE J1939 standard’s Suspect Parameter Numbers (SPNs), where you can look up how to locate and scale/offset the data in the message payload. This is particularly useful if you need to check whether the data is valid but have no other way to access it. The important part though is to find the PGN in the header. To do this you take the two middle bytes in the ID as decoded from Pico, for example – 0C F0 04 00. The two middle ones are the important ones here which are F0 04. We now convert F004 into a decimal, and by using a programmer calculator in windows, we get the number 61444. A quick search through the SAE standards for PGN 61444 confirms to us that this is for the Electronic Engine Controller 1. Therefore, we can be confident that 0C F0 04 00 represented the Engine ECU or EEC1.
Diagnostically speaking, the Source Address can be even more useful. By using the global Source Address ID list in the SAE J1939-DA document it is possible to create a data-to-text description file and then selecting it in the decoder, the decoding table can display the descriptions of all the CAN controllers communicating on a network. This can tell you exactly which controllers are online, offline or might be causing network issues.
In addition to the CAN message parts that can be returned by a CAN serial decoder, the CAN J1939 serial decoder fully decodes the message identifier (ID) and splits it into its three constituent parts: the Priority, Parameter Group Number (PGN) and Source Address. When a suitable data-to-text file, relating the ID values to their descriptions, is supplied and selected, full-text descriptions of the PGN and Source Address are displayed in the decoding table.
In the above image you can see the clear difference between the conventional CAN decoder (1) and the J1939 decoder (2).
As mentioned above we can use the Data to Text, or Link file, function within the decoder to convert the decoded values into a readable format. To create a Link file, we must first create a template. On the decode table click Data to Text and then select Create template. This will then ask you to save a file to a location on the computer, my advice is to pick somewhere you can easily find. Once saved, locate this file and open with software capable of opening CSV files, typically Excel will work.
This CSV file acts like a lookup table with each column in the decode table now having another column labelled with description. I’ve highlighted the boxes of interest for visibility.
Here we can take the values we see in the J1939 decoded table and then give them a description. If you search on the internet there are a number of free resources containing a number of PGN’s and source address id’s so for an example I’ll demonstrate a common one found, Engine Controller 1. We have spoken in more depth around PGN’s and Source address in the following post - topic22271.html. For the full PGN list you will need to purchase this from the SAE.
A quick search on the internet found that Engine Controller 1 is given the PGN 61444. This is in fact a decimal number which can be converted back into HEX resulting in F004. Our decoder splits the values into HEX bytes which means F004 becomes F0 04. Therefore, we can insert our first ID into the Link file under the heading ID2 PGN and ID2 PGN Description.
For the source address description, all the ID’s can actually be found on the ISOBUS Data dictionary website - https://www.isobus.net/isobus/sourceAddress/index. This site does refer to the source address in the decimal format which in order for the look up table to work, you will need to convert the decimal back into HEX. Windows calculator has a handy programmer option which can handle this easily. One thing to bear in mind is that the source address ID can change depending on the industry type, this could be Industrial, On and Off Highway, Marine etc. The nice thing about the Link files is that you can create separate ones for each industry which might seem a little long winded but if you find you’re only interested in Off Highway for example you only need to do this for that type.
There are some common source addresses between all the different sectors and an easy example is ‘0’ for Engine #1. As with the PGN this in decimal form which when converted to HEX will appear as ‘00’ on the J1939 decode table in PS7. Excel doesn’t like leading zero’s which means for any single numbered source address ID, we have to convert them to text. Easily done in Excel by highlighting the cell, or cells, right click on the mouse and select format cells.
In the Format Cells dialog box, click Custom and then select ‘0’ from the list. In the box marked Type in another ‘0’ so the sample shows ‘00’ to add a leading zero. Click OK and then the cell or cells should now include a leading 0 which will match the decode table. Once completed the example Link file now appears like this.
Save this file and then close Excel. The link file feature with PicoScope will not function if the file is being used by another program.
Back in PicoScope 7 Automotive and with the decode table still active, click Data to text and then click Open. Use the file explorer to navigate to where the link file is saved and then select Open. PicoScope 7 Automotive will then apply the link file to the decode table where you will now see data now reading in a human readable format.
The link file would not be made as easy had it not been for the PS7 software team spending some time to create the J1939 decoder. Much thanks goes to them as I feel this will really help when dealing with J1939 issues where the scan tool has to go through a gateway of there is a bus overload issue and many others.
I hope this helps
As with everything in this modern world, nothing stands still for long! Thanks to the software development team at Pico, and I'm pleased to inform you that there has been a slight change to the J1939 decoder which makes life easier for us and is now technically correct according to the J1939 standard.
In our initial release of the decoder we split the header (ID) into 3 columns to create our priority, PGN and source address columns. Whilst this covered most PGN's and of course the source address, it wasn't technically correct. I refer to the image below which is taken from Kvaser's website - https://www.kvaser.com/about-can/higher ... roduction/.
As you can see the PGN is can also include 2 extra bits from the first byte. We also see that the Priority is only made up of 3 bits from the first byte. The changes to the decoder reflect this.
The spacing between the bytes seen in the PGN section has also been removed. This actually helps us as we can now let the software covert the PGN to a decimal for us allowing us to reference the PGN as it would be in the J1939DA document. This in turn allows us to create a link file much easier as we only have to use the decimal values.
By viewing the header ID as a decimal also helps us with the source address as we no longer have to worry about leading zeros in the link file. Now we can simply create a link file with the source address references from the ISO bus website - https://www.isobus.net/isobus/sourceAddress.
Hopefully this helps simplify decoding J1939 especially when it comes to finding ECU's that drop of the network like in the example below where the Engine ECU 1 was intermittently dropping off the network.
Here we can filter the source address for either 0 for engine ECU 1 or filter using the text "Engine #1" as per the link file. You will now only see those messages associated to that source address and here you notice the length of time between packet 169 and 292 followed again by packet 336 and 432. In this instance the engine ECU was at fault and replaced to cure the fault.
I hope this helps.