For example, on a cold start Bank1, watching sensor voltage with INPA, it starts out at ~0.44V. Within a few seconds, it starts switching between ~0.1V and ~0.85V. Looks good to me. After a minute, Bank2 is still stuck very close to 0.45V. I then open TestO, and look at the Bank2 waveform, and it IS switching, albeit over a more limited range - ~0.3V to ~0.8V. But is IS switching, and roughly the same rate as Bank1. That suggests to me the Bank1 sensor is "lazy".

You meant B2 lazy?

As about O2 waveform shown on different tools, I think TestO applied less Low Pass filter on the raw signal and it shows more real action with higher frequency "noise" between DME sampling/controlled cycles. We expect to see the O2 signal as something like a square wave swinging from 0.9v to 0.1v, cycle to cycle as the DME read the O2 and did the correction output, but I think the raw O2 signal voltage has more variation in the signal than just the filtered square wave. The Inpa and other tools might have more filter to show the user the primary action instead of including all smaller swings.

In your case, I think it's worth to try out another DME hardware.

 

Yes, it appears the Bank2 sensor1 appears to have been "lazy". I swapped in another sensor, and I now see much wider excursions - 0.1V-0.95V. And, it starts switching much sooner now, much closer to what the bank1 sensor is doing.

Is there a way to increase the update rate on the OBDFusion "dashboard" display? It seems to only update 1-2 seconds, where TestO can sample at something like 100X/second, giving a very nice waveform display. Since the sensors switch at 1-3 cycles/second, it would be nice if the OBDFusion display would update a something closer to 10X/seconds, rather than the current MUCH slower rate.

Do you know if the post-cat sensors have ANY effect on mixture control? I'm seeing both post-cat sensors switching, which, according to what I read, should not be happening, unless the cats are no longer functional. They may well be toast, as they have >240K miles on them, but it has always easily passed emissions, and it seems unlikely the cats JUST died since the last test a couple of years ago.

 

Do you know if the post-cat sensors have ANY effect on mixture control?

As I remember reading some documents that the post sensors are for monitoring the condition of the air pump and the CATs, and have no effect on the fuel mixture.

 

I am about to go get a couple of sticks of dynamite for this car. I watched the O2 sensors for quite a while, and all looked fine. Both pre-cat sensors were toggling over their full range, and the car ran well. My wife drove into town and on the way back, it decided BOTH pre-cat sensors were no longer showing any activity, so it threw P1345 & P1347, plus a flurry of cylinder miss codes on both banks and lean codes on both banks, and started running like a bag of s**t. No surprise, at this point it was running open-loop, with fuel trims pegged at 27.5%. OBDFusion shows all four O2 sensors at 0.00V! No doubt the lousy running is due to being WAY too rich.

WHY is it deciding there is no activity on the sensors, when they both appear to me to be working properly??

Just for grins, and for lack of anything more constructive to do, I've simply un-plugged both pre-cat sensors. Of course, that immediately throws both O2 heater codes, and will, in due time, throw both "no activity" codes. But at least so far, it's running with the trims at 0.0%, instead of 27.5%, so it at least runs ok.

 

Due to the rat incident, there is a chance the exposed wires might short the heater 12v to the sensitive O2 signal wire caused damages to the DME analog circuit front end. I think you might want to swap out with a used good DME from ebay and so if better luck this way.

 

O2 Sensor Update/Refesh Rates
Don't know if TestO, INPA and OBD Fusion are applying any filtering at all purposely. I'm not an electronics engineer but these are my observations.

The DME has a very fast update/cycle time. The data reporting through the diagnostic port is slower. It is constrained by the type/design of communication protocol used. For the typical K-DCan lead we use, there are settings to optimise the speed of communication. See section E, 2 in the first post. The Z3 Diagnostics Thread: Instructions, Experiences, Discussions, Experimentation

The amount of information that you are subscribing/reading though the diagnostic port slows down the total/combined speed of the reporting cycle.
When looking at two O2 sensors with TestO, at the bottom of the graph box it tells you the update/refresh rate. Both in ms and in how may times a second. My observations it that it's around 3 times a second. When I log these values, I get 320 ms data. That is, data is logged at about 1 ms. I get 3 lines of the same data before it changes, meaning the update/refresh cycle is taking 320 ms (one time stamp minus the other time stamp). If I have more data points open, they all give sensible update/refresh rates per second in the bottom of the boxes, yet when I log the data, the update/refresh time slows down. More data being subscribed slows down the overall update/refresh time.

