Smart Sensors

Ask for and share advice on using the PicoScope kit to fix Heavy Duty and Off Highway machinery here
mxx20
Newbie
Posts: 8
Joined: Sat Jul 18, 2020 8:03 pm

Re: Smart Sensors

Post by mxx20 »

On the same topic of SCR problems, we've had a few 6.7 cummins with a fault stating not enough PM sensed. Short story is there was a bad batch of SCRs that werent welded correctly and installed from the factory. Several diesel in the DeF tanks eith horizontal exhausts and the SCR was full of diesel due to it was trying to reduce nox. The tech on the diesel in the SCR one got me after it still had issues and then found that. It's amazing how some of this goes, which is why I got the pico and lurking the forums trying to gather knowledge lol

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

Re: Smart Sensors

Post by ben.martins »

Hello,

I need a little help with this project I'm working on with these sensors but I need some extra data to verify what I've found. I'll be doing the same but could I ask the next time you're at the at a machine, could you access the CAN data on the after treatment system and email it to over to me please?

if you use the settings from the guided test it will set everything up but also keep everything equal. You'll end up with 4 buffers with a lot of data don't worry about the decode table as I can sort that it's just the raw data I need. Then I can share the findings I have here which will hopefully help everyone.

Kind regards

Ben

KimAndersen
TwoWaves
TwoWaves
Posts: 223
Joined: Fri Nov 30, 2012 2:53 pm
Location: Denmark

Re: Smart Sensors

Post by KimAndersen »

Hi

What an interesting topic - the interpretation of the J1939 protocol. I have to admit that I have been following this topic from the beginning and thought it could be exciting and so is it. But in what way can I help you understand the J1939 protocol and its operation !.

Ben has described most of the documentation excellently so there is no need to repeat it again - but I want to add some documentation about the interpretation of the 8 data bytes, which in my opinion is the most exciting area to deal with.

To understand the meaning of the 8 data bytes you must have some background knowledge and by that I mean the correct SAE J1939DA document from SAE.ORG - without this document it will be difficult to find head and tail in the interpretation of for example offset and resolution values.

I will start with Ben's decoding of the NOX sensor canbus signal and especially the 8 DATA bytes which looks like this in hexidecimal ( FF FF FF FF FF 7F 1F 1F) and which Ben has already found the correct PGN number 61455 which relates to the area around Aftertreatment 1 Outlet Gas 1.

NOX SENSOR DECODING  DATA 8 BYTES
NOX SENSOR DECODING DATA 8 BYTES

I will here try to decode the first 4 bytes of 8 bytes total. So byte number 1 + 2 is (FF FF) hex and it corresponds to 65535 in decimal numbers - which does not tell us much.Before we move on, I think we should have a description of what values byte 1 + 2 mean in the form of readable text.

"The amount of combined NO and NO2 in the exhaust exiting the aftertreatment system measured by a NOx sensor at the aftertreatment outlet, represented in NOx molecule parts per million non-NOx molecules in exhaust bank 1"

Then back to byte 1 + 2 (65535 decimal) and the interpretation of this value. To be able to transform this value into something useful, you need to know two things - namely the resolution and the offset values which you will find in the documentation from SAE.ORG or more specifically in the J1939DA document.

Offset value is = (- 200 ppm) and the resolution value is (0.05 ppm / bit) and which covers a data range of (-200 to 3012.75 ppm).

So the calculation looks like this (65535 decimal multiplied by 0.05ppm / bit minus 200 ppm) which is equal to 3076.75 ppm and which is outside the mentioned data range !!!.

It was not difficult when you know what offset and resolution values are.

The next two bytes are bytes 3 + 4 and which also have the same hex value (FF FF) and are equal to 65535 in decimal numbers. Here is a short description of what byte 3 + 4 means in the form of readable text.

"The actual oxidation factor (% O2) of the gas within the exhaust stream. For positive values, the parameter represents the percent oxygen in excess of the amount required for stoichiometric combustion. For negative values, the parameter is proportional to the amount of oxygen being pumped by the sensor. This value is measured by a sensor at the aftertreatment outlet in exhaust bank 1. "

Offset and resolution values ​​for bytes 3 + 4 are respectively - (Resolution = 0.000514% / bit) and (Offset = -12%) so the calculation will look like this (65535 decimal number multiplied by 0.000514 minus 12%) which is equal to 21.68%. The data range for bytes 3 + 4 is from -12 to 21.02707% - so the value we calculated is also outside the specification.

I hope with this post that it has given just a little more insight into the understanding of the J1939 protocol and that it is just evolving in the right direction. I am by no means an expert in interpreting the J1939 protocol - I just have access to the right technical information which makes a big difference.

