Lag factors -- potential surprises

This is a forum for discussing the development and testing of alpha MS2/Extra code. Documentation
(Runs on MS2 and Microsquirt)

Moderators: jsmcortina, muythaibxr

robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Lag factors -- potential surprises

Post by robs »

I was a bit surprised recently, when I had my MS on a variable power supply, to see that the voltage reported in Tuner Studio was appreciably different from what the supply was saying. Playing with the voltage control, it turned out that it could read either too high or too low. "OK, must be the lag factor" I thought. It wasn't important to what I was doing, so I left it at that.

I have been thinking about it since though. Some of the behaviour of the lags as implemented is a little surprising. In particular, the name suggests it slows down changes, but will get there eventually. In truth, it can simply ignore quite significant changes. Even a lag factor of 99 throws out far more data than you might expect. The code is in assembly language, but here is the equivalent C code:

Code: Select all

outpc.batt += (short)((flash4.adcLF * (adcval - outpc.batt)) / 100);
So we multiply the lag factor by the most recent change in reading, then divide by 100, truncate it to integer and add it to the previous reading. Seems OK, but when you consider the truncation to integer, it means that with any lag factor less than 100, a change of 1 unit (i.e. 0.1V) will never be reduced. This gets worse with lower lag factors. The threshold voltage that will be ignored is 10V/LF -- so a lag factor of 30 would mean 0.333V is the nearest you'll get to the value.

The same behaviour is there for all the lagged variables, but at various levels of importance. Battery voltage is considered in both injector dead time and coil dwell calculations and is probably the most important, and most prone to this problem. A fraction of a degree of temperature difference makes no odds. MAP and EGO don't seem likely to be critical at the last digit.

Suggestions
Two approaches seem plausible.
  1. Increase resolution by working with hundredths of a volt rather than tenths. Would require updates to ini file and recalibration of voltage limit values in flash.
  2. Use rounding in the code. I.e. instead of dividing by 100, divide by 50, shift right and add the carry
For whoever's interested, here are some actual lags, voltage changes, and comparisons of the "exact" lagged value, the result of the current calculations and the result of rounded calculations. Note how the 0.1 voltage change always returns 0 from the "asis" code.

Code: Select all

