Smart Sensors

[krabkakes]

This may be a bit late but here is my $0.02.

The most common failure mode on these "smart sensors" are in-range failures. It's not very common that the CAN circuits fail, it's typically the measuring circuits. As was stated earlier, the only thing we can really measure on these is CAN - which doesn't help much.

The best diagnostics come from reviewing the data using a scan tool during real-world use. The problem with this is that it relies on a technician to have a general understanding of what a "good" range would be at any given time. The other problem with this is that we can look at a sensor and say "that data doesn't meet what I would expect" but we have no exact way to determine if the sensor is reading incorrectly or if the system is not working properly.

A perfect example of this is NH3. When DEF is injected into the exhaust stream, it bonds with the wash coat on the SCR (think of a sponge absorbing water). If the SCR was coat is damaged in any way then more NH3 will pass through to the sensor and cause high NH3 measurements. Many of these NH3 sensors are then replaced when, in all reality, it was a worn or damaged SCR wash coat.

While Ben did show a way to graph PicoScope data, you're better off using a scan tool to do the same thing (assuming you have access to one).

[muttnjeff]

Thanks for the post, agree with your thoughts, I find it useful to use scan data for smart sensors and if possible export the data into a spreadsheet for review.

[ben.martins]

Hi krabkakes,

Never to late to add comments as it all promotes discussion which we can hopefully contribute and learn from.

I don't disagree that scan tool data is vast and when it comes to spotting the odd one out in a short space of time. Knowing what to look for is obviously key as you say, and many OEM's can now provide you a list of the expected values in their technical information. Scan tools give you lots of data very quickly and as such will always be a part of the diagnosis - where you have a scan tool available to you.

An example of where the scan tool isn't always clear to a technician is when Gateway ECU's are used. I was assisting a customer a few months ago where the scan tool was reporting the After Treatment ECU was off line as was all the NH3 sensors. With no data available to report the sensor readings the technician did the next thing which was to check powers, grounds, CAN bus resistance at the after treatment ECU and at the NH3 sensors and everything was checking out as OK. Everything at that moment was pointing towards to the After treatment ECU as the scan tool had said but, as we all get a little twitchy about replacing an ECU, they got in touch and we walked through the issues. We then got a capture of the CAN network at the After treatment ECU and using the techniques mentioned in this post, could determine that the after treatment ECU was online and sending out data and we could also see that data relating to the NH3 sensors.

The issue wasn't with the After treatment ECU but on this machine the Engine ECU acted as a gateway. As the DLC was on another branch where the only access to the After treatment ECU was through the Engine ECU, we concluded that actually the Engine ECU was at fault. It was replaced and the scan tool could now see the missing after treatment ECU again.

Every tool has it's place in the diagnostic challenges we face. What makes a good technician isn't the amount of tools they have but knowing when to use the right tool for the right job.

[krabkakes]

An example of where the scan tool isn't always clear to a technician is when Gateway ECU's are used.

Absolutely! That is a great use of a PicoScope for CAN decoding! In the trucking industry we're seeing more and more gateway modules as the industry continues to focus on reliability (isolating critical networks from customer-installed devices, or non-critical devices like the radio) and data security.

[Mossy85]

To resurrect an old post, I was wondering if anyone in here has done much decoding of Nox sensors on Volvo products?

I have trawled through several captures looking at the decoded CAN data gathered from FH/FMs and have found the Nox sensor IDs for both up and down stream. These IDs however are not the same as those listed in this thread. My Inlet is 0C FF 17 51 and my outlet is 0C FF 17 52. The scaling and offset does not follow J1939 from what I can see. I therefore have to assume this data is proprietary.

From what I can see the data field is FF for all 8 bytes until the sensor is activated. From there the data means little to me. The next chance I get I plan to run a sensor test via the diagnostic tool and capture the raw data and see if I can make any correlation.

I would appreciate anyones feedback or help on this, cheers

Dave

[ben.martins]

Hi Dave,

I think the data I have sadly has no activity from the NOx sensors, so possibly still in the warm up phase.

The PGN FF17 = 65303 DEC and when looking that up on the isobus.net website we can see it is a proprietary message. It will be tricky to correlate the decoded values in Pico with live data but it isn't impossible.

