Decode J1939 CAN data, don’t guess.
Customer support called regarding an issue with a Manitou, reporting that the DEF level was empty despite the DEF tank being filled to the point that it’s physically impossible to add any more. With the machine derated due to the DEF tank showing low and a fault code present, how can you be sure that the expensive replacement part (£1000+) will cure the fault? Understanding how something works is key to making the proper diagnosis.
The interesting point about the DEF unit is that the level is transmitted over CAN, which is partially expected, but it can be done in two ways. Although I’m not allowed to share the J1939 SAE document or information, it doesn’t take long to find out more about this data through a quick internet search. The best one I found is from the following – https://www.ssi-sensors.com/perch/resources/documents/tulc-combination-sensor-tulc-an.pdf
The sensor in the document above isn’t the same as the one fitted to the Manitou, but the information regarding the DEF level, being J1939, is the same for all (unless it’s reprogrammed for proprietary messaging).
By using the J1939 decoder in PicoScope 7 Automotive, we can start to pick some of the data apart and start to filter according to the PGN and/or source address.
J1939 Interface
The TULC product is SAE J1939 compliant. It uses a fault-tolerant TJA 1040 transceiver chip to interface to the bus. The TULC does not include a bus terminating resistor. The data rate is 250 kbits/seconds. The TULC uses source address 0xA3. The TULC product is re-programmable over the J1939 bus and uses proprietary PGNs to perform the programming.
According to the found document, the source address for this level sensor is 0xA3, where the 0x tells us that the value is in hexadecimal. This is helpful as we have the information we need to set up the decoder.
By adding a filter for the source address 0xA3, we can remove the data we are not interested in.
To add a filter,
- Click Add Filter, select the parameter you would like to filter on.
- In this case, ID (Source Address), the operator is defaulted to Contains, for which there is no need to change.
- We then add in the argument or what we would like the software to filter on.
- Finally, click Add.
This gives us quite a lot of information and we can see that there is more than one PGN. By referring back to the PDF mentioned above, we can see that they have given the PGN for the level.
At this point, we can delete the previous filter or just add another, but this time we are going to filter on ID (PGN). From earlier posts, such as the following https://www.picoauto.com/support/topic22271.html, the PGN is the 2 bytes in the middle of the ID. In the above example, this would mean FE56 is our PGN.
We are now left with just 8 packets of data, which is a bit easier to digest! When initially looking at the data, the first 4 bytes have values that change. We can also assume the data transmission rate is 1s based on the fact that it takes a second between packets in each buffer!
Using the information from the sensor PDF, the DEF level as a percentage starts at byte 0 (which is the first one) and lasts for 8 bits, which is 1 byte. If we use the first data field from buffer 1, this byte is 11. As this is still in HEX to get to real values, we have to convert this to a decimal and by using the built-in Windows calculator, we have 17.
The next part is usually the tricky part, as the information to convert this to real units is locked away in the SAE document. Fortunately, the sensor PDF has actually given us the scaling factor and offset. The required conversion takes our decimal value, applies a 0.4 scaling factor and requires no offset. Therefore:
17 x 0.4 = 6.8%
This is supposed to be the percentage of DEF compared to the tank volume. However, is this how empty it is or how much room is left in the tank? Bearing in mind that the instrument cluster is reporting the level as being empty, we could assume that the lower the %, the lower the level. We can back this up by using the physical level sensor data.
To determine this, we can use the float level to determine the height of the fluid from the bottom of the tank. This can be done in a number of ways, such as ultrasound or floats. Not knowing which one the Manitou has, we will just use the information from the PDF and see what it comes out to.
Looking at the start bit position and the bit length to begin with. The bit length is marked at 16 bits, which, as 1 byte is 8 bits, means we are going to be using 2 bytes. The bit start position is also 16. The image below from https://cdn.intrepidcs.net/support/VehicleSpy/spyInDecodeBits.htm shows how bit positions are allocated. It only shows the position for the first two bytes, but hopefully you can see how the rest of the position would occur through the proceeding bytes.
This would put bit position 16 on byte 3, therefore we need to be using bytes 3 & 4. We have to reverse the byte order to create the right decimal as per the following post – https://www.picoauto.com/support/viewtopic.php?p=100659#p100659. This means looking at the actually physically measured level of DEF fluid is as follows:
Bytes 3 & 4 =
55 0F
Flip them around so byte 4 leads –
0F 55
Join them together and convert to a decimal
0F55 = 3925
We then apply the scale and offset according to the PDF document, which is 0.1 scale with no offset –
3925 x 0.1 = 392.5mm
Given that this is recording nearly 400mm (40cm), which is not anywhere near the bottom. But how do we determine if that is the height from the bottom or the height to the top of the tank? Given that we know the tank in the faulty machine is full, both of these values point towards a defective sender unit, but is there more evidence we can gather to prove it?
The only real way is to get data from a known good source.
The following data comes from a machine with no faults and the DEF tank is showing Full on the instrument panel.
Looking at the first byte, we have a HEX value of FA. If we use the same conversion as above:
0xFA = 250 DEC
250 x 0.1 = 100%
As the tank is full and the display is reading the same, then we can assume that this information is correct and proceed to the other level measurement.
Here we have 4B 00, which is flipped to make 004B, giving us 75 DEC. If we follow the above, we end up with 7.5mm. As this machine is fault-free and full to the top, we must assume that this level corresponds to the top of the tank. I haven’t been able to find any documentation to support this. Hopefully, we can obtain further examples to support this theory, or replace another one to manipulate the float before fitting to the machine.
We were able to get to another machine that was showing approximately. 50% on the instrument panel. Applying the same method as above, we have the following:
For the level in percentage, the first byte 75 converted to a decimal is 117 x 0.4 = 46.8%. The two bytes for level in mm are E3 08, switched around and converted to decimal, 08E3 = 2275, then into mm, 2275 x 0.1 = 227.5 mm.
Diagnosis Summary
There is sufficient evidence to support that the reading was incorrect for one that measures at 100%. Consequently, the level sensor was replaced and the fault has now been resolved. To be completely certain what these measurements represent, we need to take some physical measurements of the tank and the level sensor. Hopefully, this demonstrates how decoding for certain components that are universal between machines can help to verify scan tool data.
FAQ section
Question: What was the primary diagnostic challenge in the Manitou DEF level sensor case?
Answer: The challenge was decoding the J1939 CAN bus data using a PicoScope to verify the DEF level sensor’s output since the instrument cluster was incorrectly showing the tank as empty.
Question: What is the J1939 Source Address for Manitou DEF sensors?
Answer: 0xA3.
Question: What was the conclusion of the diagnosis regarding the Manitou DEF system?
Answer: The DEF level sensor unit was defective, which was confirmed by comparing its incorrect CAN bus data with data from a known good machine.