ttypecamaro

iTrader: (2)

I had the tune down where everything below 3600 rpm had average BLMs of 128 +/- 3. All of the sudden, the BLMs at any current load/rpm climbed instantly to the max (160), the O2 sensor reads a consistant 90XmV, and the O2 rich (code 45) is thrown.

Shouldn't the BLMs dive if the O2 is reading 900mV?
Shouldn't the O2 lean (code 44) get thrown if the BLMs max out?

I have reason to belive this 3-wire sensor could have been injured in a lean(ish) wide open throttle condition. the sensor is right after the turbo on a 3.1 motor.

junkcltr

iTrader: (1)

Unplug the O2 sensor and see what the ALDL reads for the O2 mV value.

How close is the heated O2 to the turbine outlet? Maybe too close and over-heating it?

ttypecamaro

iTrader: (2)

the sensor is maybe 5-6 inches from the outlet right on the outside radius of a 90 bend.

should I ground the O2 input after I unplug it, because couldn't some residual charge on the wire cause different voltage readings?

ttypecamaro

iTrader: (2)

I unplugged the (3-wire) O2 and the datalogger read a constant .451mV. It normally idles with 1.3-1.4ms pw but it was "trying" to idle at 2.2ms pw with the O2 unplugged and blm/int at 128. When I plugged the O2 back in it seemed to work fine for about a minute, cross-counting like it should. Then the O2 was sitting in the 800mV range untill code 45 came back.

I have a spare ecm that I could modify for the flash chips, but it would be much easier (but more expensive) to replace the O2 sensor.

junkcltr

iTrader: (1)

The datalog should show 450mv +/- a little bit with the O2 sensor unplugged. So the ECM seems fine. Start and run it with the O2 plugged in and and wait for it to throw the code, then unplug the O2 sensor and see if the ECM is reading 450mV. This will tell you if something is going wrong with the ECM after a little run time.

My first guess is the O2 sensor is bad. The above test will show if it is. If you have a single wire O2 around you could try that. I run my single wire O2 sensor close to the turbine outlet. The Nissan turbine outlet flanges I used had the O2 bung right in them with a 3-wire O2 screwed in. It was about 6 inches after the turbine wheel. I am not sure how much heat a 3-wire can take, but Nissan didn't seem to worry about over-heating the 3-wire O2 sensor. Or maybe factory it took a single wire and someone put a 3-wire in it.

ttypecamaro

iTrader: (2)

I unplugged the O2 when the SES light came on and the aldl read .451mV... so The ecu was not bad.

I replaced the O2.. problem persisted... then I remembered changing a value in the chip:

the problem stopped, and the new O2 sensor is WAY better than the old abused one. The old one seemed intermittent after 3600rpm for some reason. This one reads seemingly accurate and counts faster.

I modified the stock table "Injector Pulse Width(usec) vs Load value" in the bin and the definition file. I multiplies the calibration by .77 to account for the LT1 injectors on the 2.8/3.1. I changed the XDF to read in msec because it is more familiar to me.

My next problem is trying to log LV8 from the 1227302. WinALDL doesn;t and tunnerproRT is supposed to do it, but I can't get my 2-transistor cable to work with tunerproRT. I have a 232 cable for the OBDI '95 LT1 but it has an OBDII connector (works with tunerproRT on the LT1). I wonder If I can make an adapter?

junkcltr

iTrader: (1)

Yup, you croaked the first O2 sensor. At least now you know how to test if they are bad. ECMs are pretty tough in general.

Not sure about that 302 ECM. I have one in a box somewhere that I never used for anything. I wouldn't be messing with the definition file. Injector time in millisec is millisec no matter what engine. You need to change the BIN like you did.

I use my homemade ALDL Maxim_IC to RS-232 converter with 160 baud ECMs (302, 870, etc), 8192 baud ECMs (730, 165, 94-95 LT1 PCM). It works fine with all of them. I used WinALDL on a 1986 V6 2.8 Camaro with it and it worked fine. That ECM is very similiar to your 302 ECM.