INPA shows you multiple data points per page. There is a definite update/refresh rate on the page. I have not done any testing to see if this rate changes between pages with more or less data points. I suspect that the update/refresh rate is dependent on the number of data points being displayed.

OBD Fusion when using a EML327 dongle appears to have an update/refresh rate of between 3 to 7 seconds. This looks to be dependent on the device (iPad etc) and the Dongle (Bluetooth or WIFI). I get 7 second data on my iPad2 with WIFI dongle and 1 second data logging (7 lines of the same data before it changes). So, set OBD Fusion to 5 second data logging. Again, it's all to do with the communications path and how long it takes the data request to get to the DME and for the answer to get back to the software.

So what does this all mean to testing O2 sensor?
O2 sensors switch several times a second. To really see what they are doing requires an oscilloscope working at 1k Hertz or higher, that's 1 sample every 1ms or quicker.
TestO gives a nice curved graph of the O2 sensor voltage, but there are flat spots and missed peaks. This tells me that it is not fast enough to really show what is happening. It is showing the value that was registered in the DME when the request came through. TestO puts a nice line between the dots and shows us a graph. The 320 ms data is the best we can get, yet it is too slow and missing all full cycles of the O2 sensor. In simple, we are being fooled by technology into thinking the graph is true and complete (pretty moving picture) when that technology can not provide the data stream fast enough to represent the reality of the O2 signal.

INPA gives us a slower update/refresh rate. OBD Fusion is even slower, yet we chart the pre-cat O2 data logs and try to make meaningful diagnostics from an incomplete dataset.

Capturing O2 Data is like shooting a shotgun at a flock of ducks. You'll hit one every shot, but many more have flown past by the time you have reloaded, taken aim and pulled the trigger. You are counting the size of the flock, by the number of ducks in your bag.

Ray's O2 Problem
After reading your posts over the last few days, I came to the conclusion that your O2 are telling the truth. Its just that we don't understand what they are telling us. You then found the loose pre-cat O2 sensor and the reading made sense.

Post-cat O2 on E46's do not have any fuel trim control.

If the post-cat O2 is switching, It typically mimics the pre-cat sensor on that bank and is a sign of a blocked cat. Other blocked cat indicators are a Lower than expect MAF value at idle. The bank with the block cat will likely be lean at idle and go double digit rich at higher rev's.

There are several Fuel System Status values

• 1 - Open loop due to insufficient engine temperature, We know that fuel trims do not operate in this status
• 2 - Closed loop, using oxygen sensor feedback to determine fuel mix, We do know that fuel trims operate in this status
• 4 - Open loop due to engine load OR fuel cut due to deceleration, My observations it that STFT's go to Zero and LTFT stay the same, Indicating that fuel trims do not operate in this status
• 8 - Open loop due to system failure, no observations, but suspect that fuel trims do not operate in this status
• 16 - Closed loop, using at least one oxygen sensor but there is a fault in the feedback system, no observations

With the MAF disconnected and running on Alpha-N tables, the Long Term fuel trims are Zero and the DME runs in Fuel Status 2 (closed Loop) with just the Short term fuel trims operating.

Which fuel system status are you observing the DME is in when the O2's go to zero Volts?
You say that the car was in open loop with fuel trims pegged at 27.5%. Which fuel trims, short or long? Why would the fuel trims still be functional in open loop?

0.0V on the O2's is extremely lean. If we believe that the O2's are telling the truth, what is common to both banks that could tell/fool the DME into believing that the mixture is so lean?

• The DME itself is faulty
• The MAF is faulty. Does running with the MAF disconnected on Alpha-N Tables make a difference? The assumption with this test is that you do not have any vacuum leaks, otherwise you'll get false results.
• The MAF signal to the DME is somehow compromised. There are few MAF codes. An under reporting MAF caused lean conditions. The MAF signal is 0-5V, so any high resistance joint will cause the MAF to under report. Check all connections and the DME connectors for coolant/oil contamination.

 

NZ00Z3,

All different kinds of good information there, some of which I've learned in the last few hours. Found two documents that give some insight into how the DME works:

