Quote:
|
All acceleration times already have about 0.001 second resolution, as they stand now.
|
Well, then there's no reason to change the loop time. I knew you took out the delay, but I assumed you used the timer to pause execution of the loop ... I never bothered to look. Based on your statement, the main loop is obviously able to repeat very quickly (some multiple of clock speed, of course).
Under the old code, the acceleration time was checked once per loop, during the doDisplay event which in turn called drag::Update. So, a user could hit 30 mph at, say 2.100 seconds, but checking for the condition could be delayed up to the length of looptime, in this case it could read 2.3499.
To improve accuracy I skipped the delay if drag_running or drag_waiting was true. This could drop the looptime to at most 110ms, or if I'd never called the LCD display routine, 7ms.
This caused its own problem!! Mainly, while waiting to start loop time is between 7 and 110ms. The engine is idling at 1200 rpm or 20 rps, or every 50ms. Our #1 injector fires once every other revolution, or once every 100ms. Also, our injector is open for a very short time, has a 500microsecond "settle" time -- long way of saying rpm flashes to 0 when we have a loop without an injector fire, and higher when we have two fires per loop. This also throws of calculation of instant mpg. It doesn't hurt current/tank mpg since those are based on total distance/fuel ticks, all of which remain accurate - but the displays jump around. Based on my empirical testing, anything below 2300 rpm would show this behavior -- so I started working on logic similar to Flip to EOC data when stopped - after 6 or so loops, basically saying "don't return 0 rpm unless 0 rpm has been reported N number of times.
The RPM buffer is to solve a problem that no longer exists as long as acceleration times are accurate to within .001, or actually accurate to looptime, which I'm guessing is greater than .001 second.