High pressure fuel sensor no ground, SENT signal

[leonardorj]

Bem bacana, um post antigo mais atual. Hoje já temos alguns Corpo de Borboletas assim na linha GM.

[robnic]

Great write up Roman thanks for sharing, nice find to.

[Steve Smith]

Decoding of a Denso SENT Differential pressure sensor (Part No. A 000 905 65 03)

The following post looks at decoding a Denso Differential pressure sensor that I acquired from the following case study viewtopic.php?p=104529#p104529

The vehicle in the link above suffered excessive exhaust back pressure accompanied with DTC P245296 (Exhaust gas differential pressure sensor [DPF] Internal fault)

Prior to introducing a WPS500X Pressure transducer into the exhaust, other than serial data, there was no way to qualify the data being streamed from the SENT DPF sensor

To cut a long story short, the WPS500X confirmed the exhaust back pressure to be excessive and ultimately the SENT data stream from the DPF sensor to be correct (The fault code description leads you to think otherwise!)

Replacing the downstream exhaust system (SCR/ASC) cured our issue and so “job done”

Now, the DPF sensor from this vehicle has sat on my bench for a while and given we have a SENT decoder with PicoScope 7, see Ben’s post on how to decode SENT here viewtopic.php?p=99866#p99866 and Kim’s post on the conversion of SENT data into pressure units here viewtopic.php?p=99749#p99749 the temptation to reverse engineer this Denso sensor was too much too resist

The nature of a SENT sensor is such that when connected to power (5 V) and ground, it will begin to stream data that will change in proportion to a pressure applied to the sensor ports

In order to decipher the operating characteristics of the sensor (X1, X2 & Y1, Y2) we use the SENT slow decoder as described in Kim’s post above. However, looking at the decoded data below the operating characteristics of this DPF sensor are not displayed!

1

In the capture above we have a sweep time 5 seconds (500 ms/div), my initial thoughts revolved around more time being required to reveal the operating characteristics of the sensor (X1, X2 & Y1, Y2). I can say even with longer captures, these fundamental requirements to “map” the DPF sensor operation and turn the values obtained into pressure units were never visible

So where to now and how can we turn the data found in the SENT Fast decode table (Ch1 & Ch2) into pressure units? The answer is reverse engineering (which is not without pitfalls!)

Below we use a Mityvac to apply both positive and negative pressures to each port of our DPF sensor, whilst simultaneously capturing the pressure applied (with WPS500X) and decoding the SENT data output from the sensor.

2

Hopefully, in the image above, we can see how the DPF sensor is supplied with +5 V & Earth resulting in the output of SENT data which in turn is connected to channel A of PicoScope. On channel B we have the WPS500X connected in series with the Mityvac and a port on the DPF sensor

Below we have captured the data on Ch1 in the SENT Fast decode table which changes in direct proportion to the pressure applied to the Pre CAT/DPF sensor port.

3

With reference to the image above, “Scope 2” viewport has an overview of the SENT data streamed from the DPF sensor (Scope Ch A) and the pressure applied to the sensor port (Scope Ch B).

Looking now at the decode table, we can see the precise point where our sensor output reaches a max decimal value of 4088 (Packet No. 315 at 265.2 ms) regardless of the ever-increasing pressure after 265.2 ms.

Double clicking on packet no. 315 will take you directly to the packet location within the graph view which can be seen in “Scope 1” viewport. Placing time rulers at the start and end of packet no. 315, we can use the Mean measurement function (between the time rulers) to denote the pressure value applied to the sensor port (1.176 bar)

Here we have found several key pieces of information to help us characterise this DPF sensor; i.e. we know when our sensor output reaches a maximum decimal value of 4088 (Ch1) the pressure at the sensor port = 1.176 bar. Here we have found our SENT Y2 value (4088) and X2 value (1.176 bar)

The above process is repeated only this time, to find the minimum decimal value from the sensor when a negative pressure is applied to the Pre CAT/DPF sensor port.