https://www..bimmerfest.com/attachm...ens_ms42_ms43_m52tu_m54_ecm_engine_control_module_management_systems-pdf.441295

BMW N43 N52 N53 N54 diagnostics Lambda probes INPA

The oxygen sensors (Lambda probes) perform the control of exhaust gases and are one of the most important parts of petrol engine. The modern BMW engines use 2, 3 or 4 oxygen sensors. 4 cylinder engines: wide-band oxygen sensor for each bank (for example, N43 for 5 series) or one […]

bimmerprofs.com

I have been unable to get a scope probe into the O2 sensor connectors. I'm about ready to bite the bullet and sacrifice a couple of sensors to make a break-out cable I can plug in between the car harness and the sensor to enable me to do so.

Even if TestO is missing cycles, it still shows essentially near-constant switching on both sensors, at a rate of ~1-3 Hz, outside of the first minute after a cold start. So, I think it is showing useful representative, if not 100% cycle-accurate, data.

I have not looked at the system status values, because OBDFusion does not give me enough "dashboard" displays to see everything I Want, and the O2 readings were more important. But, when it has gone full rich, but in every case, the O2s read a constant 0.44V, which is what happens when it goes open loop. Next time it happens I will look at the state. Interestingly, with the pre-cat O2s unplugged, it is sitting with the short-term trims at a constant 0.0, and the post-cat O2s are still switching full-range. It's hard to be certain, but it seems to me to run a bit better with the post-car sensors unplugged as well. Is it possible the DME tries to use the post-cat sensors when it detects failures in the pre-cat sensors?

I haven't had the long-term trims displayed, because I'm mostly driving at low speed, where they are, in theory, not being used. SO, every time I looked, they were 0.0.

What seems really odd to me is, while driving, the short-term trims are almost always low, under 10% and mostly under 5%. Then, all of a sudden, the DME decides something, it's massively lean, is wrong, and the trims go way up. Sometimes only one bank, sometimes both. And, today, when it did this, the pre-cat O2 readings went to 0.0! How does THAT happen?? Clear the faults, and all is good. And, the funny thing is, when the DME is not throwing faults, the car runs GREAT! Idle is smooth, it revs smoothly, and has lots of power. So much so, even my wife commented on how much better it's been running!

The really infuriating thing is I feel like I'm chasing ghosts. I see one behavior, and just when I think I'm making progress figuring out what is happening, the behavior changes. I get very consistent errors on one bank, start debugging, and after a hour or two of digging around, I suddenly start getting a different error on the other bank! I fell like I've been going in circles for weeks!

The MAF appears to me to be working fine. I get ~3.8gm/sec at 650RPM idle, and it increases in a reasonable manner above idle. It was running for a while without the MAF, again because a rat chewed through the MAF harness. The little bastard did it again a few days after I repaired it the first time! But for now, it is fine, and I've seen no MAF codes when the wires were intact. Two different MAFs, one old, one new, give the same results.

I'm wondering if I should pull the entire harness containing the O2 sensors, peel off the jacket, and look for shorts to other wires. Any idea how hard it is to remove that whole harness?

Any idea how to run the INPA sensor tests?

 

I have been unable to get a scope probe into the O2 sensor connectors. I'm about ready to bite the bullet and sacrifice a couple of sensors to make a break-out cable I can plug in between the car harness and the sensor to enable me to do so.

Why not probe the same signal at the DME connector pins?

 

Found this page, which explains what the INPA sensor data SHOULD look like:

Diagnostics of MS43 | Bimmerprofs.com | *** emulator NOXEM 129 | 130 | 402 developed for BMW N43 & N53 series engines

One key sentence, that explains the 0.0 sensor readings I see when the DME has thrown up its hands:

Important: if for the warmed up engine, any of the menu data groups is 0, it means: MS43 work in EMERGENCY mode and does not perform normal fuel correction!

 

This smells like a DME circuit or connection issue, which I think Sapote suggested earlier.

 

May well be, but before I spend $$$ for another DME, with re-flashing and re-coding, I want to be absolutely certain that is the problem.

 

A bit more information. Did a cold start, watching O2 sensors, lambda and fuel trims using INPA. BOTH pre-cat sensors come up in a very similar manner - they start toggling at almost exactly the same time, starting perhaps 20-30 seconds after a cold start) over almost exactly the same range. All looks good during warm-up. This seems to confirm O2 sensors are ok, and heaters are working properly. After idling for a minute or two, I started driving to get engine warmed up faster. All continued to look fine.

