Ozzstar

Finally proof of truth. I laugh at holding the brake pedal down everytime I read it

Cliff Harris

I've seen "turn on the headlights" several times. I think honking the horn would be more effective. At least you could hear that nothing is happening.

tequilaboy

To get an idea of what the ecm is seeing while you datalog, check the unlimited airflow value (often labeled as MAF raw input in the *.adx if using TunerPro) during the burnoff cycle.

LC7AB FDB $00B6 ; 38 UNLIMITED AIRFLOW USED IN ERR 34A & 34B

You can check this in your existing data if you have it and correlate the value against the voltage in the MAF tables for a sanity check.

You can also raise the max maf vs rpm table to 255 at zero rpm in the bin, to see the effect on the normal gram/sec display value while logging.

Alternatively, you can add the MAF voltage directly into the datastream, but this is a little more work.

I have to suspect a sticking burn-off relay that stays active longer than the actual burn-off signal.

puzzigully

Thanks for the suggestions.

i have replace/swapped relays, so pretty sure it cant be "sticking"

My problem is the ALDL socket doesnt seem to stay "live" to report what the ECM is seeing.
See my datalog results.

tequilaboy

The 23 gm/sec that you see in your log data is the result of the MAF (display value) being limited by the max maf vs rpm table.

Based on this we know the MAF voltage during burnoff is at least greater than 1.46 volts based on the standard MAF transfer. Since it keeps failing, we can also assume its greater than the ~1.9 volt (95 A/D) failure threshold.

Since the (8 bit) unlimited airflow value is not limited by the max maf vs rpm table, it is a better indicator of the actual maf voltage under these conditions, despite the lower signal resolution.

puzzigully

I thin I'm understanding what you're saying...can you elaborate a bit more for the uneducated

tequilaboy

There are 2 MAF signals present in the 8192 baud datastream. The first is the 16 bit display value which is used for fueling and is subject to the max maf vs rpm table limitation. This is the value that appears in your log samples.

The second or unlimited airflow signal is an 8 bit value not subject to the max maf vs rpm table limitation. This value is intended for use in the code 33 and code 34 diagnostic routines and it roughly reflects the sensor's output but with 1 gm/sec resolution.

It is the next byte in the datastream after the 16 bit display value.

puzzigully

Can you elaborate on this logic please?

Cliff Harris

The MAF output signal varies between zero and 5 volts. The 5 volts is a reference signal that comes from the ECM. The ECM has an ADC (Analog to Digital Converter) that compares the voltage output of the MAF to the reference voltage. The ADC converts the voltage to a digital number from 0 to 255. That means that each digit is 5.00/255 or 0.0196 volts, which is the resolution of the ADC. The ECM converts that digital number into an air flow rate in grams/second. The conversion process is complex and weird so I won't go into that...

The 16 bit MAF output value is misleading because you would think you would get better resolution with more digits. It turns out that the upper 8 bits are the value that is used and the lower 8 bits are the fractional part of a division and they are ignored by the ECM internally.

puzzigully

Guys....an update on my particular situation..

Took it to a local EFI expert and he used an externally powered scan tool plugged into the ALDL and he saw the ECM turning off WHILST the burn off was taking place.

He shipped it to one of the well know diagnostic places here in Australia and as the ECM is similar to the local Holden products they could simulate the Burn off sequence in a test rig.

They have confirmed that the ECM is "turning off" before is sees the completion of the burn off cycle.

They claim to have repaired it and we will test in the car next week.

My guy didn't get to talk the technician responsible, but comments such as "the MAF degrading can cause this fault in the ECM".
No clue how valid this is. To be honest sounds like BS.

But have new MAF to install along with repaired ECM.

Will keep you updated.

puzzigully

Latest Update:

finally convinced my "technician" to attach a 'scope to the MAF output.

He has a crazy-*** scanner, that puts an output to a laptop screen.
He is a bit "old school", so he can't (at the moment) save the data, but can capture on a screen.

What we are seeing happen:
The burn off relay activates (nice sharp waveform from off to on)
We see the MAF output go from approx 2.5V to almost zero for only approx 5-7 msecs (again, nice sharp waveform).
BUT
Then its as if the ECM cannot "keep it there" and there is a curve upwards back to (cant remember exactly) - almost like a battery going flat or capacitor discharge..
If you know what I mean.

So, as we know that at 0.3 secs after the burn off relay is activated, the ECM takes 6 readings and all need to be between 400msec and 1.9V, looking at the waveform, there's not much chance it passes the test.

Anyone know how long the 6 "tests" or "samples" take and/or how long between each one?

Any speculation as to why the MAF output doesn't stay at a constant reading for the entire Burn-off?
The burn-off relay stays at 12V for the one second burn off time.

We have two MAFS (one new and one old, both show the same waveform) so unlikely to be the MAF?

I'm thinking that when the "load" (burn off) is applied, it cannot be maintained due to a poor earth?
If so, what earth?
The MAF has two earths. An "Analog Ground" and a "System Ground" - any idea how the "Analog Ground" is supposed to work?

Thanks

Cliff Harris

The readings are taken every 1/10 of a second.

That is mysterious. Do you have another ECM to try?

