First, I realise this is a bit out of the scope of DIY PROM. But it's an idea I'd like to air to the few here who are into this stuff..

A thought for hooking up a WB02 to an ECM for datalogging purposes and still retaining normal drivability (as if normal O2 was plugged in):

DIY WB02 -> ADC -> device -> DAC -> ECM

The ADC would simply digitize the WB02 input voltage. 16bit with 0x00=1.5V and 0xFF=2.7V (range of 10.4:1 to ~17.2:1)
The "device" (maybe a PLD, maybe a microcontroller) would do a basic equation on the incoming 16-bit value, and spit out a different 16-bit value
The DAC would take the PLD's digital output and make it analog again, 0x00=0mV and 0xFF = 1000mV
and then the ECM would use it normally.

roughly:
AFR = WB02_V = device input = device output = Vout to ECM
11.0:1 = 1.70V = 0x2A = 0xFF = 1000mV
12.0:1 = 1.96V = 0x61 = 0xE5 = 900mV
13.0:1 = 2.18V = 0x90 = 0xCC = 800mV
14.0:1 = 2.38V = 0xBB = 0xB2 = 700mV
14.4:1 = 2.45V = 0xC9 = 0xA5 = 650mV
14.7:1 = 2.50V = 0xD4 = 0x72 = 450mV
15.0:1 = 2.52V = 0xD8 = 0x3F = 250mV
16.0:1 = 2.61V = 0xEB = 0x26 = 150mV

This would, in my theory, give an O2 reading to the ECM that fluctuates fairly rapidly between 650mV and 250mV (centered about 450mV) for AFR 14.4:1 -> 15.0:1 (centered about 14.7:1). There would be quite a bit of loss of resolution around stoich, but oh well?

The "device" would operate under three rules:

0x00 < input < 0xBB
0xBB < input < 0xD8
0xD8 < input < 0xFF

Each "rule" would have to have some simple math to map the incoming 16-bit value to an output 16-bit value, but i'm too lazy to figure the equations for right now.

Obviously the values and ranges could be tweaked to make the ECM think it has a bonafide switching O2 hooked up to it, yet still give a useful range of data outside of the switching range so that the O2 volts logged at say WOT actually has meaning.

thoughts?

 

Mind you it's almost midnight, but I'm pretty sure that all your hex values are 8-bit. Why use a 16-bit AD/DA converter with 8 bit values?

I haven't researched this, but if our normal O2 sensor goes into a AD circuit built into the ECM, why can't we put a WB02 in the same spot? Is it possible to adjust the code on the PROM to compensate for any value difference between the two?

If I'm totally off, don't mind me, I'm going to bed now.

 

I'd say you might be better served to condition the analog signal from the WBO2 to be in the same range as what the ECM is looking for at whatever input slot you decide to go with. You could do that with a couple op amps & such, and not have to go through the whole A/D D/A sequence. Make sense?

 

Craig-
the main reason I went with an A/D D/A is because I know how that works. I'm not familiar with Op Amps to know how to use them to rescale a voltage in a non linear way. The key thing was to get the rapid swings in V right across 14.7:1 so that the ECM would be fooled into thinking it was a switching O2 and that it was seeing cross counts.

Synapsis-
You are right about the hex values, serves me right for trying to think of this stuff in the middle of teh night. If I recall correctly, the normal O2 does go into an ADC, and then is available for selection to read as a "channel" just like all the other analog voltages (MAP, CTS, etc.) The WB02 could be hooked up in place of the regular O2, but it's output would need to be scaled down to the 0-1V range, and even then the ECM would reject it because there would be no rapid crosscounts around 450mV. THat's the problem I was trying to address.

 

What's the range of a normal O2 sensor? I thought it was 0-1V.

I don't know how a WB02 sensor works. It doesn't sweep back and forth like a regular O2 sensor? If it's just a matter of where in the scale 14.7 AFR is, that shouldn't be more than a 2-4 byte change in the EPROM I would think.

I'm sort of curious about this now. I'll have to look it up once finals are over. (A week. )

 

synapsis-
normal 02 sensor has a 0-1V range, yes, but it's very non-linear. At 14.7:1 they put out 0.450mV, and with slightly decreasing AFR (going slightly rich) the output rapidly climbs, and with slightly increasing AFR (going slightly lean) the output rapidly falls. This oft-posted image characterizes 02 output:



