The tests in the Torque app are showing failures of O2 sensors, but I'm confused as to which ones are causing the failures. The app says "O2 bank 1 sensor 3. Sensor 3?? It says the same for bank 2. Sensor 1 is upstream, sensor 2 is downstream, but WTH is sensor 3??

 

What is the vehicle?

 

Just realize you need to ignore that . I think there is a fail on both sides for three on mine . We just don't have it '

 

2004 F150 SCrew 4x4 XLT, with the 5.4L 3V motor.

 

But the weird thing is that the Torque app is receiving data from an O2 sensor labeled #3, on both banks.


Bank 1

Bank 2

 

No, it's not receiving any data, it's erroneously displaying data for a sensor that is not present. It's a "bug" in the app.

As redfishrd already advised, ignore it.

 

If you follow the you tube guy sma south main auto he will tell you all of the code readers have bugs . He has the real expensive ones but he always gets a reading form two different ones because you can't fully trust them . He really is good at diagnostics . He doesn't like being lead down a rabbit trail and telling a customer the wrong thing . .
I recommend following him as you can learn a lot of tricks .
Wish I had access to all the tools he has, what a nice shop he has .

 

You are correct in that Torque Pro is receiving NO data from O2 Sensor 3 on bank 1 and 2. But it is NOT a "bug" in the app. Torque Pro is correctly displaying data for the sensors that "OBDII specifies are present" according to the PCM.

PID # 13 (hex) [19 dec] specifies the number of O2 sensors present. If you create a custom PID and digital readout gauge in Torque Pro (which 99.9% of code readers will not let you do), you will find the raw response is from PID $13 returns the response of "33" in byte A, indicating there are three O2 sensors present for each bank. (This is confirmed on my 2004 5.4L.)

Depending on how you define a 'BUG', as one with considerable experience programming process control devices, I would say this is NOT a bug, The ONLY thing the program can determine is it gets NO DATA from the querry. Maybe the damn sensor isn't there or is there and isn't generating data. Recognizing that some vehicles can have a third O2 sensor, (but this specific one does not) I'd say it is a data error in the PCM, not a bug in the App.

Though confusing to the user - the last part is correct. As redfishtd says - ignore it.

 

Thanks for the in-depth explanation, I stand enlightened! I haven't previously dug that deep into the OBDII data.

 

The whole thing is enormously fascinating (to me). Having done similar programming in my work career I find myself frequently trying to reverse engineer what they have done. It's actually pretty amazing what all the onboard computer is doing that we never know about - in all kinds of areas.

Another interesting fact on the subject of three O2 sensors --- Each PID for O2 sensors is two bytes long. Byte A is O2 sensor volts, Byte B is fuel trim in %. S_O_M_E_H_O_W , the PCM calculates a THIRD fuel trim %, referred to as "Rear Fuel Trim" - as though their is a third O2 sensor in the 'rear' when there is NOT. They can be read with Torque Pro by adding custom PIDs and gauge (digital/graph/ or pointer) for custom PIDs

22163E - _Fuel Trim Bias Bank1 rear O2
Short name: REARFT1
Min/Max 0-100
Unit %
Equation Signed(A)*256+B

22163F - _Fuel Trim Bias Bank2 rear O2
Short name: REARFT2
Min/Max 0-100
Unit %
Equation Signed(A)*256+B

I'm not (at all) sure how this is used in the PCM's fuel trim stratagem, but it definately fluctuates in some sort of concert with O2 sensor readings and is effected by RPM / Load etc.

 

Most of us can't go that deep ,I am too old for that sadly . Makes sense but why does this pcm not realize it doesn't have 02-3 sensors let alone give false readings . We will never know but kudos to those that try ..I have the feeling that as time goes by things will get more standard. Remember computers at first would not forgive you for syntax errors now they say did you mean xxx. Well we may be all in electric vehicles by then . Look for gov to outlaw fossil fuel vehicles 20-30 years away or a special tax on them .Aren't we jetsons supposed to be flying by now . .

 

Hey 'Jetson'. Some food for thought about doing away with fossil fuels - or taxing them into oblivion.

Electric cars (and airplanes and such) running on batteries _SOUNDS_ like a great 'Green' idea. But think of it. That electricity stored in those batteries comes pretty much exclusively from generating stations powered by one of the fossil fuels that naturally 'contains energy' within it (coal, oil, natural gas, uranium). The conversion efficiency rate is NEVER 100%. So, as you use more electric cars, you have to generate more electricity (at say 60-75% conversion rate) to put into those batteries. SAME is true for Hydrogen cars - also which sound great. But Hydrogen is not a natural occur commodity. Yes it comes from water - but ONLY by injecting electricity into the process, and the output is not 100% efficient. So - OH MY - what is a Jetson to do?

 

I'd be curious to know if a scan tool would also display a third O2 sensor if it is indeed a PCM data error.

 

Hey @alloro I would be willing to bet pretty heavily that it would.

My reasoning is based on some 'subtle' OBDII facts coupled with my curious nature to try to reverse engineer the PCM software.

The OBDII standard PIDs (those few that are standardized) contains a PID assignment location for 'nibble count' for Total Number of O2 sensors on each bank.

O2 sensor PID assignments are specified for eight O2 sensors - (4 per bank). I note that those PIDs assignments for the eight O2 sensors are sequentially numbered, from 14 (hex) to 1B (hex). Each sensor PID is mapped & scaled identically, -- byte "A" stores O2 sensor Volts (A/200), and byte "B" stores fuel trim % (100/128*B-100). See: https://en.m.wikipedia.org/wiki/OBD-II_PIDs

This structure sets up a perfect scenario for a Do While Loop, inside of a Do 2 times Loop, in software. Put the first nibble (number of sensors present bank1) in a counter, set a pointer at PID # 14, and Do While loop counter <> 0 within a small software loop getting and formatting byte A and byte B for each O2 sensor and decrement the loop counter. Get second nibble (number of sensors present Bank2) and run internal loop again.

This schema would accommodate any number of O2 sensors per bank up to 15 on each bank in a minimum amount of software. Based on the ERROR on Sensor 3 that we see on both banks in Torque Pro, I would be willing to bet heavily that if our trucks were actually designed with FOUR O2 sensors per bank, the Torque Pro Mode 06 "Test Results" routine would read and display them all. I can't speak much about other scanners - but it sure follows that Torque Pro would.

Whatcha think?

 

I think we should go back to the simpler times of points, condensers and carburetors.