This is modern VAG V8 4.0 petrol turbocharged engine.

Complaint:
Engine warning light is ON and the 01 ECU has logged DTC: U066500 Lost Communication with Fuel Rail Pressure Sensor Bank 2

Diagnose:
The B2 fuel rail pressure value monitored on the diagnostic tester is not displaying plausible value, the DTC U066500 is static and cannot be deleted.

The easiest way how to move forward was to check the wires and socket on the B2 fuel rail (HP) sensor as the sensor can be easily reached after removing the engine plastic cover. There was visually all OK and because we have PICOSCOPE in the workshop, to back pin the 3 wires or use Pico breakout leads was the next move (such check but limited could be done by multimeter in voltage range as well).
The result was 5V present on all 3 wires of the G624 sensor. (we were using breakout leads which is electrically the same as if the connector is plugged directly to sensor and each of 3 wires back pinned by needle probes)

There shouldn't be 5V on all 3 wires, now was the time to check the wire diagram. See the affected G624, the B2 rail fuel high pressure sensor and also the G247 which is btw. the same sensor for B1. Both sensors getting ground and 5V reference voltage and ground directly from the engine ECU. The same connection is on the low fuel pressure sensor G410 (pin no on sensor different only). All 3 sensors are providing signal to ECU by the 3th wire. (later we have learned it is digital signal using serial data bus connection SENT "Single Edge Nibble Transmission")
This could be a shortcut of the wires somewhere in the wire loom before the connector to sensor? Or the sensor faulty? First lets see what the Picoscope shows: The fuel pressure sensor B2 does not work as the ECU does not provide “earth” on the pin no 2 at T3gr connector to the sensor G624.
- There is a comparison (Blue) waveform of the signal from the B1 rail fuel pressure sensor G247, displayed on Blue channel A.
- The FAULTY fuel pressure sensor B2 signal waveform is Green colour and constantly on high voltage 5V.
- The Channel B (Red) and D (Yellow) is the ground wire of G624 connected on the sensor side (Red) and backpined on the ECU side (Yellow). Both sides of the ground wire are high voltage, means no ground on either side (a possibility the wire is cut or interrupted in the middle is out).
- The ground and signal as well as 5V power supply is provided by the ECU, the wires are connected directly to ECU.

We have decided to introduce the "artificial" ground to the pin 2 of sensor G624 by test light, it has 5W light bulb so such "ground" should not burn anything and should provide some reasonable good ground for the quick test. On the waveform above is the G624 fuel pressure sensor B2 already working because we have introduced “artificial” ground. The test light did not even light up (very small current) so we have grounded it by extra wire instead of the test light as it was safe now.

Below is the functional sensor after the ground is introduced and DTC deleted.
The reading is correct and responding to engine acceleration accordingly. The conclusion:
- This basically proves the G624 high pressure fuel sensor is functional if the ground is provided.
- The GREEN waveform is the signal from the B2 G624 sensor and the
MVB on ODIS are displaying true fuel pressure on both rails.
- The DTC is possible to delete and does not log back after ignition cycle and several engine start/stop cycles.
- The engine ECU is faulty and must be replaced for new part, somewhere inside of the engine ECU is internal fault causing the ground open circuit.

At the end:
- We have spent about 45 minutes on the car where most time took the ECU side pin of the G624 ground wire identification. Also connecting the diagnostic scanner and back pin or install the breakout leads on the sensors.
- If we have used the "traditional" way like swapping the fuel pressure sensors between the banks and measuring resistance/continuity of each wire between the ECU and the G624 sensor by multimeter, the diagnostic time taken would be much longer.

Repair:
The Engine ECU has been replaced and this rectified the fault, no engine light ON and no DTC logged in ECU fault memory.
Thanks to Picoscope

Below are pictures how we have connected the Pico to the sensors and ECU, it looks messy but that is from the real life diagnostic. Thank you for reading.

Great case study - many thanks for posting!
Alan

