DEF level sensor

Ask for and share advice on using the PicoScope kit to fix Heavy Duty and Off Highway machinery here
Post Reply
ben.martins
Pico Staff Member
Pico Staff Member
Posts: 539
Joined: Tue May 16, 2017 1:02 pm

DEF level sensor

Post by ben.martins »

Hi all,

Hope all are keeping well. This is a mini case study of sorts but I also wanted to bring another example of where serial decoding can be used to help qualify data between the scan tool and what is available on the CAN network.

Customer support called for issue with a Manitou reporting that the DEF level was empty despite the fact that the DEF tank is actually brimmed to the point that it’s physically impossible to get any more in. With the machine in derate due to the DEF tank showing low, and a fault code present, how can you be sure that the £1000+ part will cure the fault? Understanding how something works is key to making the proper diagnosis.

The interesting point about the DEF unit is the level is transmitted over CAN which is partially expected but it can be done in two ways. Whilst I’m not allowed to share the J1939 SAE document or information it doesn’t take long to find out more information on this data by a quick search on the internet. The best one I found is from the following - https://www.ssi-sensors.com/perch/resou ... ulc-an.pdf

The sensor in the document above isn’t the same sensor 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 PS7A we can start to pick some of the data apart and start to filter according to the PGN and/or source address.

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 the up the decoder.
J1939 decode HEX.png
By adding a filter in for the source address 0xA3 we can remove the data we are not interested in.
Add filter.png
To add a filter click Add Filter (1), select the parameter you would like to filter on in this case ID (Source Address) (2), the operator is defaulted to Contains which there is no need to change. We then add in the argument or what we would like the software to filter on (3) before finally clicking Add (4).
Filtered on A3.png
This gives us quite a lot of information and we can see that there are more than one PGN. By referring back to the PDF mentioned above, we can see that they have given the PGN for the level.
PGN for level sensor.png
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 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.
Filtered on FE56.png
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 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 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 at.
PGN for Level 2 sensor.png
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 below image from https://cdn.intrepidcs.net/support/Vehi ... deBits.htm shows how bit position is 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.
Bit position.png
(7.12 KiB) Not downloaded yet
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 - viewtopic.php?p=100659#p100659. This means looking at the actually physically measured level of DEF fluid is as follows:
Bytes 3 & 4.png
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 height to the top of the tank. Given we know that this tank in the faulty machine is full both of these values are pointing towards a faulty 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 showing Full on the instrument panel.
Known good.png
Looking at the first byte we have a HEX value of FA. If we use the same conversion as above we -

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. Onto the other level measurement.

Here we have 4B 00, flipped around to make 004B which gives 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 have to make the assumption that this level is level from the top of the tank. I’ve not been able to find any documentation to support this but hopefully we can get further examples to back up this theory, or if replacing another one to manipulate the float before fitting to the machine.

We were able to get to another machine that was showing approx. 50% on the instrument panel. Applying the same method as above we have the following -
Known good 46%.png
For the level in percentage the first byte 75 into a decimal is 117 x 0.4 = 46.8% and 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.5mm.

There is enough evidence to support that the reading is incorrect for the faulty machine and so the level sensor was replaced and the fault has now gone. Going forward to be completely certain what these measurements represent, we need to take some physical measurements of the tank and the level sensor.

Hopefully this shows how decoding for certain components that are universal between machines can help to verify scan tool data.

I hope this helps.

PaulW
OneWave
OneWave
Posts: 18
Joined: Tue Jul 26, 2022 5:37 pm

Re: DEF level sensor

Post by PaulW »

Hello Ben,
Great example and use of decoding tool in Pico automotive software. Awesome breakdown and step by step. That .pdf find was awesome as well. Finding information is half the battle. Knowing how to get the information is difficult but finding out what the limits are a must in a proper diagnosis. We replace a lot of DEF headers at my work. The only test we do is load test supply and return ckts. while doing a wiggle test on the harnesses. Then ohm out J1939 and checking voltage on high side and low-side of datalink. I wiggle test while having my meter on min/max function. I've only had 1 where high-side datalink shorted to ground intermittently when wiggling. Found the rub spot on the other side of the truck and had 1 strand holding the circuit together. Normally if there is an issue with datalink I would expect more than 1 smart device reporting mulitple DTC's but not in this case. Having a scope on the datalink would have showed me a lot more than an average reading my multimeter was showing me. I can not wait to get to use the decoding tool. This was a great post and keep them coming if you have more please!