If you get some data and happy to post here or upload to the waveform library we can take a look.

Kind regards

Ben

[Mossy85]

Hey Ben

Thankyou for the response. I do have some data saved however i did aquire it over 3 years ago now so i cant hand on heart say that the Nox levels i have wrote down are correct.

There would be no point in me posting "questionable" data so I will aquire some fresh captures on the next emissions fault i get and then post it up.

Carl did take a look for me when i first aquired the data i mentioned and he seemed to think that the scale and offset from J1939 may actually be used however the data byte locations may be in a different orientation.

Either way I will get some good data uploaded as soon as I can and then if you or anybody else can chip in and work some magic that would be great

Cheers

Dave

[Mossy85]

This week turned out to be a good week for emission related faults which worked out great as it allowed me to gather some data.

In the past when I have looked at the data from Nox sensors on Volvos I had it worked out that even though the data was proprietary, the scaling and offset factors used in J1939 were actually being implemented. That data I am referring to was from a 2015 vehicle, but I am now struggling to confirm what the scan tool was showing me at the time I captured this.

The data I collected this week I acquired from a 21 plate FH4. On the factory tool we are able to put the vehicle into a test mode where adblue injection is inhibited thus allowing for a direct comparison between upstream and downstream sensors. The test runs for approx 1 hour and places the engine into various conditions that produce Nox levels where the sensors range will be tested, ie high nox, low nox. The uploads below were captured at various stages of this test which would hopefully allow me to correlate the scan tool readings against the raw data.

So what did I find? Well if we take the inlet nox sensor which has an ID of '0C FF 17 51' and look at the data, we can see that we have data in all byte positions but it is bytes one through four that are actively changing. This would line up with J1939 where bytes one and two are responsible for reporting Nox levels and bytes three and four are reporting 02 content.

If I pull a sample from the data I have uploaded for the inlet sensor where the scan tool was reporting 1650 ppm we have the following

72 06 AA 01 D2 FF 55 CC

As above, in J1939 it states bytes one and two are responsible for reporting the Nox data. So our Nox data here would be 72 06. If we take this and use intel byte order we have 06 72. Converting the hex into decimal we are left with 1650 which is identical to what the scan tool is reporting. The suprising part here is that there is no scaling resolution or offset required, it is literally a straight conversion. I thought that perhaps it was a very strange coincidence on my first try so I applied it to more data throughout the test where the nox levels were both high and low and it holds true.

Please feel free to look at the data for yourselves and try it out incase Im missing something. I haven't tried too hard to go further than Nox data and work out 02 content or heater status etc as from what I can see that is still proprietary. Maybe someone can look at it and work it out though and share their findings?

Just a side note about the older 15 plate vehicle I mentioned at the start. I am almost positive that the data from that vehicle was using the J1939 scaling but that Nox was being reorted in bytes three and four instead of one and two. This would lead me to believe that somewhere along the line Volvo actually changed things around. I wonder could it a software change or would it have to be a hardware change? I know that both have been changed extensively between 2015 and 2021 so it could be possible. Or, I am completely wrong and the 2015 vehicle was reporting the same way as the 2021

Anyway, let me know your thoughts if you have any

Dave

[Mossy85]

The figures will change slightly as the nox levels are dynamic as expected

[ben.martins]

Hi Dave,

Great captures and thank you for sharing.

I would agree with you that the NOx data does appear to be a straight conversion from the first 2 bytes to decimal. The oxygen though is leaving a little to the imagination if we following the same rules! I've put the decoded date and using the J1939 decoder filtered out the source address for 51 and 52, upstream and downstream NOx sensors. I've run them through a sheet I've created to get the following images from both the sensors>

As mentioned, the O2 is a little off but there is some movement with the data to suggest it is something that is changing. It does also change depending on the NOx levels as well which would make sense - it's just finding the conversion.

With the J1939 decoder it is possible to add a filter which will highlight just the messages of interest which in our case would be from PGN FF17 and source address 51 or 52. You could open and additional decode table to show the two in separate windows.

Great work and if I find any relationship for the O2 output I'll update here.

Kind regards

Ben