Smart Sensors

Ask for and share advice on using the PicoScope kit to fix Heavy Duty and Off Highway machinery here
muttnjeff
TwoWaves
TwoWaves
Posts: 72
Joined: Tue Jul 21, 2020 7:19 pm

Smart Sensors

Post by muttnjeff »

Open question...

Has anyone had or currently have a good method for diagnosing "smart" sensors?

Sensors that are equipped with their own module, which in-turn communicates on the CAN network, examples would be the NGK/Continental NOx sensors, NH3 sensor and/or particulate matter sensors.

Examples of sensors for reference.
Continental NOX Sensor Delco PN. 19330003
PM Soot Sensor 12 Volt Volvo/Mack PN. 22946032
Paccar Ammonia Sensor PN. 1902241PE

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

Re: Smart Sensors

Post by ben.martins »

Hi muttnjeff,

Great question as these are notorious for being difficult to 100% prove as the only thing we have to measure is the CAN signals. This usually means trusting the scan tool for the right information. I've spent a little time looking at these sensor but I probably need to spend more to grab some further data.

The after treatment systems I've seen have been quite useful to work on as the network consists of a limited number of ECU's. This is including the NOx sensors which I treat as their own module. Some of these also come with termination resistors inside giving yet more of a headache if fitting aftermarket parts.

What I do know is that because most HD and Off Highway machines run on the J1939 protocol, this actually makes things a little easier for us. J1939 is for the most part standardized meaning it doesn't vary from manufacturer to manufacturer. This is good news for us as we can exploit this in PicoScope using our serial decoder. We must remember, though, that PicoScope is not a dedicated CAN decoder/logger but an oscilloscope with limited decoder/logger features. That being said, there is still an awful lot we can do.

I will look to go into a little more depth on J1939 at a later stage but for now we just need to understand how we can determine the PGN - Parameter Group Number. To begin with, we need to understand how the message ID of a J1939 message is made up. The message header is made up of 29 Bits but to keep things simple we will look at the message in HEX. When carrying out any serial decoding in PicoScope you have the option to display in HEX, Binary, Decimal and ASCII.

Each message has a unique Parameter Group Number, PGN, which also contain the Suspect Parameter Number, SPN. 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.

This same process can be applied to the Aftertreatment network. If we capture raw CAN data either at the Aftertreatment ECU or a NOx sensor we can see the traffic from all ECU's present in this network. Fortunately when compared to other networks, the Aftertreatment one tends to have only a few ECU's present which makes things easier when it comes to reviewing.

The easiest way to capture CAN that you would like to decode is the use the Guided Test. In PS6 this can be located under Automotive, Communication Networks, Serial Decoding. This will then load a file with correct voltage and time base for this capture along with the math channel and the serial decode table. Once you have data on the screen you might find that the data isn't being decoded correctly. The most likely cause is due to the incorrect Baud rate being set in the decode table. J1939 is usually running at either 500kbaud or 250kbaud. Changing this is easy by clicking the settings cog on the right hand side of the decode table and then changing the baud rate as per the image below.
Changing Baud Rate.png
You should now see the decoded data in HEX form. I've given an example below.
J1939 NOx sensor.png
If we apply what we found earlier to the ID's we can then work out which PGN's we have present on this network. If we take the top ID of 18 F0 0F 52, translate that into a PGN by taking the two middle Bytes F00F and then convert this to a decimal, our PGN number is 61455. A quick search on the internet and PGN 61455 is Aftertreatment 1 Outlet Gas 1.

We could break this down even further to actually determine what that data is but I'll need a little more time on that one!

By using the export option we can save all this data to a CSV file where we can then use Excel to dig deeper. Adding in a filter will allow quick sorting of the data and also display how many PGN's we are working with.
Filtering in Excel.png
Filtering in Excel with drop down.png
Here we can see there are just 3 PGN's present and if you work through how to determine what they are we have the Outlet and Inlet NOx sensors and the Engine Controller 3.

If you wanted to be sure that just because the Scan Tool is saying there is an issue with a NOx sensor, this is a way of seeing if it's even present on the network. It could be that there is a issue in the CAN wiring which is preventing the sensor from being visible on the network.

I hope this helps and we have a number of resources in our useful links section on CAN and CAN decoding - topic15231.html