The System Ground is used for the 12V burnoff voltage. The Analog Ground is the reference ground that the ECM uses (it comes from inside the ECM).

An interesting experiment to try would be to ground the scope to the engine and then probe the grounds at the MAF connector to see if they are bouncing around during burnoff. If a ground is moving then the connection is bad somewhere.

puzzigully

Thanks


Unfortunately, I do not.....I know I'll need to change the EPROM over if I do get one though.


Will do, we are checking grounds now, will put this on the list also

puzzigully

I'm thinking that whilst the Burn-off relay shows 12V for the entire 1 second and the wire itself has been observed for being "glowing" for at least the entire second.
So the wire in the MAF is getting the full 12V for the full second.

It has to be the signal from the MAF that is getting "distorted" somehow - as it only goes to the value it needs to be at for, at most, 6 milli secs.
after the 6 milli secs, it starts to trend upwards, away from the "burn off value".

puzzigully

Guys,

latest update.

Car has been with a shop for 4 months!!!

On/Off efforts at finding the issue.

The ECM was sent down to "experts" twice!!

Their conclusion:
They can see the ECM functioning, but think the ECM doesn't "see" the end of the burn-off in the allotted time.

They can see the ECM start the burn off, take measurements, but the ECM apparently doesn't "see" the end of the burn off.
That's is why (they say) its throwing a code - not because the measurements are out of range, but because the ECM doesn't think the burn off finishes....

They have no idea why this is.

This may account for some of the other failure modes for code 36 that is not MAF or relay related, that others have experienced.

what to do next?

Any suggestions??

I will try a replacement ECM next as it appears it is the ECM that is the problem.

Be nice to know why though.....

tequilaboy

Here is a log of a burnoff event captured with TunerPro. Interesting parameters are also highlighted in the tables.

The bottom monitor panel shows the IAC position in blue and the 8 bit unlimited airflow in grey. You can see that the data stops and the ecm shuts down about 11.5 seconds after ign off. Note: The IAC step/ramp/reset occurs just after the IGN is switched off and serves as a handy reference signal.

The unlimited airflow signal is 57 gm/sec before and after the burnoff cycle which is approx. 2.5 volts. During the burnoff, the signal spikes then settles at 30 gm/sec or about 1.7 volts in this log.

The top panel shows the 16 bit MAF signal which is being limited to 23 gm/sec at 0 rpm.

A log like this will tell you exactly what is going on. You can see the delay and burn off duration clearly in the data.



It's always possible to reduce the delay, if the keep alive is being cut short for some reason.
LC6A1: FCB 10 ; 1 Sec MAF Burn off time.
LC6A2: FCB 50 ; 5 sec MAF burnoff delay time fm ign off
;--------------------------------------------------------

puzzigully

Awesome info!!

Will need some time to figure out exactly what you're saying

If the ECM really "stops looking" at the burn off and doesn't "see it" finish, then I'll have to modify the code to tell the ECM to keep looking for longer.

As I understand it:
5 secs from ign off, burn off starts
0.3 secs later the ECM takes 6 readings 0.1 secs apart
So not a lot of room for error as 0.3+0.6=0.9 secs

I'm not aware the ECM needs confirmation that burn off actually finishes, so I'm speculating that's the problem.

Does anyone know if that's in the code?

If the burn off time isn't long enough, the ECM can't get the six readings in time, so increasing the burn off time, should be straight forward.
A simple check would be to increase it to 1.5 secs, then see if the code still gets set.

Does anyone know how the ECM knows when to start taking the readings?
And if it knows when to stop?

Cliff Harris

There is no confirmation that burnoff finished.

The ECM takes MAF readings every 1/10th of a second as long as it has power and during the MAF burnoff test time (until 11.3 seconds after the ignition is turned off).

I don't think it actually stops. It just goes back to reading the MAF in the usual way after the test finishes (after it has done 6 readings). I don't remember the details and it would be a painful process to search through a lot of 68HC11 assembly language code to see what happens during burnoff. I think I remember seeing a bunch of MAF readings at 23 before and after the burnoff test, so that seems to confirm this.

As mentioned elsewhere, 0.3 seconds delay plus 6 readings use 0.9 seconds, which just fits inside the 1 second window. If you look at the burnoff waveform that I posted earlier in this thread (post #52), things are very glitchy at the beginning of burnoff so you need the 0.3 seconds for the readings to stabilize.

puzzigully

Cliff,

Do you think setting the burn off time to 1.5 seconds might help?

Tequilaboy, what hardware and software did you use to get the output from the ECM?

tequilaboy

;--------------------------------------------------------
; ERR # 36 Params
; MAF Burn off Diag

LC22E: FCB 3 ; 0.3 Second Dly prior to Burn off check, (sec * 10)
LC22F: FCB 6 ; 6 fails req for ERR #36
LC230: FCB 95 ; Fail Burnoff test if HLM A/D > 95
LC231: FCB 20 ; Fail Burnoff test if HLM A/D < 20

The above got cut off when I added to my original post.

Hardware is just a USB ALDL cable from Moates. Software is TunerproRT with my own adx file for logging/displaying data. Nothing special really.