I know Ben will be able to answer far more questions regarding HD equipment than I ever get to.

Best regards
Kim :wink:
Last edited by KimAndersen on Wed Jul 29, 2020 6:33 pm, edited 1 time in total.

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

Re: Smart Sensors

Post by ben.martins »

As always Kim your input is invaluable, thank you.

What you have explained so brilliantly is what I've discovered with the NOx sensors. I just need some data to show that it works. One day I hope to share the rest of what I've been working on. It's extremely exciting and has helped me on a number of occasions where the scan has given me some, but not all the information.

This has reminded me actually that there are some other requirements for the data capture if anyone can help. Ideally the vehicle or machine needs to be running and up to temperature whislt recording the after treatment network. If there is enough time to capture it, a snap throttle would also be amazing!

Thanks again all for the input and starting this topic. It's something I've been wanting to share but never felt I had the right audience! It's going to be great!!

Kind regards

Ben

muttnjeff
OneWave
OneWave
Posts: 15
Joined: Tue Jul 21, 2020 7:19 pm

Re: Smart Sensors

Post by muttnjeff »

Hello Kim,

I’m pasting part of your post:

To understand the meaning of the 8 data bytes you must have some background knowledge and by that I mean the correct SAE J1939DA document from SAE.ORG - without this document it will be difficult to find head and tail in the interpretation of for example offset and resolution values.

I looked for the document you mention, it’s available on SAE, not inexpensive however if a shop were to purchase it it could be used by multiple techs which would help justify the expense... my question, not able to see what’s available in said document I’m curious if it does cover many aspect of sensor reporting? Could you either go into a bit more detail as to what’s available or possibly post a snip it of the document?

Great write up glad you added your insight..

KimAndersen
TwoWaves
TwoWaves
Posts: 223
Joined: Fri Nov 30, 2012 2:53 pm
Location: Denmark

Re: Smart Sensors

Post by KimAndersen »

Hi muttnjeff

I can not display anything from the J1939DA document based on SAE.ORG's copyrights or anything else - I dare not.

Regarding your question about sensor reporting, this document is very detailed regarding PGN and SPN numbers about where and what the individual bytes / bits have been used for.

But it is not described in such a way that when you have a sensor, its signal voltage must be at a certain value under a certain working condition - it is more described as an area that this value must be within - such as this range from 0% to 21.65 % oxygen content and last but not least the important information about the resolution / scaling values as well as the offset value.

You will not regret the purchase of this document.

As you yourself mentioned, this document is not particularly expensive to buy and especially not if you are several people about the purchase.


Best regards
Kim :wink:

muttnjeff
OneWave
OneWave
Posts: 15
Joined: Tue Jul 21, 2020 7:19 pm

Re: Smart Sensors

Post by muttnjeff »

Kim,

Completely get the copyright laws.. The description of the contents is good and gives a clearer picture of what applicability or use it could have.

Thanks again, this has been a good topic thus far and appreciate the insight.

Neil

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

Re: Smart Sensors

Post by ben.martins »

To follow on from what Kim has posted I wanted to share with you how we can use the data captured with Pico to better obtain some information that will aid with diagnosing these sensors. Thanks as always Kim the information you share. It is both invaluable and inspiring as it spurs us on to achieve more than originally thought possible.

I have kindly received some captures from muttnjeff who was able to gain access to the Aftertreatment network from the upstream NOx sensor on a Cummins ISX engine. As the file doesn’t belong to me, I won’t post it here but if muttnjeff would be OK for me to do so, I’ll add it at a later date.

There are plenty of resources already on the forum for CAN decoding but I will quickly go back over the basics. I know not everyone uses the guided tests but I do find that the serial decoding preset works very well when working with J1939. It will also setup the Math channel and the decode table for you which helps to speed things up. I have mentioned this in an earlier post so no need to go back over this.
Using muttnjeff’s file we get the following results –
Pic 1.png
I’ve added an extra view to show how tolerant CAN is as the message is cleaned up when subtracting High from Low leaving us with the physical layer to decode on. You can quickly determine that the network you have is using the J1939 protocol by looking at the ID. This 29 bit header gives us the clue that we are looking at J1939.