Once engine gets up to temp, both banks go closed loop, and STFTs are generally low. But, after a few minutes, Bank2 STFTs shoot up, and shortly after that bank2 goes open loop, in "Emergency" mode. This all happens over a period of just a few minutes.

I'm going to see if I can get a log with OBDFusion, with all O2 values, trims, fuel states, speed, pedal position, rpm, etc. to see if I can catch a clue WHY this is happening.

I'm going to beat this thing into submission if it kills me...

 

Question: If the cats are not working, wouldn't I be getting codes related to low cat efficiency? I have NEVER gotten those.

 

Here is another interesting link from your website. BMW M54 N43 N46 N52 N53 N54 diagnostics INPA

 

Here is another interesting link from your website. BMW M54 N43 N46 N52 N53 N54 diagnostics INPA

Yes, I saw that one. There are links to quite a few interesting pages there.

 

OK, I've captured some data that I find strange This is a trace starting from a cold engine, al faults cleared, then running until the DME threw up it's hands and went open loop. What seems odd to me is the warm-up looks fine. But once warm, the O2 sensors both say its running rich, and the ECU forces the short-term trims even richer, eventually pegging both trims to +27.5%. Not surprisingly, it runs like crap at that point. Interestingly, after it threw the faults, I disconnected both pre-cat O2 sensors, and it runs just great like that.

So, it looks to me like the DME is CAUSING the problem. How can that be? It appears Bank2 always faults first, followed shortly by Bank1. I'm going to repeat the test a few times later today, on a warm engine, so ensure it is consistent.

 

Hi Ray

Could you please post the log in CSV or something spread sheetable. I'm running up and down the page using my mouse as a curser and it's hard to see the whole picture at once.

Initial views:
Short Term Fuel Trims are reacting correctly to the pre-cat O2 signals.

• The pre-cat O2 data is really crap until you rev the engine to around 2,000 rpm.
• The O2's heat up as expected and are sitting above 0.8V ready to go into closed loop control. This is good. Once closed loop control occurs, they are not switching full range. Both are missing the bottom part of the switch signal. Bank 2 has a block of no switching at all and sits at 0.35V. Both are not getting to 0.8V. This is not normal. The STFT are trending lean because of the missing O2 data.
• Once you rev the engine to around 2,000 rpm, the pre-cat O2's start switching full range, although a bit hap-hazard. The STFT drop to rich due to the O2's going to 0.8V but missing the lower voltage data.
• There is a period of things going right, just before 34200, where the pre-cat O2 signals are very red/close full range switching. Bank 1 STFT on 0 and Bank 2 STFT on 10 (lean).
• After that, it the all goes to crap with gaps in the pre-cat O2 data and not switching full range. The STFT react accordingly.
• On the first 27% STFT spike, you can see the impact of a very rich mixture in the post-cat O2's. They jump from topping out at 0.8V to 0.9V or higher. Similarly with the second two 27% STFT spikes, the post-Cat O2 see the rich condition. The rich condition is real. The STFT's are doing their job correctly.
• The pre-Cat O2's are not showing the rich conditions during the first 27% STFT spike and are turned off by the time the second and third 27% STFT spike comes through. Missing the first one may just be the reality/difficulties of data logging O2 signals. The O2's are showing 0.45V at the time. Almost as if they had been switched off.
• The post-cat O2's are switching. This is normally as sign of partially blocked cats, but your fuel trims are not showing the associated rich (double digit negative fuel trim) conditions. It's likely that they are just not fully up to temperature.

What turns off a pre-cat O2 sensor?

• The DME turns them off under some predefined conditions.
• They get cold and fall outside of the linear operating range. We know that when they are cold they sit at 0.45V. But we see the heating cycle at the front of the cold start log and know the time it takes to heat them. The heating cycle is far longer than the short periods of 0.45V, so they are not likely cold.

How does the STFT's keep operating with the pre-cat O2's turned off?

• It almost looks like the DME uses the post-cat O2's as a rough feedback signal
• Maybe the signal is still there, but the DME is not reporting it?

Been thinking about what drives the pre-cat O2 switching. It's the DME. The DME quickly injects a little more or less fuel to try and maintain the 14.7:1 air fuel ratio. The pre-cat O2's react to these changes and switch, thus giving feedback that drives the STFT's and LTFT's.