Hello,
On the new SENT sensors is very interesting the PICO decoding, I have attached a capture of the good known car for anyone who is interesting to play with the decoding.
As I remember, we have most likely accelerated (stationary) somewhere within the waveform capturing and If so, the pressures and temperatures should be changing. I have tried the SENT bus decoding, slow and fast in many variations but the result is not much readable to me. If I get into similar measurement next time, I will connect one channel to crank sensor signal to capture the engine speed as well.
Regards,
Roman

Hello,

Thank you for this. It's a great case study that shows us these sensors that are already out there but not seen much. I'm doing some research into how we can get the best out the data from SENT sensors and having some success. It would be great if you can share any captures you have going forward and I might put together a different settings file if I'm not quite seeing the important things in the slow channel

Thanks again and keep up the good work.

Kind regards

Ben

Hello

That's a really interesting case study you have created here which covers the decoding of a rail pressure sensor which is using the SENT protocol to transmit both pressure and temperature signal to the ECU.

Maybe I can help you with some of the decoding of the SENT protocol, but firstly I most ask you some questions about this high rail pressure sensor (G624).

I already know the sensor is made by SENSATA from the manufactor code which have the data value 5 in the decoding file.

And now my question.

Du you know the pressure range of this sensor or perhaps the spare partnumber ?

And what are the pressure at idle speed and full throttle speed ?

Best regards
Kim

I managed to find the correct part number of this rail pressure sensor which is used in this particular engine type 4.0 Litre TFSI V8. The spare part number of this sensor is 06L906054C which have a pressure range at 0 to 350 bar and are manufactored by Sensata.

For those who are interested in decoding the rail pressure sensor which uses the SENT J2716 protocol will I say - its not easy to decode if you haven´t got the correct SENT protocol document from SAE.ORG.

I will here be concentrating soly on how to decode the 12 bit encoded rail pressure signal which also include the temperature of the fuel and a internal measurement of the sensor itself - so only the pressure signal are here coveret.

By looking at the first file that Rfmotors had uploaded here - can we see many interesting things decoded in the slow channels ( CH A and CH C ) which is the pressure sensor on each cylinder banks.

But what is needed to decode this sensor ?. It depends on how much you already know about SENT signal sensor and there linear transfer characteristic functions also known as the scaling factor.

There are five things shown in this file which covers the basic paremetres of this pressure sensor and which is vital for correct scaling factor and they are only shown in the SLOW CHANNELS.

Just to remember that the 12-bit encoded pressure data value are shown in the FAST CHANNELS which Rfmotors didn´t decode.

I have here highlighted the most important values from the slow channles which are ( Fast Channels 1 Characteristic X1,X2,Y1,Y2 ) and the ( Channel 1 / 2 Sensor Type ) which is a very important when you those your settings in the picoscope decoding window - dont forget to select the correct sensor type in the FAST CHANNELS decoding window.


Before we move on to the calculation or decoding of the rail pressure signal - I just want to point out a very important note regarding the Fast Channels 1 Characteristic ( X2 ).

Lets say you dont know the pressure range of the sensor then it becomes a little harder to find the Fast Channels 1 Characteristic ( X2 ) value.

In this rail pressure sensor the range goes from 0 to 350 bar where where X1 equels data value of (0) and X2 equels a data value of (286) both values are decimal.


To convert the X2 (286) into a pressure range we can use in our calculation formel we must first transform the 286 decimal data value into a 12-bit binaer value which looks like this.

The 12-bit binary value of 286 decimal is ( 0001 0001 1110 ) and the binary value are counted backwards, so the first 3 bits ( 110 ) which is the same as a decimal value of 6.

So the decimal value of 6 is the exponnet 1e6 or the same as 1.000.000. Then the rest 9 bits are (0001 0001 1) which equels a decimal value of 35, so the pressure range of this sensor is 35e6 which is the same as 35.000.000 Pascal or 350 bar.

The above binary calculation are only necessary if you don't know the pressure range of your sensor - I must admit that this is the hardest part of the pressure range calculation to understand.

The calculation of pressure value is a matter of using the formula.


If one could wish something regarding decoding of the SENT signal would it be digital to analog conversion of the signal into curve - that would be really cool feature to have, but I suppose its only Picoscope that could answer that question.

I´ve seen such a function on Leroy oscilloscope where its called MessageToValue which is decoding the signal in realtime.