lag    V exact  asis round

 10  0.1 0.010 0.000 0.000
 10  0.2 0.020 0.000 0.000
 10  0.3 0.030 0.000 0.000
 10  0.4 0.040 0.000 0.000
 10  0.5 0.050 0.000 0.100
 10  0.6 0.060 0.000 0.100
 10  0.7 0.070 0.000 0.100
 10  0.8 0.080 0.000 0.100
 10  0.9 0.090 0.000 0.100
 10  1.0 0.100 0.100 0.100
 10  1.1 0.110 0.100 0.100
 10  1.2 0.120 0.100 0.100
 10  1.3 0.130 0.100 0.100
 10  1.4 0.140 0.100 0.100
 10  1.5 0.150 0.100 0.200
 10  1.6 0.160 0.100 0.200
 10  1.7 0.170 0.100 0.200
 10  1.8 0.180 0.100 0.200
 10  1.9 0.190 0.100 0.200

 20  0.1 0.020 0.000 0.000
 20  0.2 0.040 0.000 0.000
 20  0.3 0.060 0.000 0.100
 20  0.4 0.080 0.000 0.100
 20  0.5 0.100 0.100 0.100
 20  0.6 0.120 0.100 0.100
 20  0.7 0.140 0.100 0.100
 20  0.8 0.160 0.100 0.200
 20  0.9 0.180 0.100 0.200
 20  1.0 0.200 0.200 0.200
 20  1.1 0.220 0.200 0.200
 20  1.2 0.240 0.200 0.200
 20  1.3 0.260 0.200 0.300
 20  1.4 0.280 0.200 0.300
 20  1.5 0.300 0.300 0.300
 20  1.6 0.320 0.300 0.300
 20  1.7 0.340 0.300 0.300
 20  1.8 0.360 0.300 0.400
 20  1.9 0.380 0.300 0.400

 30  0.1 0.030 0.000 0.000
 30  0.2 0.060 0.000 0.100
 30  0.3 0.090 0.000 0.100
 30  0.4 0.120 0.100 0.100
 30  0.5 0.150 0.100 0.200
 30  0.6 0.180 0.100 0.200
 30  0.7 0.210 0.200 0.200
 30  0.8 0.240 0.200 0.200
 30  0.9 0.270 0.200 0.300
 30  1.0 0.300 0.300 0.300
 30  1.1 0.330 0.300 0.300
 30  1.2 0.360 0.300 0.400
 30  1.3 0.390 0.300 0.400
 30  1.4 0.420 0.400 0.400
 30  1.5 0.450 0.400 0.500
 30  1.6 0.480 0.400 0.500
 30  1.7 0.510 0.500 0.500
 30  1.8 0.540 0.500 0.500
 30  1.9 0.570 0.500 0.600

 40  0.1 0.040 0.000 0.000
 40  0.2 0.080 0.000 0.100
 40  0.3 0.120 0.100 0.100
 40  0.4 0.160 0.100 0.200
 40  0.5 0.200 0.200 0.200
 40  0.6 0.240 0.200 0.200
 40  0.7 0.280 0.200 0.300
 40  0.8 0.320 0.300 0.300
 40  0.9 0.360 0.300 0.400
 40  1.0 0.400 0.400 0.400
 40  1.1 0.440 0.400 0.400
 40  1.2 0.480 0.400 0.500
 40  1.3 0.520 0.500 0.500
 40  1.4 0.560 0.500 0.600
 40  1.5 0.600 0.600 0.600
 40  1.6 0.640 0.600 0.600
 40  1.7 0.680 0.600 0.700
 40  1.8 0.720 0.700 0.700
 40  1.9 0.760 0.700 0.800

 50  0.1 0.050 0.000 0.100
 50  0.2 0.100 0.100 0.100
 50  0.3 0.150 0.100 0.200
 50  0.4 0.200 0.200 0.200
 50  0.5 0.250 0.200 0.300
 50  0.6 0.300 0.300 0.300
 50  0.7 0.350 0.300 0.400
 50  0.8 0.400 0.400 0.400
 50  0.9 0.450 0.400 0.500
 50  1.0 0.500 0.500 0.500
 50  1.1 0.550 0.500 0.600
 50  1.2 0.600 0.600 0.600
 50  1.3 0.650 0.600 0.700
 50  1.4 0.700 0.700 0.700
 50  1.5 0.750 0.700 0.800
 50  1.6 0.800 0.800 0.800
 50  1.7 0.850 0.800 0.900
 50  1.8 0.900 0.900 0.900
 50  1.9 0.950 0.900 1.000

 60  0.1 0.060 0.000 0.100
 60  0.2 0.120 0.100 0.100
 60  0.3 0.180 0.100 0.200
 60  0.4 0.240 0.200 0.200
 60  0.5 0.300 0.300 0.300
 60  0.6 0.360 0.300 0.400
 60  0.7 0.420 0.400 0.400
 60  0.8 0.480 0.400 0.500
 60  0.9 0.540 0.500 0.500
 60  1.0 0.600 0.600 0.600
 60  1.1 0.660 0.600 0.700
 60  1.2 0.720 0.700 0.700
 60  1.3 0.780 0.700 0.800
 60  1.4 0.840 0.800 0.800
 60  1.5 0.900 0.900 0.900
 60  1.6 0.960 0.900 1.000
 60  1.7 1.020 1.000 1.000
 60  1.8 1.080 1.000 1.100
 60  1.9 1.140 1.100 1.100

 70  0.1 0.070 0.000 0.100
 70  0.2 0.140 0.100 0.100
 70  0.3 0.210 0.200 0.200
 70  0.4 0.280 0.200 0.300
 70  0.5 0.350 0.300 0.400
 70  0.6 0.420 0.400 0.400
 70  0.7 0.490 0.400 0.500
 70  0.8 0.560 0.500 0.600
 70  0.9 0.630 0.600 0.600
 70  1.0 0.700 0.700 0.700
 70  1.1 0.770 0.700 0.800
 70  1.2 0.840 0.800 0.800
 70  1.3 0.910 0.900 0.900
 70  1.4 0.980 0.900 1.000
 70  1.5 1.050 1.000 1.100
 70  1.6 1.120 1.100 1.100
 70  1.7 1.190 1.100 1.200
 70  1.8 1.260 1.200 1.300
 70  1.9 1.330 1.300 1.300

 80  0.1 0.080 0.000 0.100
 80  0.2 0.160 0.100 0.200
 80  0.3 0.240 0.200 0.200
 80  0.4 0.320 0.300 0.300
 80  0.5 0.400 0.400 0.400
 80  0.6 0.480 0.400 0.500
 80  0.7 0.560 0.500 0.600
 80  0.8 0.640 0.600 0.600
 80  0.9 0.720 0.700 0.700
 80  1.0 0.800 0.800 0.800
 80  1.1 0.880 0.800 0.900
 80  1.2 0.960 0.900 1.000
 80  1.3 1.040 1.000 1.000
 80  1.4 1.120 1.100 1.100
 80  1.5 1.200 1.200 1.200
 80  1.6 1.280 1.200 1.300
 80  1.7 1.360 1.300 1.400
 80  1.8 1.440 1.400 1.400
 80  1.9 1.520 1.500 1.500

 90  0.1 0.090 0.000 0.100
 90  0.2 0.180 0.100 0.200
 90  0.3 0.270 0.200 0.300
 90  0.4 0.360 0.300 0.400
 90  0.5 0.450 0.400 0.500
 90  0.6 0.540 0.500 0.500
 90  0.7 0.630 0.600 0.600
 90  0.8 0.720 0.700 0.700
 90  0.9 0.810 0.800 0.800
 90  1.0 0.900 0.900 0.900
 90  1.1 0.990 0.900 1.000
 90  1.2 1.080 1.000 1.100
 90  1.3 1.170 1.100 1.200
 90  1.4 1.260 1.200 1.300
 90  1.5 1.350 1.300 1.400
 90  1.6 1.440 1.400 1.400
 90  1.7 1.530 1.500 1.500
 90  1.8 1.620 1.600 1.600
 90  1.9 1.710 1.700 1.700