• If the DME is not giving the full range of this quick little bit more fuel injection, then the O2's will not fully switch. The bad switching after closed loop is common to both banks, so is not an individual injector problem.
• Yet there is that 0.35V flat line section in bank 2. If it was a fuel injection problem, then that flat line section should be common to both banks.

Either way, if the DME pre-cat O2 monitoring is faulty, or its the DME fuel injection that is faulty, the result is the same. Change the DME.

 

A csv file is attached (extension changed to .txt). The part you care about starts in row 11.

What I'm seeing now is at least consistent, and Car Scanner Pro is behaving so nicely, it gives me some confidence the data is correct. Bank2 appears to always fail first, with bank1 usually, but not always, following within a few minutes. I was quite surprised today when I managed to drive for about 15 minutes before bank2 shut down.

I do believe there is something funny going on with the heaters, and in the next few days I'm going to try a test - two constant speed runs, starting each with codes cleared, on a warm engine, one at low speed, and one at high speed. I suspect the low-speed run will fail, and the high-speed run will not. My understanding is the heaters are NEEDED when the engine is cold, and when RPM/speed/load are low, but not needed when RPM/speed/load are high.

In the above graphs, the car was sitting until ~34200, then I started driving, mostly at 40-50MPH, and that is where the signal swings seem to increase. I believe ~34200 is also about where the engine reached full operating temperature, so I believe it was running on a rich map up to that point.

I'm also going to rig up a way to directly monitor the heater signals, to see for sure when/if they are being powered. The heaters themselves are fine, measuring ~5 ohms.

NO indications of injection problems. In fact, before bank2 shuts down, or if I disconnect the pre-cat O2 sensors, the engine runs incredibly well considering its 240+K miles!

The STFT drop to rich due to the O2's going to 0.8V but missing the lower voltage data.

Not sure I understand that. With no low peaks (constant rich indicated), I would expect the DME to try to FORCE the sensors to go low(lean), by leaning mixture, with negative trims. The trims should generally move opposite the sensors, and vice-versa, with some small time-lag. This is WHY the O3 signals constantly toggle, even under steady-state driving, so the average mixture hovers around the ideal point.

 

Here is my solution to making the DME connections probe-able. Turns out the connectors use 0.025" pins with 0.1" spacing - i.e. - standard header pins and sockets. I've got buttloads of that stuff. So I made up a breakout board that has pigtails with sockets that plug into the DME, and pigtails with pins that plug into the harness. Now I have complete access to all the connections on the X6002 connector, where all the O2 sensor I/Os are located. So, I can easily confirm if/when the heaters are turning on, and also easily put a scope on the O2 sensor signals.

Also seems clear the DME probably senses whether the heaters are connected by checking the voltage on the heater ground pins. When the heaters are off, these pins should all be +12V, and to turn the heaters on, the DME pulls these pins to ground. Similar logic is used on the sensor connector, by sensing current in the O2 sensor ground wires. No O2 sensor, no current, which reads no voltage. Simple.

 

There does not seem to be any problem with the heater wiring, or the heater drivers. And the heaters are getting power. So, that is off my list of possible problems. About all I can come up with at this point is something about the current O2 sensors the DME simply does not like, or the DME itself has some bizarre fault. I think my next step is to replace both sensors with brand-new OE sensors. If that does not work, then replace the DME. I just don't see anything else to do.

 

I haven't followed this thread religiously, however if there's still an issue with heating the new sensors I would have a very close look at all the fuses and wiring.

Heating an element is more amperage than voltage. This is handled by drivers inside the DME.

 

I think there is a light at the end of the tunnel. I WAS getting consistent first-faillure on the Bank1 pre-cat sensor, with both a heater fault, and a "no activity" fault. Just now I swapped the two pre-cat sensors, and, sure enough, the first fault now occurs on Bank1. Oddly, bank 2 never actually went closed loop (trims all stayed at 0), though also never threw a fault. But, Bank1 consistently throws a "no activity" fault after a few minutes of close-loop operation. My conclusion is the DME is simply unhappy with what it's seeing from the pre-cat sensors. So, I will get a pair of new Bosch sensors, and hope that solves the problem. Perhaps the ones in there now got fouled somehow.