Mossy85
Newbie
Posts: 3
Joined: Wed Nov 25, 2020 1:56 pm

Re: DEF level sensor

Post by Mossy85 »

Hey Ben,

thanks for another great post. I was actually having a bit of a play with a Volvo FM4 a while back now as they too have gone down the ultrasonic route for their tank level and concentration etc. I took two captures of the subnet, one of which I took the level sensor off line to help identify its SA as Steve shows in his YT video. Ive just had a mull back over them to refresh myself whilst following your post and its nice to see how J1939 really is a blessing for us HD guys when wanting to make the call on potentially seriously priced parts
Attachments
DIXONS ADBLUE CAN DIFFERENTIAL AT INLET NOX WITH QUAL SENSOR IN TANK 2.psdata
(22.55 MiB) Downloaded 238 times

ben.martins
Pico Staff Member
Pico Staff Member
Posts: 539
Joined: Tue May 16, 2017 1:02 pm

Re: DEF level sensor

Post by ben.martins »

Hi all,

Thank you for the feedback and the kind words. We've always said that if something we put out there helps at least one person then it's worth while.

The J1939 decoder in PS7 has been a great asset to working with J1939 networks. By being able to see the source address and even creating a link file which will show the source address in human readable form makes it easier to determine if any ECU is on or offline. Great for finding those ECU's that communicate to the serial tool through a gateway. I've found the ISO BUS website particularly useful for the generic SA's - https://www.isobus.net/isobus/sourceAddress.

Load and resistance tests still have their place of course but hopefully by testing the network without having to dismantle or disconnect makes using the scope the first point of call when dealing with these issues, even more so if it's intermittent. It's different way of working for certain but to quote a wise man, Joe Bell, we have a degree of unlearning to do before we can start to learn new ways of diagnosis. Unlearning isn't easy believe me!

Thanks for the PSDATA file Mossy as it'll help others have a play. Worth shifting through the waveform library as well to have a play with some J1939 networks and to try out the decoder. Making the call on some of these parts is never nice and it doesn't matter how long you've been doing it! It also seems to be the bigger the machine, the more expensive the same part is so making sure you're right is a must.

More will be coming I'm sure and it's great to see that this sector of the forum is getting more and more people involved. Looking forward to seeing it continue to grow and more questions being asked!

Kind regards

Ben

PaulW
OneWave
OneWave
Posts: 18
Joined: Tue Jul 26, 2022 5:37 pm

Re: DEF level sensor

Post by PaulW »

Hi all,
Hope all has been going well. I sat down last weekend and went over how you decoded the can with offset and scale with the bytes I did some research and found this link for NOx sensors I haven't seen on this forum, forgive me if this is old information.

https://www.ecotrons.com/files/ALM%20Co ... %20CAN.pdf

It has a great display for the bits in the byte layout. The only thing I don't see is the scale. I do see under resolution it shows "0.000xxx" I assume that is the scale so with the offset we can get the number we would see typically with the scanner live data monitor. This whole forum has been a treasure chest of information. Hope this will help someone. I decoded my first can frame with Picoscope last night due to the DEF header, Smart sensor, and J1939 CAN decoder threads. I can't wait to get a hold of 4425A someday. Ben if you would like share the .pdf where you want. I'm still learning forum etiquette. I'm very new to this and can't wait to see the other ways I can use the scope.

I have a question for Mossy85, which video were you referring to with Steve on finding SA? if you don't mind me asking.

Mossy85
Newbie
Posts: 3
Joined: Wed Nov 25, 2020 1:56 pm

Re: DEF level sensor

Post by Mossy85 »

Hi PaulW, not a problem, here is a link to the video https://www.youtube.com/watch?v=Bc2R462dlac&t=10s enjoy

Dave

PaulW
OneWave
OneWave
Posts: 18
Joined: Tue Jul 26, 2022 5:37 pm

Re: DEF level sensor

Post by PaulW »

Hi Mossy85,

Thank you very much. That is awesome!

ben.martins
Pico Staff Member
Pico Staff Member
Posts: 539
Joined: Tue May 16, 2017 1:02 pm

Re: DEF level sensor

Post by ben.martins »

To help with decoding, the J1939 decoder makes everything that little bit simpler. As the SA is the last byte in the header, the decoder can be used to easily identify an ECU that is missing or causing corrupt data.

You can see more on the decoder here - viewtopic.php?p=102564#p102564

Hope it helps!

Kind regards

Ben

Post Reply