Happy decoding.


Regards
Kim

Hello all,

Firstly, thank you Kim. Your input here has been most welcome and I must admit, understanding the X characteristics is something I struggled with especially as you say when the sensor range isn't known. I have also been working with better understanding how Pico can help us visualize SENT and hope the following helps.

I’m not going to spend too much time on what SENT is. There are some great trainers out there that will do a much better job at describing how this protocol works. To give brief insight into this network though, SENT stands for Single Edge Nibble Transmission and follows the J2716 standard. It is a low cost, Uni-directional (one direction only) so the sensor can only send data out. What makes SENT different is that multiple pieces of data can be ‘sent’ over one wire for example, one sensor can send both pressure and temperature measurements using a single wire. This makes it low cost and reduces cabling, something manufacturers are always looking to do. This means you may well see a MAF sensor with just 3 wires which when measuring you will have a 5V supply, ground and the data.

As above, SENT has the ability to transmit more than 1 piece of data and it does this by making up SLOW message from ‘nibbles’ taken out of the FAST message. In order to build up a slow message it takes multiple fast messages but more importantly both of these can be decoded in Pico using the serial decoder. What does a SENT sensor look like then?
This capture was taken from our forum where a member had kindly uploaded it. To see the post please see here - https://www.picoauto.com/support/topic21901.html

You can see that it could quite easily be mistaken for a PWM signal given it is 0 – 5V with a seemingly varying change in duty cycle. You may also notice throughout this article that there is signals that appear inverted. This isn’t deliberate but just another characteristic of the SENT protocol as the polarity of the signal can change but the data remains the same.
Just so we can all see how the SLOW signal is made up, I’ve already added the decoder but I will go over how to set each one up. From the above then we can see that there are a number of FAST packets of data required to make up the one SLOW message. This is important to note as the SLOW message contains so extremely useful information related to the sensor but it is necessary to take a long enough capture to ensure you have all the data.

If we continue to use the above data and begin to add the decoder in but it is useful to start with the SLOW decoder first.
Click Tools > Serial Decoding > Create> SENT Slow.

The reason for starting with the slow message first is because quite often information about the sensor can be found in here. The FAST decoder provides you with a number of options as to how you would like the decoder to work based on the sensor type you are measuring.

In order to complete the decoder, the software will automatically set some paraments for the thresholds based on the channel selected. You will notice that this signal isn’t ‘clean’ and has some interference which can be cleaned using the LowPass filter in the channel options. I’ve found that 300 kHz works well. The other options is to amend the settings yourself in which case you will need to inform the decoder what voltage threshold to decode with and any hysteresis you would like to include. The following settings where done after the LowPass filter had been activated but settings you can use would be 3V with minimal hysteresis.
Once completed click OK and then ensure the decoder is ticked before clicking OK once more. The table will now form at the bottom of the waveform with some information. Now we can see some human readable data! Unfortunately, we are missing some additional sensor information. If we had a little more time on the screen would have meant we could get additional information on the sensor meaning we can create a SENT Fast decoder more accurately.

Using the same process to setting up the Slow decoder we apply it to the following capture. For clarity the following sensor is a pressure sensor used in an EGR cooler. The capture was taking with the engine started and then performing a snap WOT test.
A lot more packets of data present given us more chance to find some of the additional information transmitted in the SLOW signal. You can also see the Characteristic values for X1 and X2 which as Kim explained above are needed to translate the data into a physical value. Packet 8 at this point is the one we are interested in and as you can see it gives us the information relating to the sensor type. This is important when it comes to setting up the FAST decoder and we can see we have Pressure/Secure sensor. The additional data can be equally as important though especially the Manufacturer code. The message ID actual refers to list that can be used to determine who makes the sensor.

It is available with a quick search on the internet but for reference the ones that I’ve found so far are listed below – There may well be others added in the future.