Your OBD1 cable should work fine. All you need is the ALDL serial data wire and the GND (ground) wire, and possibly power depending on the cable design. Two or three pieces of wire between the car ALDL connector and the OBDII connector and you are there. BTW, I couldn't get TunerPro to connect to the 1986 2.8 V6 Camaro ECM but WinALDL connected fine.

ttypecamaro

iTrader: (2)

thanks for the help, all around.

I'm using the WinALDL 1986 2.8 v6 configuration to log this 1988 2.8 bird (now 3.1). The only problem is that the battery voltage reads half of what it should. ("BAT" usually sits around 6.8V*2=13.6V). I wish I knew how to edit the WinALDL program. I've done intro-JAVA and intro-C++, but I wouldn't know where to start.

I'm unclear what you're talking about here.

I changed the XDF from microsec to millisec (divide by 1000). Both tables exist in my XDF and editing one changes both.

If I raise the 240 and 256 LV8 vs PW values the problem returns. Must be a bug in the code like 256==0 messing it all up. GM must have calibrated the stock chip like that for some reason, even if it was to work around a bug. Maybe I can raise the 240 value, but leave the 256 alone.

junkcltr

iTrader: (1)

I didn't notice the BAT error. I just used the MAF, TPS, RPM values to diagnose a MAF problem.

I was confused too. I thought you were talking about the ALDL definition being modified. You were talking about the XDF. What you did is fine.

I would think that the 256 is fine, but you are exceeding the allowed limit for the value itself. You entered a value of 16.xx. Maybe the range is only allowed to be 16. Try 15.8 and see if that works. I never played with the 302 ECM code, but I bet it is a value limit and not a bug in the code.

EDIT: Use the show items summary view in TP when you modify that table so that you can see the hex value that will be used/programmed into the bin. I bet a value larger than 16 goes bad and becomes "value - 16" that will be programmed. In other words, the 16 becomes a 0.

Looking at the resolution of the table you posted makes me believe the max. value you can have for that table is 16. Anything bigger becomes "value - 16". Basically, it wraps around and starts at zero again. That thing must have run WAY LEAN under boost with the injector PW cut down to about zero.

Here is the equation: NUM * (16/256) = TABLE_VALUE
NUM can be any integer between 0 and 255.....8 bit number

ttypecamaro

iTrader: (2)

I never knew about the "item summary" in TP! I can see how that will be useful in the future. you were right, the max is 16. The location of the table is $4DB-->$4EB = 16

I noticed the pulse width decreased from 8.7X to 7.7X, (which is like -12%) so maybe the LV8 never made it too far past 240.

I was worried that the max PW was going to be only ~14ms because it wouldn't even go static untill 4300rpm which is after the peak torque, but a 16ms PW goes static at 3750rpm, which isn't that bad. And these LT1 injectors should be good to 240 flywheel hp as long as high duty cycle isn't a concern with the AMBD (302ecm) like it is with the stock AUJP.

ttypecamaro

iTrader: (2)

I could have been wrong about the max being 16ms though I think the max is 19.4549445ms. the conversion is .0762939*X


stock table (2.8L)

junkcltr

iTrader: (1)

If it uses two bytes like you posted then it could be 19.xx ms as the max. along with a clamp in the code. I will run the numbers tomorrow and see if the stock table matches up with that. Overall, it is usually more difficult to do without source code, but running the numbers will show if it exactly matches the stock table.

ttypecamaro

iTrader: (2)

I figured out the problem with the battery voltage. In WinALDL they log bit 18 as the battery voltage, but for the $3A code ('88 bird) bit 18 is the load bit. Im guessing that the raw value of this bit could be a useful tuning tool without having to manually calculate load.

I wish I could make that "simple" change to the WinALDL program.