Fuel/Spark tuning for LH 2.4/EZK with TunerPro!

[klr142]

Nice nice. Yeah, people were talking about how much "sweep" or something that it allows, which can help smooth a larger cam's idle quality? Or maybe they were talking about something else being tweaked to help it idle better. I need to bring this other computer home so I can take a look at the new files. Or just do it here at work during lunch...

[beepee]

You could always bump up the idle speed for obnoxious cams, it's super easy.

Also, I think (in theory) a AMM setup can probably tolerate lumpy cams more easily than a MAP setup. I'd bet that the airflow measurement is more stable than the manifold pressure measurement anyway...

[JW240]

From my limited time playing with the big 16x16 fuel target map and the lambda feedback flag turned off, when reducing the values that were used while idling made the mixture leaner, increasing the value made it richer. So i'd expect that map to dictate the mixture the ecu wants to see for a given load/rpm. So if you tune it to get a certain lambda at a certain load/rpm, i'd expect it to try to reach those values. Fuel target map.

The other maps (5x5/6x6) just adjust various things like lambda authority, how much it is allowed to compensate at a given load/rpm etc. not sure what they all do but there are a lot of those little maps

[beepee]

Originally Posted by JW240

So i'd expect that map to dictate the mixture the ecu wants to see for a given load/rpm. So if you tune it to get a certain lambda at a certain load/rpm, i'd expect it to try to reach those values. Fuel target map.

There is no way for the ECU to verify that the target has been reached; the O2 sensor is narrowband.

Originally Posted by ipdown

In other words if left as is, (unsigned) 128 would mean that after doing the calculation for the given load and rpm, the calculated value is used as is without correcting it (zero correction). Changing a cell by 1 changes fueling by about 0.2%

If I am understanding this correctly, it is a fuel trim map. I am hypothesizing that the formula looks roughly like this:

(AMM measurement / 14.7) * (Fuel trim table/128) = desired amount of fuel

I *think* the lambda is used to 'learn' about where that centerpoint (128) on the trim table is.

This is how I would have done it (i.e. PURE SPECULATION):

Let's say the car is idling at 750 RPM with an AMM load of ~30. The lambda is reporting rich, so the ECU continually trims fuel until it hits lean, then bounces back. Each crossover (lean/rich and back) adds 'weight' to the trim measurement. So it learns lambda correction for the point below; we'll say it's -2.

x=RPM
y=AMM

    750  1000  2250
30  <-2>    _     _ 
40    _     _     _
50    _     _     _
60    _     _     _
70    _     _     _

Later we are cruising down the highway at about 2250 RPM, the AMM is reading 60. Our huge injectors are spraying tons of fuel and we are running super rich. The ECU continually lowers the fuel trim until we hit stoich again. After a few crossovers, the ECU learns this point:

x=RPM
y=AMM

    750  1000  2250
30  <-2>    _     _ 
40    _     _     _
50    _     _     _
60    _     _   <-8>
70    _     _     _

Now our ECU has two data points to work with. It can then use the blazing fast 8051 CPU to interpolate values in other areas:

x=RPM
y=AMM

    750  1000  2250
30  <-2>   -2    -3 
40   -3    -3    -5
50   -4    -5    -7
60   -5    -6   <-8>
70   -6    -8   -10