Heading back to PicoScope then and looking to the serial decode tool we now select SENT FAST from the list.
Here you’ll see that knowing the sensor type is important to us as we can select the specific sensor from the list. We know from earlier that it is a Pressure/Secure sensor. Again, I’m not going to go into too much detail here as it’s not the purpose of the article but basically the format of the data field changes depending on the sensor type. Pico allows you to pick out the type of format you want from the standard J2716 list.
Now we have both the Slow decoded data and the Fast data in the decode table. To flick between the two, you can click on the tabs for each table at the bottom of the screen where the labels for the SENT Slow and SENT Fast are visible.

The next step in order to better understand what this sensor is doing is to use the export function in PicoScope. On the decode table ensure you have the SENT Fast tab open and the decode only operating on the Current Buffer only, then click Export. You will then be asked to save the file in a easy to find location. I always find the desktop a good one to go for!

With file saved, locate the file and then double click to open in Excel. You will now be presented with the same decode table from PicoScope but with the ability to further manipulate the data. Steve has a number of posts on the forum where he has used Excel to pull further information from captured data one can be seen here - https://www.picoauto.com/support/topic21593.html?&p=97888&hilit=excel#p97888
Whilst on the surface it looks quite overwhelming, we are only going to do something very simple in order to visualize what the sensor is doing in a way we are familiar with. The data packet for the SENT message is actually split up depending on the type of sensor it is which are labelled as Channel 1 and Channel 2. Below is an example which hopefully explains it in more detail.
When you apply the SENT Fast serial decoder in PicoScope you are telling the software how you want the data to be split up. In the image above this would be a typical even split for the data field so 12 bits for Channel 1 and 12 bits for Channel 2. We know that the sensor we are looking at in Pico is a Pressure/Secure sensor and when looking through the J2716 standard the Pressure data is present in Channel 1. Returning back to the Excel sheet in order to visualize the data we need to create a chart. Select Channel 1 column, column D, and by clicking on the column header it will select the entire column.
With the data selected now select Insert and then locate the Line Chart option.
You can now see the graphed image of data which we acquired from the SENT sensor. Whilst it looks a little basic, we can zoom in to the graph by amending the date in the graph. I admit this is a little ‘clunky’ at best but if it’s all you’ve got then it’s better than nothing!

Selecting the data source and then amending the data range will allow us to focus the graph on an area of data we would like view more closely. Below I have chosen to view between D5625 and D12140.
Below, I have amended the range again to be between D5625 and D6625. I think we can agree that what we are looking at is something resembling an exhaust pulsation waveform.
The exact same process was applied to MAF sensor that used a SENT sensor to send out air flow and temperature. Data was capture with Pico, decoded and then exported and a chart was created using the data present from Channel 1. Similar test carried out with engine idling moving to a WOT snap test.
Again, amending the range changed the ‘zoom’ of the capture.
The one problem I've run into is I can’t correctly take the value decoded for the channel 1 or 2 and translate this into a unit of measurement we can relate to. Kim mentioned that in order to do this correctly you do need the pressure range of the sensor in order to do this which is sometimes tricky to find. That being said I feel that this is an extremely useful way of visualizing a SENT sensor that we couldn’t before. You could graph the data from a serial scan tool but I would be worried that the refresh of PID data will miss something which for intermittent faults could be vital.

For both the exhaust sensor and MAF sensor I’ve found it best to take long capture, between 1s/div and 2s/div and keep the sample rate high, aim for 10MS. This will hopefully ensure that the samples can be decoded correctly. I have seen that I get the Yellow warning triangle for ‘Sample rate may be too low,’ but I’ve not had any issues with the decoding as of yet. There are ways to ensure no loss of data and one would be to add a single trigger but you have to be ready to perform the snap test. We will continue to work on trigger functionality as it’s one thing I’ve found tricky when capturing. Other options would be to use another channel accelerator pedal position or brake switch. Once you’re all set up a quick touch of the pedal will trigger the scope ready to capture the data for decoding.

I hope this helps and please feedback with any suggestions and if I can get the units working, I will update.

Ben

Hi Ben

Do you have the psdata file for the EGR pressure sensor so we can have a play with it?

Regards

Simon

Hello Simon,

Of course. I hadn't added them to the post due to their size. Could you message me and I'll send on via another method.

Kind regards

Ben

Hi Ben.
I would like to take a look at this file to play with it as well.
Could you sent this file, please
Kind regards
Dario