4

Referring to the above image, we can see the precise point where our sensor output reaches a minimum decimal value of 1 (Packet No. 1450 at 1.223 s) regardless of the ever-decreasing pressure after 1.223 s

Double clicking on packet no. 1450 will take you directly to the packet location within the graph view Placing time rulers at the start and end of packet no. 1450, we can use the Mean measurement function (between the time rulers) to denote the pressure value applied to the sensor port (-111.6 mbar)

Here we now have the final pieces of information to complete the characterisation of our DPF sensor i.e. we know when our sensor output reaches a minimum decimal value of 1 (Ch1) the pressure at the sensor port = -111.6 mbar. Here we have found our SENT Y1 value (1) and X1 value (-111.6 mbar)

To summarize

Had our decode table contained the X & Y characteristic values (as described in Kim’s forum post earlier) we would have found

• X1 = A decimal value representing -111.6 mbar
• X2 = A decimal value representing 1176 mbar
• Y1 = 1
• Y2 = 4088

Now, rather than trying to determine the decimal value used to represent X1 & X2, we have enough information above to plot the output of our DPF sensor between the X & Y values obtained above

Given the output of the DPF sensor is linear between the two measured points (X1 & X2) if we calculate the scale and offset values for the DPF sensor, we can convert any of the displayed decimal values in Ch1 of our Fast SENT decoder table into human readable pressure values!

It is at this point we are going to deviate from the graph below which describes how a SENT sensor is encoded by plotting the displayed decimal values in Ch1 of our Fast SENT decoder against the pressure values via the WPS500X

5

Instead, from here on in, we are going to plot gauge pressure in mbar (X1 & X2 obtained via the WPS500X) against our sensor output decimal value (Y1 & Y2 found in Ch1 of our Fast SENT decoder table) In order to do so, we need to amend the graph above to plot pressure against our Fast SENT decoder decimal value (Ch1) This in turns means we have to change our X & Y values around as seen below

• X1 = 1
• X2 = 4088
• Y1 = A decimal value representing -111.6 mbar
• Y2 = A decimal value representing 1176 mbar

Whilst I know this is confusing (please bear with me) once you have the values ordered as above, you can use this technique to decode any linear output based on just 4 points. i.e. 2 x physical values (e.g. Pressure or RPM) and the 2 decimal values used to represent the obtained physical values. See the revised graph below

6

To graph the output of a linear sensor, we need to know the scale and the offset values to apply to the “raw” decimal values acquired (Ch1 in the SENT decoder table using our example above)

This is where we utilise the formula for a linear equation “y= m.x + c”; please do not dwell too much on this at present.

We can rewrite y = m.x + c into something more “human”:
Final Value (y) = Scale(m) multiplied by Raw decimal value (x) + Offset (c)

To first determine the scale, we use the following equation:
(Y2 – Y1) / (X2 – X1)
1176 – (-111.6) / (4088-1)
1287.6 / 4087 = 0.315048
Our scale is therefore 0.315048

An easy way to remember the above equation is to use Rise/Run where “Rise” is our range of values on the Y axis and “Run” is the range of values on our X axis

At this stage let’s begin to add in the values we know into the linear equation y = m.x + c

Below we have opted for known “y” value 1176 mbar represented by our known “x” decimal value 4088

Final Value (y) 1176 mbar = Scale(m) 0.315048 multiplied by Raw (x) 4088 + Offset (c) which is unknown. The values alone are: 1176 = 0.315048 x 4088 + c

To find “offset” we need to transpose y = m.x + c into c = y – (m.x)

Using our known values above this looks like:

Offset (c) = Final Value (y) 1176 mbar – (Scale(m) 0.315048 x Raw (x) 4088)
The values alone are: c = 1176 – (0.315048 x 4088)

c = 1176 - 1,287.916224
c = -111.916224
Our offset “c” is therefore -111.916224 mbar (note the offset is negative)