Have fun,

Rob.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Lag factors -- potential surprises

Post by robs »

Thought I'd post a couple of graphs to illustrate what I'm talking about:
lags.jpg
The graph shows the behaviour on a 1.2 increase in voltage from a previous steady state (based at 0). The dashed line shows the measured voltage. The other lines show how the lag code would converge towards this line with each iteration. Lag values plotted are 10, 20, 40, 50, 60, 80 and 90. Graph on the left is as the current lag code would calculate it. On the right is the result of the same code with rounding added as described above.

With either algorithm, as long as the lag factor is 50 or more, it comes to one stable value. With rounding, that value is also the correct value. With the current code, if you were converging from above you'd be 0.1V high instead of 0.1V low.

Where the difference is more striking is how much closer the rounded code gets to the correct value when a small lag factor is used.

Hope this makes the above ramble a bit clearer.

Have fun,

Rob.
masterx81
Master MS/Extra'er
Posts: 776
Joined: Mon Oct 25, 2004 7:36 am
Location: Asti - Italy

Re: Lag factors -- potential surprises

Post by masterx81 »

Strange that i not see interest on this by the developers :o
Enrico
Opel/Vauxhall Corsa GSi MS2
Subaru v4 EJ20 MS3
elaw
Super MS/Extra'er
Posts: 2926
Joined: Fri Oct 16, 2009 6:20 am
Location: Wilmington, MA

Re: Lag factors -- potential surprises

Post by elaw »

This is interesting!

I wrote a little program in c# to fool around with this, and noticed something else that's interesting.

Here's the program:

Code: Select all

		static void Main(string[] args) {
			byte batt = 120;
			byte lagfac = 33;
			byte adcval = batt;

			Console.WriteLine("Lag=" + lagfac.ToString());

			for (byte i = 0; i <= 25; i++) {
				if (i == 2)
					adcval = 140;

				if (i == 15)
					adcval = 120;

				batt += (byte)((lagfac * (adcval - batt)) / 100);
				Console.WriteLine("t=" + i.ToString() + ", ADCval=" + adcval.ToString() + ", batt=" + batt.ToString());
			}

			Console.Write("Press any key...");
			Console.ReadKey();
		}
And its output:

Code: Select all