I'll continue to dig deeper into J1939 and hopefully there will be even more available for us to help with diagnosing these sensors and systems.

Kind regards

Ben

User avatar
campbell.kwtech
OneWave
OneWave
Posts: 16
Joined: Mon Jun 25, 2018 1:15 pm

Re: Smart Sensors

Post by campbell.kwtech »

I have extensive t/s experience on those sensors.

What's funny throughout the day I was working on a topic for CAN t/a.

What is your issue?

muttnjeff
TwoWaves
TwoWaves
Posts: 72
Joined: Tue Jul 21, 2020 7:19 pm

Re: Smart Sensors

Post by muttnjeff »

Currently no issues, I plan on digging more into the CAN system as Ben posted about, what approach /process do you use when troubleshooting smart sensors? How do you use scope and scan data to troubleshoot smart sensors.

User avatar
campbell.kwtech
OneWave
OneWave
Posts: 16
Joined: Mon Jun 25, 2018 1:15 pm

Re: Smart Sensors

Post by campbell.kwtech »

I posted a new topic last night concerning your very question, in fact I was working on a draft before you posted the Smart Sensor topic.

If you go to the new topic CAN 101, I posted the topic last night, and you'll see the first steps what I do concerning CAN fault codes.

I posted a topic under this forum for Paccar Kenworth, in that topic I attached a couple of start-up settings for testing CAN. You can download those and try it.

muttnjeff
TwoWaves
TwoWaves
Posts: 72
Joined: Tue Jul 21, 2020 7:19 pm

Re: Smart Sensors

Post by muttnjeff »

I did read your post and would agree with your approach, so I think what my question is now, is it possible to take reading directly from the sensor and bypass the module that converts those signals into CAN messages?

Would that be beneficial?

Could that type of testing be used to support or contradict scan tool data?

The problem I’ve had in the past was getting the proprietary info on the sensor wiring, if it were possible to take readings from the sensor directly, one could begin to decode what is being sent to the sensor node and then in turn transmitted on CAN.

User avatar
campbell.kwtech
OneWave
OneWave
Posts: 16
Joined: Mon Jun 25, 2018 1:15 pm

Re: Smart Sensors

Post by campbell.kwtech »

You are unable to by-pass the CAN device. Concerning Nox Sensors, there are driving tests, I.E. Paccar MX engines came out with a SCR Driving overview about 10 years ago. This test can easily spot a defective Nox Sensor. After the driving test you have to analyze the data, and you can easily see Nox ppm's. I once introduced this test to Cummins Tech support some years ago and they actually agreed that his was a good test, of course you would be using Cummins Insite, select all parameters, with sampling rate set at 1 second, follow the same Driving Overview instructions as set by Paccar MX Engine, But, I've only done this once, due to the Cummins ECU Software for Nox Sensors, the software has the capability of detecting faulty Nox sensor readings.

The best practice for CAN Sensor devices would be to follow the Engine manufactures Trouble shooting tree, if that doesn't produce any results, tech support usually comes on board to help out. When it's not warranty you sometimes develop other methods.

Analog sensors in conduction with CAN Sensor devices for comparison also helps, but this is rare.

muttnjeff
TwoWaves
TwoWaves
Posts: 72
Joined: Tue Jul 21, 2020 7:19 pm

Re: Smart Sensors

Post by muttnjeff »

Thanks for the input, The reason I keep wondering about these sensors I’ve have “seen” hundreds of these changed and in many cases the sensor was the victim, as for the scan tool test, Mack/ Volvo also offers a NOx conversion test that more or less checks the health condition of the SCR and NOx sensors, however unless there is a hard fault with the sensor how are techs supposed to differentiate the root cause of a NOx conversion derate.

I try to teach the value of data that you can dump into excel, turn into graphical format for a visual analysis however that’s sometimes unrealistic when in field on a machine that’s broke down.

The after treatment systems are coming close to a point where the cost to diagnose is greater than the parts cost (considering multiple trips, down time, customer dissatisfaction, etc.), so we are pushing techs to just swap parts.

I think I’ve digressed some and glad to get other perspectives on these sensors, systems in general, again appreciate the input and look forward to keep learning from the collective knowledge on their forum.

mxx20
OneWave
OneWave
Posts: 15
Joined: Sat Jul 18, 2020 8:03 pm

