Help with PID 2F (Fuel)

[FoxSTI]

Guys, I have been trying to get a reading from my dash via ODB2 for fuel level.
the car is a 2015 Subaru STI. I have a full tank of fuel at the moment 14 USgal.

In the dash manager I have gotten up to requesting the PID but I am having trouble getting a value in return that make sense.

From what I have read in order to interpret the value I must apply the following formula.

1000*A/255 or use a multiplier 3921 and Divisor 100
I am sure I am very close but I think I may be using the wrong OFFSET, LENGTH and Bit Mask combination.

From what I understand in the formula above A refers to the first bit of the returned value.
Below is a screen shot of my current setup what is not working properly. I appreciate any help in advance.

[David Ferguson]

That math is already done in the template you show.

If you take 100 / 255 you get 0.3921

So to turn the value transmitted (0-255) into a .1 unit value, you would multiply by 3921 and divide by 1000. That is EXACTLY what the template does.

The only issue is that the units are listed as .1 l (liters), when what we have is really a percentage. But if you're just displaying the number, you should get a 0% (empty) to 100% (full) value.

What does your current fuel gage read (approximately) -- what is the value of "Fuel Level Initial"?

[FoxSTI]

right, I checked the math twice and it should work.
I am currently getting 1.2x or 1.3x I can confirm in the morning my gauge is ready full. I just filled up.

[David Ferguson]

So it's probably trying to ready 120 - 130%, you can change the divisor from 1000 to 10 to see two more digits (and view a ratio as a percentage). It also possible to switch to a real percentage (ratio) channel (like GP Percent 1, then edit the name to be "Fuel Tank Percent"), that will make it easier to pick units like % when setting up the display.

[FoxSTI]

I will try it in the morning.
regardless why do you think it reads "120%" ?

[David Ferguson]

Sorry, I must be sleep deprived. What I wrote makes no sense... I was trying to rationalize the typical gas gauge that shows more than full when first filled up. Of course the ODB value can never be more than 100% if I had thought about it for more than 39 seconds..

Never mind.

[FoxSTI]

according to the reading I have been doing, the car's OBD2 will return :
412F will turn on Byte of information. So shouldn't the offset value be 1 and not 3?

I am just trying to reason a solution.
This morning I used the GP Percentage channel (Fuel level input mapped into it) and I am getting 93% - 86% and the values fluctuate down as the was is in motion and turn back up when stopped. I am attributing this to the actual flotter sensors moving when the car is in motion.

I guess the question is: how can I verify that such PID is really something I can get out of my ODB2 port? Maybe I all I m seeing it bogus "floating" values because 2F is not supported? Could that be a possibility?

PS: What are the GP Percentage channels for?

[David Ferguson]

GP stands for "General Purpose", so they are for this type of application. Seems like 86% - 93% is a believable value if you just filled your tank. Fuel level signals are notoriously noisey due to fuel slosh in the tank,and often are only accurate when stopped on mostly level ground.

I would say monitor it and compare it as you use the fuel in your tank to see how reliable it is.

[FoxSTI]

Dave,

The needed in my car's OEM dash must be getting its signal directly from the sensor in the tank?
I am wondering if there is a way to stabilize the readings on the C125 via some sort of threshold value.
I am wondering I should be using the Fuel prediction Setup dialog box to set my gauge.

[the_bluester]

Working on the assumption that the C125 setup is the same as the C127, about all you could do would be to increase the filter value to average the reading over a longer time.

In my previous dash there was no option to long term average it as you can do in the Motec and it was unusable, the fuel level in L would jump around so much when driving that the display was useless. I went back to a stepper motor gauge which resolves the problem simply by reacting slowly.