Lag=33
t=0, ADCval=120, batt=120
t=1, ADCval=120, batt=120
t=2, ADCval=140, batt=126
t=3, ADCval=140, batt=130
t=4, ADCval=140, batt=133
t=5, ADCval=140, batt=135
t=6, ADCval=140, batt=136
t=7, ADCval=140, batt=137
t=8, ADCval=140, batt=137
t=9, ADCval=140, batt=137
t=10, ADCval=140, batt=137
t=11, ADCval=140, batt=137
t=12, ADCval=140, batt=137
t=13, ADCval=140, batt=137
t=14, ADCval=140, batt=137
t=15, ADCval=120, batt=132
t=16, ADCval=120, batt=129
t=17, ADCval=120, batt=127
t=18, ADCval=120, batt=125
t=19, ADCval=120, batt=124
t=20, ADCval=120, batt=123
t=21, ADCval=120, batt=123
t=22, ADCval=120, batt=123
t=23, ADCval=120, batt=123
t=24, ADCval=120, batt=123
t=25, ADCval=120, batt=123
Press any key...
The interesting thing I see here, and I realize this is probably more important in the theoretical world than the real one, is that when you have two opposite symmetric step changes the output value never returns to where it started!

I'm guessing that the use of a single byte for the battery voltage is a carryover from the original MS1 code, and given that code's lack of resolution for injection pulse width and timing, the inaccuracy in Vbatt wasn't a big deal. With the increased accuracy of the MS2/extra code, the issue becomes more important.
Eric Law
1990 Audi 80 quattro with AAN turbo engine: happily running on MS3+MS3X
2012 Audi A4 quattro, desperately in need of tweaking

Be alert! America needs more lerts.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Lag factors -- potential surprises

Post by robs »

Pleased to see some interest in this. As you say, it's probably mostly of theoretical interest as long as you're running a decently high lag value. Down at 33% though, that's 0.6V of potential variation for one exact voltage input. Even at 99% lag, without rounding, there is a 0.2V variation. BTW Eric, the code uses integers (2-byte) for batt and friends. I think you're right that the 0.1V precision is due to the historic use of unsigned byte.

Here's a graph along the same lines as your generated numbers:
voltlag.jpg
This is with a 50% lag. Red is with the current chopping approach, blue is with rounding. With a 30% lag, chopping undershoots both ways by 0.3V, rounding undershoots both ways by 0.1V.

FWIW, here is a patch to implement rounding in the batt code:

Code: Select all

diff -Naur orig/ms2_extra_misc.c ms2extra/ms2_extra_misc.c
--- orig/ms2_extra_misc.c	2014-03-04 11:50:51.000000000 +1100
+++ ms2extra/ms2_extra_misc.c	2014-03-04 11:52:58.000000000 +1100
@@ -467,9 +467,14 @@
                         "clra\n"
                         "ldab    %2\n"      // it is a uchar
                         "emuls\n"
-                        "ldx     #100\n"
+                        "ldx     #50\n"
                         "edivs\n"
+			"bmi	noinc\n"
+			"iny\n"
+			"noinc:\n"
                         "tfr     y,d\n"
+			"asra\n"
+			"rorb\n"
                         "addd    %3\n"
                         : "=d"(outpc.batt)
                         : "m"(tmp1),
But I'm not sure that the right approach wouldn't be to move away from lag factors altogether. They seem to have two potential purposes, neither of which they do all that well.
  1. Noise reduction -- extraneous values that have nothing to do with what is being read. What does 50% lag do with them:
    spike.jpg
    OK, it halves the height of the peak, but then spreads the noise over the signal for seven samples. If it were battery voltage, rather than shorten the dead time a lot for the one sample, we shorten it by less for seven. Given that this was noise, neither is desirable, and there's a case to be made that one mistake is better than seven. The right thing to do with noise is discard it, not smear it over your signal. If it's noise, and you can't eliminate it electrically, something like a median filter should be the weapon of choice.
  2. Jitter reduction -- real signal that is inherently prone to fluctuations.
    You have signal, you don't want to throw it away. But what you do want to do with it depends. Is the jitter a problem? If the alternator is genuinely changing the voltage rapidly, the best guess of the voltage that applies to the next squirt/spark is the most recent reading, not some blend of the last n readings. OTOH, MAP used to get very jittery, and no amount of playing with lags solved that jitter problem without introducing other problems (these difficulties were perhaps compounded by the truncation problems when running low lag values as in the graph earlier in the thread). The "right" answer was to use purpose built map sample averaging code, where many samples were read over a short period of time and averaged.
Maybe the only change that should be made is to the manual. Treat the lags like the noise reduction options and leave them off (i.e. 100%) by default. Further encourage users to sort out electrical noise problems electrically.

