Lag factors -- potential surprises

[masterx81]

And enable the better resolution as an option?

[robs]

And enable the better resolution as an option?

I think it complicates things unnecessarily. The voltage compensations for injector dead time are up to about 0.2ms/V, so a 0.1V error leads to a 0.02ms dead time error. Impressed if anyone has their dead time accurate to this level. Similarly, dwell compensation is at its steepest at low voltages. Mine is around 0.4ms/V @11V, so a 0.1V error is only 0.04ms error in dwell. So, while it might be nice to have things in 10 or even 1 mV units, 100mV units are pretty well accurate enough.

But the truncation errors that I started this thread with are a somewhat different matter. With lags < 50, the gap never comes down to the 0.1V resolution. A lag of 30 gives you a 0.3V gap that will never be closed. That still only gives a dead time error of 0.06ms, and a dwell error of 0.12ms. But it's a double sided error. Sometimes it'll be reading on the high side, sometimes on the low side, effectively doubling those errors. They just might start to become significant. Adding the rounding code considerably reduces the errors with low lag factors, and abolishes the error altogether for lags >= 50.

As I said earlier, in the EGO code, the double-sided error may mess up the closed loop feedback. A bit like a steering box, too much free play makes it difficult to steer a steady path.

I have built a special for lagos, and we'll see what it does for him. I'm not expecting it to set the world on fire, but maybe it'll tidy up a small niggle or two. I don't plan to hand it out to anybody else, but for anyone who wants to build their own, here is a suitable patch file:

lagegobatt.txt

Have fun,

Rob.

[robs]

Just a quick follow-up posting. As suggested above, I built the firmware for lagos. Apparently it wasn't suitable for use in his car (using DIYPNP), but he tried it on the bench, just playing with the voltage and comparing the outputs of the standard and modified lag factor firmware. Pretty much as expected, for lag factors >= 50, there wasn't much difference, but at low lag factors (also as expected) the modified lag code got much closer to the true value.

Kind of funny that the existing lag code actually does something kinda like the moving anchor stuff, in that it simply ignores changes less than some value. Unfortunately, it also degrades changes greater than that value, which makes it pretty so so.

All academic for me. I'm running 100 lags on all inputs and both cars are running fine. I can't see any reason that everyone shouldn't aim for this (and start with this).

Have fun,

Rob.

[lagos]

I took some screen shots during my testing. You can clearly see in this example how far away from steady state voltage the values become in high smoothing situations.

Stock firmware.


Modified rounding code.


I don't agree with this being all "academic". Smoothing raw input is a good thing to do to, as long as you can do it without much delay and as long as it reaches steady state. Id personally love to see this change get added to the official code.