Once we have this data, we’re now ready to export. A quick tip if you are looking to export more than 1 buffer. Typically, you’ll find that the data isn’t in numerical order which you can sort after the export but it’s just as easy in PicoScope. To start with you need to select All Buffers then click on the Packet and then Buffer within the serial decode table and this will arrange the packets and buffers in ascending order. This also means the packets are in the correct time as well.
Pic 2.png
With everything now aligned click Export and save the file in a location you can easily find. Locate this file and then open in Excel.
Pic 3.png
To help with sorting click the Filter option which will then add a drop-down arrow to each of the columns. This will mean you can sort by data in any column but the one we are interested in is the ID.

A little bit of background information is now required as we need to know what the PGN’s are. We know that it is made up of two bytes in the ID but what if we are only interested in a specific PGN? As this topic has been on Aftertreatment sensor lets look at one that is most likely to be changing a lot, namely the upstream NOx sensor. Kim has mentioned the SAE J1939DA document which if anyone is interested in this level of decoding, is an absolute must. I wouldn’t be where I am with decoding J1939 without it! As Kim also mentioned we are unable to share any of these documents here due to copyright.

What we can do though is look up what PGN is used to display data from the front NOx sensor. To do this the following website can really help - https://www.isobus.net/isobus/pGNAndSPN/index. Here you’ll be able to look up any SPN which in turn will give you the PGN. By typing in NOx to the SPN name we can see that the PGN for Engine Exhaust 1 NOx 1 is 61454

By using the built-in windows calculator and selecting Programmer, select DEC and type 61454 which gives us the result in HEX. This works out to be F00E.
Pic 4.png
Now we have the PGN for the Engine Exhaust 1, NOx 1 in HEX which we can filter through in the Excel sheet. By clicking the dropdown on the ID cell, you can see all the relevant data which contains all the PGN’s present in that capture. We are looking for F00E which is fortunately near the top! Click Select All will actually deselect all leaving you to just click 18 F0 0E 51.
Pic 5.png
Pic 6.png
With the ID’s now all order we can also see the data packets that shown are only those from the PGN 61454. Fortunately, the byte allocation for this PGN follows exactly the same rules as what Kim has mentioned above for the Outlet NOx sensor which means we can just apply the same math again. It would be easier if Excel could do the work for us.

The biggest hurdle is having to split the Data into actual Bytes. This can easily be done by using the Text to Columns function. If you highlight the whole data column and then click the Text to Columns this will separate out the Bytes.
Pic 7.png
There will be a warning as it will over write the data in the columns to the right of the Data, but right now we’re not interested in those fields so it doesn’t really matter.

Hopefully, after a little bit of tidying there should be something like the following –
Pic 8.png
I’ve added in the Byte Numbers as well for clarity. Going back to Kim’s post we know that the first two Bytes contain the information related to NOx content in PPM. We do however, need to join those Bytes together but in the correct order. Reading back through the spec we find that the following comment - Other parameters consisting of 2 or more data bytes shall be transmitted least significant byte first. This means we have to join these bytes together moving from left to right in little endian fashion. This is also true for the Oxygen Content which is made up of Bytes 3 & 4.

If we manually go through the data with the math we get the following results –

Byte 1 & 2 = 46 & 17

This needs to be changed to 17 & 46 as per the spec.

Joining these together we have 1746 in HEX which when converted to Decimal = 5958.

If we now apply the scaling and offset as per Kim’s post we have –

5958 x 0.05ppm – 200ppm = 97.9ppm

Carrying out the same process for the O2 percentage –

Bytes 2 & 3 = 43 & B4

Now becomes B443 which as a decimal = 46147

46147 x 0.000514 – 12 = 11.719558 %

The good news is that Excel can do all that for you using the HEX2DEC and CONCATENATE functions.
Pic 9.png
Not only this but within Excel you can add in a graph although it doesn’t really like creating graphs on filtered data. To change this, copy the NOx and O2 columns and paste into a new worksheet. When pasting select the option to paste values only and then you can create a graph on this data.
Pic 10.png
By no means is this an easy way to get this type of data. There are many purpose-built devices that can do this much easier along with DBC files that will process all the data for you. What this does show though, is that your PicoScope isn’t only limited to measuring the electrical signals.

I hope this helps

Ben

muttnjeff
OneWave
OneWave
Posts: 15
Joined: Tue Jul 21, 2020 7:19 pm

Re: Smart Sensors

Post by muttnjeff »

Great write up Ben, its good to see the use of the scope expand.

Feel free to upload the waveform I sent to you.

Neil

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

Re: Smart Sensors

Post by ben.martins »

Thanks muttnjeff,

If it helps just one person it's all worthwhile! Thank you for allowing to share the file here as I know it will help those using trying out decoding J1939.

Kind regards

Ben
Attachments
Ben Data 3.psdata
(12.87 MiB) Downloaded 12 times

Post Reply