(these are totally bogus figures, didn't feel like whipping out excel)

Now, our ECU has an idea of how the injectors scale with airflow and RPM. It can then use the calculated scaling factors to estimate other fueling ratios.

Assuming that AMM output is linear, you would need twice the amount of fuel to establish the same AFR at twice the AMM load. But because of all of the variables involved, the ideal injector pulse width is not linear. Injector opening time, battery voltage, manifold pressure, air temperature, etc. all affect the amount of fuel effectively delivered. So we calculate a scalar to compensate.

Once we know our scalar, we can then calculate injector pulsewidth for AFRs that the narrowband can't verify.

Analogy: You are playing Goldeneye 64 with your buddy. He's got a Klobb (terrible gun) so he runs and hides behind a wall. But his toes are poking just around the edge. You've got a Cougar Magnum (shoots through walls!). You know where his feet are (your frame of reference, stoich/14.7), you know how tall his character is (fuel trim table value) so you can aim for the headshot! (desired AFR). The gun isn't 100% accruate, so you approximate the spread based on your previous shots when you could see the target (ECU-calculated injector trim/scalar). Put it all together, position the crosshair, and Boom! Headshot!

TL;DR: LH2.4 "shoots in the dark" when attempting to achieve AFRs other than 14.7. It uses hard coded values (fuel trim table, injector constants), and derived values (observations from narrowband o2) to estimate injector flow and combustion efficiency. These values are all used to establish fueling values for AFRs that are beyond the O2 sensor's sensitivity range.

Whoa. Didn't mean for that to get so long. Hopefully I'm correct in theory at least...

[JW240]

Originally Posted by beepee

There is no way for the ECU to verify that the target has been reached; the O2 sensor is narrowband.

yeah that is very obvious. how it works exactly i dont know, probably something got lost in translation, i didnt mean to say that the ecu has a way to verify the exact mixture (other than above/below stoich). the values in the 16x16 map tell the ecu to add or reduce the amount of fuel from the calculated value. when it knows what stoich is at a certain rpm(/load?) it could approximate other mixtures than stoich.

[beepee]

Originally Posted by JW240

yeah that is very obvious. how it works exactly i dont know, probably something got lost in translation, i didnt mean to say that the ecu has a way to verify the exact mixture (other than above/below stoich). the values in the 16x16 map tell the ecu to add or reduce the amount of fuel from the calculated value. when it knows what stoich is at a certain rpm(/load?) it could approximate other mixtures than stoich.

Yup. My question is: does the ECU use any of the learned lambda data while in open loop? I know it doesn't use lambda feedback, but if it learns a fuel trim, does it get applied universally?

I'm looking at you ipdown!

[ipdown]

Originally Posted by beepee

Yup. My question is: does the ECU use any of the learned lambda data while in open loop? I know it doesn't use lambda feedback, but if it learns a fuel trim, does it get applied universally?

I'm looking at you ipdown!

I guess Bosch never intended the lambda flag to be changed on the fly, so probably the ECU will still use it's adaptation values stored in the RAM until it gets reset. All adaptation/trim learned with lambda feedback will be stored in a few RAM variables shaping final injection pulse. Remember, this processor has only 256 bytes of RAM. The same variables are then used to trim the calculation result without lambda. They probably will have only minor effect of a static "offset" . I guess in open loop mode the ECU should be more responsive to map changes and accept them blindly.

[beepee]

Originally Posted by ipdown

I guess Bosch never intended the lambda flag to be changed on the
fly, so probably the ECU will still use it's adaptation values stored in the RAM until it gets reset.

By reset, do you mean key off/on, or hard reset (i.e. pulling the battery)? Do you have any hints to what parameters are stored in RAM; i.e. what is re-used across car starts and what is reset?

Like I said earlier, I have my narrowband emulation offset about 1 point leaner than normal and it hasn't seemed to affect the AFRs in open loop. But I haven't done any hardcore testing yet. One point might be too small of a change to make a noticeable difference to any trim values applied.

Maybe I'll set my narrowband to something silly and see what happens!

[klr142]

Originally Posted by beepee

Yup. My question is: does the ECU use any of the learned lambda data while in open loop? I know it doesn't use lambda feedback, but if it learns a fuel trim, does it get applied universally?

I'm looking at you ipdown!

From my non-turbo experience, what the car learns in closed loop, it DOES use to calculate what it wants to do in open loop. When I first install an ECU, my car runs pig rich up top until I have a few tanks of gas through the car and it finishes learning. Sometimes I even have to "train" it by revving the car all the way out to redline at lower loads so it stays in closed loop and learns that area of the maps. Once learned(depending on the tune, obviously), it will be leaner at high rpm/WOT.

Regarding resetting the ECU, he means disconnecting the battery(or ECU), or touching one battery terminal to the other for x amount of time.

[ipdown]

Originally Posted by beepee

By reset, do you mean key off/on, or hard reset (i.e. pulling the battery)? Do you have any hints to what parameters are stored in RAM; i.e. what is re-used across car starts and what is reset?

Like I said earlier, I have my narrowband emulation offset about 1 point leaner than normal and it hasn't seemed to affect the AFRs in open loop. But I haven't done any hardcore testing yet. One point might be too small of a change to make a noticeable difference to any trim values applied.

Maybe I'll set my narrowband to something silly and see what happens!

When the key is off the ECU retains it's RAM. Even when the battery is disconnected it can survive a few minutes because of a big capacitor holding it. I don't know everything in the RAM, but only adaptation and error codes are retained. Part of it is stack, part is sratch pad/runtime variables.
Some time ago I tested K-line like communication with the ECU. I traced where the DLC pin goes inside the ECU and how it is connected to. The CPU own UART-style serial port is connected to the hybrid chip, which forms some kind of a K-line adapter and to the outside goes only one pin - DLC. Anyway, after some headscratching were able to run my own code inside it and then, I patched my code into the unused (filled with 0xFF) area of the LH code, and hooked a call from the timer overflow vector to it. I were able to read all the RAM while the ECU were running with a simple K-line adapter built with comparators. Back then I discovered where it stores data read from ADC's, some timers, etc.
It is possible to make real time datalogger reading the load, rpm, temperature, inj. pulse width and a lot other stuff from the RAM. All this need a K-line to usb adapter hooked to the laptop and appropriate software patched inside the LH code. I plan to add this "patch" in my new software, but probably not in the first version I am going to release at the end of week, since I need to do some testing on it before.
And finally, since the RAM is only 256 bytes, it can be displayed as 16x16 table and you can observe all used/changed bytes at once. But more on this a bit later.

[linuxman51]

that would be pretty sweet.

[klr142]

Oh yes...

[linuxman51]

shoot me the stuff, I'd love to help test this stuff.

[SteveMD]

Beepee explains things so clearly even I understand and would try this

[beepee]

Originally Posted by ipdown

It is possible to make real time datalogger reading the load, rpm, temperature, inj. pulse width and a lot other stuff from the RAM. All this need a K-line to usb adapter hooked to the laptop and appropriate software patched inside the LH code. I plan to add this "patch" in my new software, but probably not in the first version I am going to release at the end of week, since I need to do some testing on it before.

[beepee]

Originally Posted by SteveMD

Beepee explains things so clearly even I understand and would try this

Thanks

Originally Posted by linuxman51

shoot me the stuff, I'd love to help test this stuff.

me too me too!

[beepee]

Oh yeah, just uploaded v7 of the fuel XDF, it has categories, etc. now. Lots of unknowm tables which I pulled from ipdown's editor. Maybe we can trace some of these out...

[beepee]

aaaaaand v8 is up
http://dl.dropbox.com/u/2074311/Volv...-beepee-v8.xdf

added CORRECT injector constants
labeled CORRECT idle table
did some gross speculation

Also flooded out car 3-4 times

Is anyone with an ostrich using my XDF? Feedback would be awesome.

Sorry about the super frequent updates; I have been slightly obsessed as of late

[turbovulvo]

I like seeing the updates, this is interesting.

[linuxman51]

Originally Posted by beepee

aaaaaand v8 is up
http://dl.dropbox.com/u/2074311/Volv...-beepee-v8.xdf

added CORRECT injector constants
labeled CORRECT idle table
did some gross speculation

Also flooded out car 3-4 times

Is anyone with an ostrich using my XDF? Feedback would be awesome.

Sorry about the super frequent updates; I have been slightly obsessed as of late

scaring me with the flooding the car out bit. I has ostrich and am opening up mah ecu.

[klr142]

Originally Posted by beepee

Sorry about the super frequent updates; I have been slightly obsessed as of late

I don't blame you... One bit. I know it's been in my mind for the past month, that's for damn sure.

Originally Posted by linuxman51

scaring me with the flooding the car out bit. I has ostrich and am opening up mah ecu.

w00t.

I'm downloading everything onto my work computer now, going to hang out here for a bit while Cassie works on her S70.

[MrBill]

I'm excited for beepee to bolt a "real" turbo on his car and step this tuning up to some real ****

Exciting++

[Jerd]

STupid question is stupid. Will this fix my Dieing at idle because of my retarded BOV.

My theory is that LH2.4 is doing something to correct for the air loss. Because when my car dies it does not run lean or rich. It just dies. Also after driving hard it will not die it will idle like a champ even if right after the bov goes off i put the clutch in at supper rich afrs. It idles. But after i shut the car off and start it back up, give it a little gas like half throttle the bov opens and the next time i try to idle it will die. Oh and my check engine light is on constantly.

So do you think i could fix this?

[klr142]

So, this is the new wideband o2 to get, aye? Looks and sounds good... http://14point7.com/SLC-Pure-Plus.php

Reasonably priced, too.

Originally Posted by Jerd

STupid question is stupid. Will this fix my Dieing at idle because of my retarded BOV.

My theory is that LH2.4 is doing something to correct for the air loss. Because when my car dies it does not run lean or rich. It just dies. Also after driving hard it will not die it will idle like a champ even if right after the bov goes off i put the clutch in at supper rich afrs. It idles. But after i shut the car off and start it back up, give it a little gas like half throttle the bov opens and the next time i try to idle it will die. Oh and my check engine light is on constantly.

So do you think i could fix this?

What's your check engine light say? What if you put in a quality BOV?

[DNAsEqUeNcE]

SLC is a baller unit