Practising what I preach, I have set all my lags to 100% and have seen no problems so far. The MAT and CLT graphs have quite a few more 0.1° wiggles, but they are no worry. MAP, TPS, Batt.V and TPS all look much as before. EGO in one of my cars is looking a bit busier than before, and maybe I'll relent on that one -- then again, the other car's EGO still looks stable, so maybe I have an underlying problem to look into.

But then I'm running my own somewhat customised version of the code. In particular MAP and TPS are using the "moving anchor" approach to settle down DOT calculations, and all ADC inputs are fed through a median3 filter. I think these changes were incorporated to greater and lesser extents in the gslender releases.

Have fun,

Rob.
elaw
Super MS/Extra'er
Posts: 2926
Joined: Fri Oct 16, 2009 6:20 am
Location: Wilmington, MA

Re: Lag factors -- potential surprises

Post by elaw »

Ah... I didn't know the code was already using 16-bit values... that makes things easy!

I actually tried modifying my code to use 16-bit ints instead of 8-bit, and to multiply the batt and adc values by an additional factor of 100. When that is done, the problem pretty much disappears... it would converge to within 0.01 volt even with a lag of 10.

I also agree on lags being a bad way to deal with noise, although it's easy to code and doesn't tax the processor too much. And as you say, the downside is that the lag is essentially what is called an "infinite impulse response filter", meaning theoretically a perturbation in the signal affects the output forever. Of course as you've shown, in practice the limited precision of a digital system causes the effect to disappear after a short time.

The flipside is you could probably write a book on "better" ways of dealing with noise... in fact I'm sure that's been done, probably many times! I can see a moving-window average having a lot of benefits. Also to reduce short-impulse noise, you might even combine the averaging with an algorithm that rejects or attenuates outlying values in any given group of samples.

In my opinion, the filtering amount and technique needs to be tailored to the particular signal in question. As you say, things like CLT and MAT really should not need any filtering at all, as any noise in those signals is likely due to electrical problems. Of course ironically, since those values change relatively slowly, they're also the least impacted by filtering's distortion.

The TPS signal is one that could legitimately need filtering. TPSs, except the Hall-based one I have in my imagination that I can't afford to build ( :lol: ), are mechanical devices and can sometimes have imperfect contact between the wiper and the resistance material. The resulting noise is easiest to deal with in software.

I don't remember where, but I think there have been some pretty involved discussions of such things here already... maybe in one of gslender's threads?
Eric Law
1990 Audi 80 quattro with AAN turbo engine: happily running on MS3+MS3X
2012 Audi A4 quattro, desperately in need of tweaking

Be alert! America needs more lerts.
lagos
Experienced MS/Extra'er
Posts: 197
Joined: Sat Jun 02, 2012 8:40 am

Re: Lag factors -- potential surprises

Post by lagos »

I have been noticing some odd behavior in the way that my ms unit is reading battery voltage as well. I will basically get voltage readings that are higher than my actual alternator output, and the problem persists regardless of how much i play with the battery calibration. My lag is set at the default 50%. Did you see similar behavior on your bench tests ?

I feel like a lot of the fueling consistency issues that i have had are battery voltage related.

Also, do you know if there is anything in the firmware code that will shut the engine down if battery voltage goes above a certain amount (trying to see if my issues are hardware or firmware related).
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Lag factors -- potential surprises

Post by robs »

elaw wrote:Ah... I didn't know the code was already using 16-bit values... that makes things easy!