With our offset value known, we can return to the equation above to qualify the maths
Final value = 0.315048 x 4088 + (-111.916224)
Final value (y) = 1176 mbar

Let us further prove the above maths using the capture below where the Mityvac is used to apply a negative pressure. Taking random packet no. 1412, we can see the Ch1 of the SENT decoder displays a raw decimal value of 116

7

Using the equation Final value = Scale x Raw + Offset we have:
Final value = 0.315048 x 116 + (-111.916224)
Final value (y) = -75.370656 mbar

Referring to Scope view 1 above our measurement between the ruler we have -70.37 mbar suggesting an error of 5 mbar, which we will come to later on!

Continuing on with this style of SENT DPF sensor (A5. Pressure [12 bit + 12 bit]) we have 2 x pressure sensors in one device, one of course sensing pressure pre-CAT/DPF (which is characterised above) and one post DPF, both of which have different X & Y characteristics.

An identical test was therefore carried out to the post DPF sensor port using the Mityvac to determine the maximum and minimum raw decimal values (Ch2 in the SENT decoder table) in response to positive and negative pressures applied, see results below.

• X1 = 1
• X2 = 4088
• Y1 = A decimal value representing -280 mbar
• Y2 = A decimal value representing 978.4 mbar

Now, rather than go through all the maths again for the second half of this DPF sensor, the spreadsheet below will take all the pain away (thanks to Oli Hayward @ Top Technician) and return the scale (Slope) and offset (Intercept) thanks to the magic of Excel formulas

By entering the above X & Y values into the spreadsheet below, we can see our scale is 0.307903107 and our offset -280.3079031

8

Please find a copy of Oli’s spreadsheet below and feel free to use with any decoding you wish to carry out. All you need is 2 decimal decoded values and their corresponding actual values (e.g. bar, rpm etc.)

Gauge values scale and offset.xlsx

Sheet

(12.23 KiB) Downloaded 378 times

So how do these calculations help in the real world?

At the start of this forum post I mentioned the case study here viewtopic.php?p=104529#p104529 and no way to qualify the data being streamed from the SENT DPF sensor. Unfortunately, my sample rate before fix was too low for the SENT decoder, however, after fix, my sample rate was sufficient and here we can use the "Template" feature in our SENT serial decoder to display pressure values rather than Ch1 & Ch2 raw decimal values.

With the Fast SENT decoder applied to our captured data, click on the “Data to text” button followed by “Create Template”, then save as a .csv file. Note, to reduce the amount of data to wade through, we have opted to decode between the Time rulers where our exhaust back pressure is at its peak (Channel C green)

9

Open the saved .csv file and number columns G and I (Ch1 & Ch2 respectively) from 1 to 4088 using the “Series fill” function below. Values 1 to 4088 you will recognise as our raw decimal values seen in Ch1 & Ch2 of the serial decode table

10

Now apply the relevant formulas containing the scale and offset values (acquired from our previous spreadsheet) to Ch1 & Ch2 Description columns

For example: In column H2 (Ch1 Description) type =G2*0.315048 + (-111.916224) and in column J2 (Ch2 Description) type =I2*0.307903107+(-280.3079031)

11

Save the above .csv file and return to the psdata file above. Click on “Data to text” once again but this time, select “Open” and locate/select the .csv file above which includes the descriptions for Ch1 & Ch2. (See below)

12

PicoScope will now load this .csv file and apply the descriptions to Ch1 and Ch2 which now display pressure units in mbar rather than raw decimal decoded data (See below)

13

Using the decode table above, we can now double click on packet 3005 (we are now decoding the whole capture rather than between the time rulers) to jump to the precise point in the graph where our DPF sensor reports an exhaust pressure of 119.960 mbar (pre DPF/CAT)

If we now subtract Ch2 (Post CAT/DPF) from Ch1 (Pre CAT/DPF) we derive a differential pressure of 119.960 – 98.413 = 21.547 mbar at approx. 2.5 seconds into our capture under WOT which is consistent on a vehicle with an entirely new DPF/SCR system