With a regular 02, there is no accurate way to link any output voltage (except ~0.450V) to an AFR. The only problem is that a regular O2 will never really indicate 0.450V because it is constnatly flipping to one side or the other.

a WB02 has a MUCH more linear output (ok, it's not totally linear), but it is WAY more linear than an 02. You can take specific voltage outputs and they correspond accurately to a specific AFR.

 

Here's a quick comparison of a WB02 output to the standard O2 output. NOTE data i charted is based on values published by the DIY WB project group. Also NOTE the data was not charted to exacting accuracy, but it's close enough (anotherwords, this is a 5 minute paint shop pro doctor job). Also NOTE that if you want to reference this image in the future, SAVE A COPY for yourself because it will eventually be removed from the web site it's on, and all permissions are given for anyone to use this in any way, post on any site which they want, yada yada yada.

 

Thanks for the info, it helped a lot.

If the PROM holds two boundaries for O2 cross counts, stock ones being maybe 250mV and 650mV, maybe they can be changed to 225mV and 350mV for use with WBO2. Then you'd still get your O2 cross counts correct.

I assume those voltages on the right of the second graph correspond to the range of a WBO2 sensor. We'd need to make a circuit to scale those down. It doesn't matter if it's linear or not, since we can change the code that uses it.

Quickly glancing through the anht_hac, we'd have to change the following values:

- The Code 13 error values for detecting a bad sensor.
- Error 44 and 45 for too rich/too lean SES.
- AIR divert setpoints
- Some filter coefficients that I don't understand yet.
- The O2 sensor ready/not ready values.
- Closed loop rich/lean threshold value.
- Closed loop rich/lean flag values.
- O2 correction tables.

I'd have to look at the O2 value filter code to understand it a bit more, but I think editing the PROM for WBO2 is entirely possible.

 

I don't think the actual mV values matter if you are going to hack the ECM to set up a new range anyways. The key thing is a rapid crosscounts so that the ECM can maintain a tight control of 14.7:1. But 225mV and 350mV woudln't work with a regular WB02 for two reasons - at around 14.7:1 the WB02 circuit puts out around 2.5V, and 125mV is too great of an AFR range.

If you simply scaled the output of the WB02 by a divisor of 3V, then you'd end up with the following:
14.11:1 = 0.8000V
14.40:1 = 0.8167V
14.70:1 = 0.8333V
15.25:1 = 0.8500V

In order to get good crosscounts, the range would be around ~0.82V - 0.84V. That's a pretty narrow range, especially considering that that the ECM ADC is (i'm almost positive) an 8-bit unit. 0.82V would be 0xD1 (decimal 209) and 0.84V would be 0xD6 (decimal 214). It might work though, but hard to say without actually doing it and testing it. The other challenge is that a WB02 has HIGHER voltage under leaner conditions, whereas a regular O2 has LOWER voltage under leaner conditions - so the ECM code would have to be hacked to take this into account. It might be just as simple as hacking a few opcodes (instead of a 'greater than' test, it turns into a 'less than' test).

The key thing is the need to understand how narrow of a range that a narrowband O2 operates over. That is to say - does it generate crosscounts when flipping between 14.6:1 and 14.8:1? Or are the crosscounts generated at 14.4:1 to 15.0:1?

 

There's a table that contains the crossover voltage at a specific MAP. It's +- 53 mV at "Fast O2" and +- 100 mV when AIR is diverted. So assuming an idle MAP of 30, it'd be 530-590 mV. It goes down as load increases.

The hard part is going to be coding for the opposite direction in voltage.

 

although I haven't looked at the hac recently, i'm somewhat pretty sure that it shoudln't be TOO hard to do the code changes.

basically the code tests the value and makes a decision based on that test. it sounds like you could just change the values in that table you mentioned (didn't know it existed), and then in the code that tests the O2 value, "flip" the type of test it does. Any test that tests if the 02V is below X, change the opcode so that it tests if the O2V is above X, and vice versa.

Ok, I just looked at the hAC. It looks like the conditions which set an O2 error would have to be disabled or modified, and who knows what else (maybe the filters?). But to expand on the above comments (about flipping the opcodes), BHI statements would become BLO and vice versa, BHS become BLS and vice versa, and maybe others as well.