Sorry, never got back to you on the CSV. One, it looks like you didn't do it "Group UDS". That runs up to 8 queries per call, so you get time synced results. But the ECM won't take more than that in one query, so if you want to do 9-12 values, you need to set the Split option. So instead of all the values queried every 0.2 sec, each one is queried in sequence. With four values, that means a value is queried only every 0.8 sec.
Also, normalized load (IDE00085) is always good to log. That's a reflection of the engine load. As well as engine speed (engine rpm, whatever they are calling it, IDE00021). Without these, it's hard to know what's going on with the engine and what the values should be reflecting.
Air mass specified value, interesting. I don't have that on my MY09 CAEB. But 8K5907115C is also a CAEB, for MY13. Must be something they added at some point. Yeah, no IDE00350 on mine. I wonder if that would be interesting to track.
Yeah, if we add short+long and look at that, at 635sec, it gets weird and just goes very large rich (it's going massive negative trim, which is a cut of the injector pulse, because it thinks things are rich, and it's trying to cut that back to balanced). But I have no idea what was going on with the engine at that moment. The g/s is not idle, but not heavy load either. The long term stays fine through the sequence, it's the short term going all over.
That's not an idle moment, but maybe it was a throttle release? Good to log accelerator pedal as well. You see how it starts to add up the values to get a clear picture. Thus important to run Group UDS and Split. The log is already a bit too coarse of sample rate.
I'm running an OEM Hitachi MAF, and it's the same thing as an OE. Hitachi makes the MAF on these engines. My Hitachi box has it marked as 250-5079 / AFH60-37. That's the newer HUCO p/n system. It was MAF0116 under the old Hitachi system (Hitachi aftermarket is now HUCO).
I'm more concerned with the lambda sensor than the MAF sensor. The g/s isn't doing anything nuts, but I don't know what it should be doing in that moment from 630sec-655sec. You should also log IDE00559, measured lambda. Fuel trim is changed in response to measured lambda. If it's suddenly seeing rich out of no where, the question is why. If the lambda confirms reporting rich, then is it the sensor or the combustion. I wonder if there's an exhaust leak, the lambda is adjusting to that extra O2 and so reporting fine but actually running rich. Then once in a while that exhaust leak seals and suddenly the true rich is measured and it starts cutting fuel. But if it's causing the engine to stumble, it would seem that cutting is not actually good.
engine speed
normed load
accel pedal
"current of O2 B1S1, lambda"
long term mix
short term mix
g/s
kg/hr spec
What I notice, if I take the g/s and multiply it out to kg/hr, it's a lot more than kg/hr spec when it's also cutting fuel. Notice in that same 636-647, the spec is not changing much, but the g/s takes off, but only after the massive negative trim comes in. Is it doing the g/s boost to help try and balance some of the excess fuel it believes is there, even after cutting the injector duration? The same thing again at 780s range.
I'm out the next few weeks. But I just don't see a MAF side concern so much. If the MAF was massively overreporting, so the engine was dumping more fuel than actually should be for the air volume, then seeing that with very rich lambda, then cutting the fuel level back for the given g/s input, ok. But it could just be the injectors dumping too much fuel randomly, or the lambda sensor just being wrong, or exhaust leak, etc. Without a means to validate sensors in an isolated test config, it's a lot of random guess.
There's also logging fuel pressure actual and specified. Is the fuel pressure spiking randomly without a matching driver input event, etc.
Reply With Quote
Originally Posted by Smac770
Bookmarks