My concerns at this stage however switch to the value displayed by the WPS500X that is inserted between the DPF sensor hose (Pre CAT/DPF) and the DPF sensor itself.

Here the WPS returns a Mean value of 240 mbar which is what I would expect at WOT full load but not what is reported by the DPF sensor!

I mentioned "Accuracy" earlier in this study as we had chosen to use 1 and 4088 as our raw decimal values upon which to base our scale and offset values.

The SAE paper for the SENT Protocol (J2716 Revised JAN2010) informs that where no raw decimal values are quoted in the SENT Slow decoder, the default values will be Y1 = 193 and Y2 = 3896 to ensure accurate measurement of pressure values with guaranteed tolerances.

This may well improve the discrepancy we found earlier on when our raw decimal value of 116 decoded into -75.370656 mbar (WPS returned -70.37 mbar) but certainly not the 120 mbar error we see between the DPF sensor and the WPS500X under WOT

With all that, I have more work to do to put this to bed and I hope the above will be of some use when decoding raw decimal values for other sensors

It would be great to have any feedback on the above and any suggestions as to why the 120 mbar discrepancy exists. My gut feeling is a measurement error during the diagnosis of the Mercedes as the decoded values were correct during the bench test with the Mityvac

I hope this helps, take care……..Steve

[KimAndersen]

Hi Steve

These SENT sensors can be a bit of a challenge when we don't have any specific data sheet on this type of sensor.

As you show with your reverse engineering, it is possible to convert the digital SENT signal to a pressure value and then make a graph.

So far so good.

Your post made me a bit curious if it was possible to find a technical data sheet for this specific type of sensor.

There is not much to be found on the big net. The big factories that manufacture this type of sensors do not have any data sheet available for public persons.

But I managed to find a Spanish company ( FAE.ES ) that makes many different sensors for the automotive industry and that had a data sheet about this type of sensor.

This exhaust gas pressure sensor #16163 from FAE fits the Mercedes-Benz you made this case study for. It is possible to check this on their online web catalogue.

The first time I saw the specifications for this sensor FAE #16163 I was so confused - that I had to ask FAE one more time if it was correct - that the pressure range this sensor covers is from 250 kPa to 3250 kPa and they replied that it was right!!!.

I still can't understand - that this sensor has a measuring range from 250 kPa to 3250 kPa - I'm so in doubt.

So the coordinates X1 ( 250 kPa) and X2 ( 3250 kPa) have now been found and we now just need to find Y1 ( 0 dec ) and Y2 ( 90 dec ), which are easy to find in the data sheet and we can thus calculate the scaling on this sensor.

According to this document from FAE.ES the coordinates Y1 and Y2 are what are called sensor specific values ​​and not default values, that's my immediate guess.

Default values ​​are Y1 (193) and Y2 (3896) as you also mention.

The exhaust gas pressure sensor you tested was Denso brand - so of course it's not the same sensor we're comparing - but it should be the same scaling I suppose !!!.

So Steve - I don't know if this data sheet from the FAE is of any help to you - it has me confused anyway.

16163_FAE_EXHAUST_GAS_PRESSURE.pdf

FAE 16163 EXHAUST GAS PRESSURE SENSOR

(332.11 KiB) Downloaded 367 times

Regards
Kim

[Steve Smith]

Hi Kim, I hope you are well and thank you so much for pursing this and feeding back

This whole episode of reverse engineering is still niggling me regarding the discrepancy between values on the bench and those from the case study!

If you are confused then I am adrift but rest assured we will crack this one and the information provided will help someone somewhere which makes it all-worth while

I am away now for 10-days and this might help clear my head where I hope to refresh and pick this “adventure” back up again

I know this is sad but I may also take a quick look whilst away on a break

Take care……Steve

[Labbis]

Hello,

I have read through this post and feel that I am in the presence of peole a lot smarter than me, the amount of information is allmost overwhelming and in the same time highly inspiring