Re: Smart Sensors

Post by mxx20 »

On the cummins nox sensors, x12 logic is horrible. Went in circles on a terex mixer with one(one fleets mix of terex and oshkosh to be exact). But this one unit rapidserve kept saying to throw a nox at it. It had been overlayed(all4) multiple new pins. Finally got the dsfe involved, the inlet nox wasnt being rational causing the outlet to not see the correct info. Short version is a new inlet and outlet nox fixed it. It was funny when I was reviewing the data after repair to before the difference in the ppm readings (this was before I had the pico)

muttnjeff
TwoWaves
TwoWaves
Posts: 72
Joined: Tue Jul 21, 2020 7:19 pm

Re: Smart Sensors

Post by muttnjeff »

Here's a couple similar scenarios where the NOX sensor was the victim part however due to varying circumstances such as poor fault tree diag from engineering, lack of knowledge/service information, poor communication (people) machinery had multiple NOX sensor replacements before getting the repair right.

Both machines are SP310 F New Holland Sparyer, 6.9L (i think), SCR w/o egr.

Case 1:

Machine was unable to run for more than a few hours before it would derate, various codes for inducement, legislative compliance and NOx conversion.

Local dealer to customer tried to repair 2x, once programming second was a set of NOx sensors, no luck, selling dealer shipped another set of NOx to the customer whom had the local dealer again install, same results as before.

Selling dealer now calls me asking for advice as the tech support service was asking for testing be completed using the engineering flow chart, problem being the selling dealer was an 8hr drive from the customer.

In the conversation with the dealer it was determined that we had more than a simple bad NOx sensor, it was also found that at some point someone had attempted to dismount the DEF injector which was only half attached as the bolts were froze.

Plan for repair was this, tech takes a DOC (with DEF injector attached), SCR and 2 NOx sensors.

While on location tech replaced DOC first, installed new NOx and reset the inducement, test drove it was found the although the DEF/SCR system was trying to reduce NOx it was just too far gone to work effectively, he subsequently replace the SCR, re-validated the SCR replacement and the conversion was exactly where we would expect it to be.

Last conversation with the customer it had ran for 2-3 week with no engine/after-treatment issues.

Later inspection of the SCR it was found to have a area with no pass through hole in the substrate, it was either melted internal or had a mass of DEF crystal built up, area indicated by the circle in the picture.

IMG_E3351[1].JPG

Case 2:
Same basic machine same type of issue,this one would run much longer up to a full day or so before derate of the engine.

Dealer had tried NOx sensors and tech support, no luck same trouble tree as prior case. Dealer calls me and asks if I can get involved, first thing was an updated tailpipe and software (design change on NOx location), no luck, collect some data was next, data looked good, exh temps, NOx conversion was great nothing in the data indicated there was a problem.

In the time this all took place machine went down and another set of sensors was installed. More discussion with the dealer it was found that the machine only fails when idled for a period of time when loading product for spraying.

Since this new info was revealed the customer was asked to not idle the engine, and if shutting down do not let it idle long. I then called a coworker that specializes in engines, after a long conversation I came away with this... This particular engine once up and running produces a higher than normal amount moisture at idle (description was "like a garden hose").

Took this info back to the dealer, advised to replace SCR as it is suspected that under normal conditions the SCR can "block" the moisture produced, since this machine continues to fail down stream NOx sensor it is believed the SCR is physically compromised allowing the moisture to pass through and make contact with ceramic of the NOx sensor.

Once the repair happens inspection of the SCR will be done.

Conclusions...

Lack of knowledge is a huge problem, poor service information compounds the problem and asking a tech working on a machine in field to work through a multi-page A-Z type trouble tree in not realistic.

To my earlier point, these sensors were all communicating, this is why the machine went down, they were telling it to derate, however in order to diagnose the machine has to be reset, and since it has to run through its drive cycle before it breaks down again the tech would have to wait around all day... Not productive for tech.. Not productive for customer.

Scan data is helpful, CAN com verification is good, but to Bens point CAN decoding is the key, if the specific messages can be decoded then we have an opportunity to improve turn time on repairs and increase customer up-time.

Anyway, the more shared, discussed and argued about the smarter we all become. Look forward to seeing what others have and yet to be done.

Post Reply