I actually tried modifying my code to use 16-bit ints instead of 8-bit, and to multiply the batt and adc values by an additional factor of 100. When that is done, the problem pretty much disappears... it would converge to within 0.01 volt even with a lag of 10.
I'm not too sure what you mean by an additional factor of 100, but the batt truncation/rounding problem is independent of how many bits your integer has in it. The code represents voltage as an integer value (16-bits as it happens) in tenths of a volt. So it can represent anything in [-3276.8:+3276.7]V. Let's say you have a lag factor of 30, a last voltage reading of 12V and the latest reading from the ADC was 12.3V (represented as a 10-bit binary in the ADC unit, but that's already been converted). So we take 123, subtract 120, multiply by 30 divide by 100 and we get (123-120)*30/100 = 3*30/100 = 90/100 = 0 -- because we're using integers. So, with a lag factor of 0.3 we can never get closer to the true reading than 0.3V, unless the true value comes back to meet us. Rounding makes this somewhat better ((123-120)*30/50+1)/2 = 1. So we close in another 0.1V on the target. ((123-121)*30/50+1)/2 = 1. Close in another 0.1V. ((123-122)*30/50+1)/2 = 0. So with rounding, a lag factor of 30 can't get closer than ±0.1V.

As I said in the first posting, we could address this by changing the representation to units of 0.01V (still being able to represent [-327.68:327.67]V). Then the truncation problem would be ten times smaller. We could go beyond that to millivolts so that even a lag factor of 1% would eventually get near enough to the true value.
elaw wrote: I don't remember where, but I think there have been some pretty involved discussions of such things here already... maybe in one of gslender's threads?
Almost certainly you're thinking of one of my threads -- something like "Noisy tpsDOT" IIRC. That was where I came up with the "moving anchor" approach to TPS that I am still using. I think it was a worthwhile insight to look at the problem of tpsDOT as "how long has it taken to move the throttle a significant amount" rather than the way the code approaches it of "how much has the throttle moved in the latest (rather brief) time interval. Gslender agreed to some extent and included my change in one of his versions. Ken and James were not so enthusiastic.
lagos wrote:I have been noticing some odd behavior in the way that my ms unit is reading battery voltage as well. I will basically get voltage readings that are higher than my actual alternator output, and the problem persists regardless of how much i play with the battery calibration. My lag is set at the default 50%. Did you see similar behavior on your bench tests ?

I feel like a lot of the fueling consistency issues that i have had are battery voltage related.

Also, do you know if there is anything in the firmware code that will shut the engine down if battery voltage goes above a certain amount (trying to see if my issues are hardware or firmware related).
I haven't experimented with battery calibration myself. The calculations say 50% lag should close fairly quickly to within 0.1V of a steady voltage, but maybe your alternator isn't outputting a steady voltage? Perhaps you should try logging with 100% lag. That should give you what the MS is actually sampling (though the RS-232 still may not give you all samples).

Not aware of any firmware tests for high voltage. I think over-voltage protection is more something for hardware anyway.

Have fun,

Rob.
lagos
Experienced MS/Extra'er
Posts: 197
Joined: Sat Jun 02, 2012 8:40 am

Re: Lag factors -- potential surprises

Post by lagos »

Thanks for the feedback.
I hope your algorithm gets implemented because this is potentially a pretty big issue that has a direct effect on the fueling of the car. Hopefully the firmware developers will notice and respond to this thread shortly.
Last edited by lagos on Wed Mar 05, 2014 6:11 pm, edited 1 time in total.
kjones6039
Super MS/Extra'er
Posts: 1986
Joined: Sat Jul 22, 2006 8:02 pm
Location: Eureka, NV USA
Contact:

Re: Lag factors -- potential surprises

Post by kjones6039 »

Don't mean to hijack but, an old guy could use some education here. I have been testing voltage at the 12v feed at the MS. Should I be measuring somewhere else?

Ken
1979 Corvette - 383 CID SBC w/ Holley Pro-Jection 900 CFM TBI, 4-85 lb lo-z injectors & Walbro 255 pump
MS2 v3 w/extra 3.4.2 Release
36-1, Delphi LS2/7 coils in wasted spark, driven by v2.0 logic board from JBPerformance
Spartan Lambda Sensor from 14point7
TinyIOX from JBPerformance
elaw
Super MS/Extra'er
Posts: 2926
Joined: Fri Oct 16, 2009 6:20 am
Location: Wilmington, MA

Re: Lag factors -- potential surprises

Post by elaw »

Ken,

If your wiring is good, that's as good a place as any to test. If your wiring isn't good, that's still a good place to test, it's just that the voltage elsewhere in the system could differ depending on exactly what issues the wiring has (I'm thinking poor grounding scheme or too-small wire size, things like that).
Eric Law
1990 Audi 80 quattro with AAN turbo engine: happily running on MS3+MS3X
2012 Audi A4 quattro, desperately in need of tweaking

Be alert! America needs more lerts.
elaw
Super MS/Extra'er
Posts: 2926
Joined: Fri Oct 16, 2009 6:20 am
Location: Wilmington, MA

Re: Lag factors -- potential surprises

Post by elaw »

Robs,

I don't think I worded my reply very well, but we're on the same page. I was just talking about storing the voltage as (actual * 1000) instead of (actual * 10). That would give a range up to 32.7 volts which I *think* would be enough? I keep reading articles saying they're going to start making cars with 48-volt electrical systems but AFAIK it hasn't actually happened yet. I do know many aircraft use 24/28 volt systems.

Actually I don't know why (for storage, not for calcs) unsigned 16-bit ints could not be used. That would allow up to 65.5 volts with 0.001-volt precision.
Eric Law
1990 Audi 80 quattro with AAN turbo engine: happily running on MS3+MS3X
2012 Audi A4 quattro, desperately in need of tweaking

Be alert! America needs more lerts.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Lag factors -- potential surprises

Post by robs »

lagos wrote:
I hope your algorithm gets implemented because this is potentially a pretty big issue that has a direct effect on the fueling of the car. Hopefully the firmware developers will notice and respond to this threat shorty.
Hey, who you calling shorty? :-) And no threats in this thread, right?

Actually, I don't think it's that big a deal, and I don't think the developers should be put under any pressure. I travel in a different direction from the developers and am in this Megasquirt caper mostly to learn. I think I understand things pretty well, but from time to time I come across something that I can't explain and I go on a ramble about it here. Some people find these threads interesting, some find them irritating. I write them with the former group in mind and hope the others are content to live and let live.
elaw wrote: I don't think I worded my reply very well, but we're on the same page. I was just talking about storing the voltage as (actual * 1000) instead of (actual * 10). That would give a range up to 32.7 volts which I *think* would be enough? I keep reading articles saying they're going to start making cars with 48-volt electrical systems but AFAIK it hasn't actually happened yet. I do know many aircraft use 24/28 volt systems.

Actually I don't know why (for storage, not for calcs) unsigned 16-bit ints could not be used. That would allow up to 65.5 volts with 0.001-volt precision.
Ah, OK, that makes sense. Yes, the existing data storage is ample, given appropriate code and INI file changes. And yes, I quite agree, unsigned would work fine. You've got bigger troubles than the Batt.V reading if you power your MS with polarity reversed.

Have fun,

Rob.
lagos
Experienced MS/Extra'er
Posts: 197
Joined: Sat Jun 02, 2012 8:40 am

Re: Lag factors -- potential surprises

Post by lagos »

Oh boy... that was either a Freudian slip, or a good example of what 12 hour college days will do to you.

I wonder how much of an effect this rounding error/bug has on wide band sensor readings. There are countless of people on here that report that megasquirt is always off by about .2 afr when compared to what their gauge reads. I myself have had this issue, and was able to greatly reduce it by setting my lag factor to 90 (too much jitter at 100) and playing around with the battery calibration settings. If at lag value 50, the voltage never converges to its steady state value, then that could cause such problems, right?
masterx81
Master MS/Extra'er
Posts: 776
Joined: Mon Oct 25, 2004 7:36 am
Location: Asti - Italy

Re: R: Lag factors -- potential surprises

Post by masterx81 »

Maybe the 16bit resolution can be used only for internal calculation, a bit a waste of memory, but allow to npt change nothing in ini, as the presented voltage is always in the same 8 bit value
Enrico
Opel/Vauxhall Corsa GSi MS2
Subaru v4 EJ20 MS3
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Lag factors -- potential surprises

Post by robs »

masterx81 wrote: Maybe the 16bit resolution can be used only for internal calculation, a bit a waste of memory, but allow to npt change nothing in ini, as the presented voltage is always in the same 8 bit value
It's already a 16-bit value going to the Megasquirt. The ini file changes would be to tell TS that this is in 100ths of a volt rather than 10ths.
lagos wrote:Oh boy... that was either a Freudian slip, or a good example of what 12 hour college days will do to you.

I wonder how much of an effect this rounding error/bug has on wide band sensor readings. There are countless of people on here that report that megasquirt is always off by about .2 afr when compared to what their gauge reads. I myself have had this issue, and was able to greatly reduce it by setting my lag factor to 90 (too much jitter at 100) and playing around with the battery calibration settings. If at lag value 50, the voltage never converges to its steady state value, then that could cause such problems, right?
Yeah, your supposed double-typo was a fine effort -- plausible deniability I think they call it.

You raise an interesting question on EGO. The usual explanation is grounding problems. That probably is the right answer, but there may be something worth a look.

The EGO ADC code grabs the 10-bit ADC value, uses it as an offset to look up a table of unsigned byte values. This table has been populated by TS's "Calibrate AFR". In the case of the LC-1 that I use, the table contains values between 74 and 224, obviously representing AFRs from 7.4 to 22.4. So the lag code as it is, with any lag factor <100, leaves an undershoot of at least 0.1 afr. A lag factor of 40 would undershoot by 0.2. But in this case it would also undershoot on the high side e.g. when you come down from overrun fuel cut you'd settle 0.2 afr above the true reading. That doesn't sound like what people have been describing as it always seems to be on the low side. OTOH, perhaps they only get a chance to study it in detail when they're sitting, free revving in neutral. You'd expect the AFRs to come up from idle when you rev. Experimenting with a lag of 100 would soon answer the question. If my suggestion of rounding were adopted, any lag >= 50 would converge.

Where I think this gets a bit more interesting is when you consider what happens in the interaction between this "sticky lag" problem and PID feedback. P determines responsiveness, but may lead to under or over shoot, I tends to compensate for these overshoots over time, but can easily lead to wild oscillations, D resists all change and can dampen oscillations and overshoots, but can also make things very sluggish. I haven't looked into MS2/Extra's EGO feedback code, and I doubt I could guess its behaviour on inspection anyway, but the I parameter's tendency to cause oscillation can certainly be worsened if the feedbacks aren't responsive to the controls.

Have fun,

Rob.
lagos
Experienced MS/Extra'er
Posts: 197
Joined: Sat Jun 02, 2012 8:40 am

Re: Lag factors -- potential surprises

Post by lagos »

Experimenting with a lag of 100 would soon answer the question. If my suggestion of rounding were adopted, any lag >= 50 would converge.
The problem with 100% lag factor is that the readings fluctuate too fast to actually determine how close both are displaying.
Since the firmware code is open source, can you compile a version of the latest stable release with the new rounding method implemented? Id be willing to test it out.
jsmcortina
Site Admin
Posts: 39585
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: Lag factors -- potential surprises

Post by jsmcortina »

robs wrote:It's already a 16-bit value going to the Megasquirt. The ini file changes would be to tell TS that this is in 100ths of a volt rather than 10ths.
But it would potentially break any dashes or loggers relying on the existing scaling. That's why I haven't changed it already.

James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
masterx81
Master MS/Extra'er
Posts: 776
Joined: Mon Oct 25, 2004 7:36 am
Location: Asti - Italy

Re: Lag factors -- potential surprises

Post by masterx81 »

jsmcortina wrote:
robs wrote:It's already a 16-bit value going to the Megasquirt. The ini file changes would be to tell TS that this is in 100ths of a volt rather than 10ths.
But it would potentially break any dashes or loggers relying on the existing scaling. That's why I haven't changed it already.

James
Uhm... And use another variable for internal calculation with more resolution? We waste 2 bytes...
Enrico
Opel/Vauxhall Corsa GSi MS2
Subaru v4 EJ20 MS3
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Lag factors -- potential surprises

Post by robs »

lagos wrote: Since the firmware code is open source, can you compile a version of the latest stable release with the new rounding method implemented? Id be willing to test it out.
The code is viewable source rather than anything GPLish, and the developers are understandably reluctant for there to be umpteen "special" versions shared around out there demanding support. However, I don't think they'd object at all to a privately shared version to see whether a suggested change seems to improve things.

Looking at the Makefile, it looks like there might be a newer version of the build tools. I've been happy enough building with the old compiler, but sharing a version I'd best update the tools, or at least look into it. Give me a day or two and I'll PM you with a place to download from -- unless Ken, James or Jean veto. This will be a build with the Batt.V and EGO rounded lag changes, otherwise the exact 3.3.1a release code. Much as I like my other tweaks, I don't think you'd thank me for them.
masterx81 wrote:Uhm... And use another variable for internal calculation with more resolution? We waste 2 bytes...
The internal value is the one sent to Tuner Studio. While code changes to use a separate internal variable wouldn't be difficult, there would still be scope for confusion for people looking at TunerStudio vs. reality. If, as James pointed out, existing peripherals require this value to hold its current representation, I'd see the rounding approach as the way to go -- assuming any change is made at all.

Have fun,

Rob.
Post Reply