I was so motivated after reading this post a few times that i started my own project to decode the Bosch Denoxtronic 5 AdBlue-supplymodule which is known as SCR Gen.4 in Mercedes. I have search allmost the whole internet and found very little information on the system that would reveal anything specific, so all the following is only my own conclusions and not necesserily facts…. might even be far from it.
About the system: It has a 3-phase diaphram pump and two SENT signal lines. I will refer to them as SENT A and SENT B according to the channels.
The supply unit contains: 2 level sensors, a DEF quality sensor, temperature sensor,pressure sensor and a pump motor RPM sensor

Scope and decoder settings I used were: 10volts, 50ms/div, 5MS, DSP filter on.
Sensor type on both A and B = A5. Pressure( 12bit+12bit)
SENT A = 30tick
SENT B = 90tick
All the decoder files i made were with the use of the Excel: Gauge values scale and offset.xlsx
that Steve posted earlier.

FILL LEVEL:

On SENT A Fast I found the level sensors 1 & 2
Simple testing with a refill and recorded all the values from the Scan tool:

I took the data to Excel and graphed it, the two level sensors draw on opposite directions

Fill level graph

I made a decoder file that chances the values to fill level % rather than millimetres, the Mercedes Xentry has ODX files for each type of vehicle and they all have different size and shaped tank
Xentry allways presents raw1 and raw2 in millimetres.

Decoded 78% Fill level

Decoded 100% Fill Level

The Scan tool allways rounds up every measuring value to an even number, there a no decimals in the fill levels or temperatures so my scaling+ offset are surely a bit off, but from a mechanics point of view the 0,1% is not significant because its not going to put the system at its knees.





ADBLUE PRESSURE AND PUMP RPM:

On SENT B Fast I was at a loss for a long time, because the numbers seemed too random to present anything that made sense.
But then it hit me that there is also the pump RPM because i have seen it on the scan tool and it was around 4400-4500 when i did the pump pressure test so the RPM had to came from the supply unit via the SENT line.

One motor revolution 13,18ms-> 75,85Hz -> 4551 RPM

SENT B Fast values

Pressure and RPM decimal values

Decoder file made using the measuring values of the Scan tool:

Pressure and RPM decoded values

CH1 = Pressure
CH2 = Pump RPM

I read on the technical data of the system ( bosch prochure on google) that it is a non-return system and the pump control i so precise that the pressure peak for each injection is done separetly, but still trying to wrap my head around that…can it really be that fast?


I took the decoded data to excel and graphed it and it is easier to visualize

AdBlue pressure & RPM graph

TEMPERATURE:

Both Fast channels decoded so where is that Temperature hiding??

on SENT A Slow

AdBlue temperature SENT slow

Made a decoder file just to look for the temp, it does mess up the other Data values.
W447 Vito with 24 celsius on the tank

Vito 24 celsius on the tank

W907 Sprinter with 1 celsius on the tank

Sprinter 1 celsius on the tank

AdBlue Quality:

The only thing I havent figured out is the AdBlue quality, i have a gut feeling that its in the same SENT A slow as is the temperature.

On SENT A Slow there are Sensor ID:s #2, #3 and #4
#2 has a decimal value = 2721
#3has a decimal value = 2994
#4 has a decimal value = 3267

2721+3267 / 2 = 2994 so ID#3 could be an average value of the other two but really I have no clue yet.

I need to do some testing when I have a tank with low quality Adblue on it or the other option is that I have to saw open a tank and hook it up with 5volt supply and start doing some testing with different solutions

If anyone has any ideas about the topic I would really like to hear about them and off course feel free to comment in any other way. It is my first post so the layout is probally a bit messy and things are not presented and explained a clearly as Steve, Ben and other experienced forum users..

Still I feel it is a good start for something that might help others,because that AdBlue system has been installed by so many VMs in the past deacede.


Best regards,
-Jarkko-

[Rfmotors1]

Hi Jarkko,
This is incredible piece of work and information you have posted here for us, I am going to study it and learn from your information and files you have posted. Thank you so much again.
Best Regards,
Roman

[KimAndersen]

Hi Jarkko

What a fantastic presentation you have given here. I'm sure we can learn a lot from each other by sharing our experiences, good and bad.

Sometimes you can see a problem from a different angle by being open to the approach of others – in relation to a concrete diagnostic process.

You have provided a lot of information in your post - which is good. But it sometimes requires - that you read it once more just to familiarize yourself with the user's way of thinking.

By reading your post, I became curious to know something about the two temperature measurements you have taken from the Adblue tank.

One temperature was 24 degrees Celsius and the other 1 degree Celsius - are these data values ​​(highlighted yellow) taken from your scantool and then pasted into an excel file ?.

Finally, I just want to say that you just need to keep coming up with more great posts like these.


Best regards
Kim

[Labbis]

Hello,

Thank you for the kind and positive feedback, really glad to hear that you have read it all the way through
For Kim's question its good that you asked because I might have not explained it very well with Temperature.

All the Temp values were collected from the Xentry scan tool.

In the SENT A Slow:
Sprinter 1 celsius had a decimal data value of 1252 --- > Excel table turns 1252 to 1 celsius

Vito with the 78%fill / 24 celsius had a decimal data value of 1838 Excel table turns 1838 to 24 celsius

Vito with the 100%fill/ 25 celsius (in the psdatafiles i had a typo/ temps mixed up) had a decimal data value of 1851 Excel table turns 1851 to 24,51024-> that scan tool rounds up for next even number 25 celsius according to normal rounding up rule I think. the added 22% of new AdBlue was so warm from the warehouse that it makes sense that the tank warmed up 0,5 degrees.


Good that your question got me thinking why would the temperature scale end at -10,5 celsius, Xentry scan tool gives you target range for the temp -11 to +60 celsius but from what I have read online the usual range for AdBlue temp sensor is -40 to +80-100 celsius.

Using the knowledge what was earlier on the post I made a more wider scale for the temp sensor, as it says in the SENT slow: Y1 = 193 and Y2 = 3896
Scale + offset calculated as in the photo

AdBlue temp scale and offset

Now the new decode file has a range on -40,5648 celsius --- > +104,7747 celsius.
The new file is attached in the end of the post.

I know its early days to release the files as I have not tested them for more than 3 different Vans.
Next step for me is to test these files as many cars and vans as possible to see does they work and also make more accurate scaling+offset.
At least these countries that -11 celsius and colder weather is normal day at the office, in a few months its going to AdBlue-system warning light season for the workshops.. as far as I know these systems are in VAG diesels, some BMW models, Mercedes, some Renault and i think many more, so here in the forum there might be Pico users that can test these as well and even might get some help in the diagnosis.

From what I have experinced with these systems if they freeze well beyond the -11 celsius its fairly common that one or both fill level sensors will go to 0mm.
The usual routine in the workshop is to load test and resistance measuring of the wiring harness and checking the connector terminals when they are confirmed okay--- > next is to swap in a new AdBlue container.
Then it gets interesting, the new container shows exactly the same values as the last one... bye bye 3000e.

Usually the problem goes away either putting the can bus to sleep and letting the tank warmup to at least +18 celsius if that does not wake up the fill level sensor(s) then its ignition on, CAN bus active and empty and then fill up the AdBlue container.-- > My working theory is that when the heating element warming up period ends and the tank has not melted all the way, level sensor fault sets off AdBlue system warning stage 1,2 and 3 depending how much you drive. When the warning strategy is active the Control unit does not update the measuring value form SENT to CAN bus.
Thats why i chose this specific system to be my victim of research, a tool to see is the tank actually sending the recuired info or not and to avoid an unnecessary tank swap. This is one of those cases that scan tool data is not to be blindly trusted.


Best regards,
-Jarkko-

[PicoBarney]

Fantastic work, Jarkko.

Many thanks for your contribution.

Barney