[mdlug] OBD fuel monitor fine tuning

[Drew]

     By means of a specially improvised funnel I've managed to 
determine the maximum possible
state of fuel tankage fill, to within plus or minus a cup; and have 
logs for two separate measurement
runs, to at least the same precision:

2007:09:16 to 2007:10:20
     Actual use:   43.833 gallons
     Tabulated:    40.301 gallons
     tabulated short by:   8.1 percent

2007:10:20 to 2007:10:25
     Actual use:   9.652 gallons
     Tabulated:    8.895 gallons
     tabulated short by:   7.8 percent

     So the software seems to be pretty consistently short in its 
estimate by about 8 percent, which is
better than I had any right to expect. Of course I still plan to 
implement a correction factor; but before
I do I'd like to get a detail or two settled.

     First off, I'd like to know what exactly should be done with the 
Fuel Trim numbers. There are *four*
of these, two Short Term and two Long Term, each a one byte number. 
According to the Python
code to OBDGauge, numbers less than 128 indicate lean adjustment 
while numbers greater than
128 indicate rich adjustment. But how exactly to apply these numbers 
to the MAF readout?

     Currently,  I'm using (MAF / 14.7) * FTRIM1/128 * FTRIM2/128 * 
FTRIM3/128 * FTRIM4/128 to
get mass flow of fuel, and a density of 6 pounds per gallon to divide 
by to get volume flow. Is
there an official, more "correct" way to apply the Fuel Trim numbers? 
Where might it be found?
Of course, I should probably get a measurement of the density of 
gasoline (weigh a measured
gallon) myself...

     The other major issue is that because my program runs through an 
interpreter (Pocket C for
Palm OS), access to the RS232 port is slow. The six readings that are 
necessary to do the
calculations take between two and three seconds to obtain, so since I 
have the loop wait for the
next whole second, readings occur at three second intervals. It is 
possible to miss significant
events (eg, throttle boosts lasting a second or two) adding 
uncertainty to the results.

     I've noticed that OBDGauge itself, which runs direct (without an 
interpreter) takes the same
two or three seconds, maybe less, to get *all* of the OBD's different 
values. By creating a
stand-alone executable, I could get the time resolution down to a 
second, or even half a second.
Trouble is, I've found the software for generating executables for 
the Palm to be a bit hard to
figure out how to use. Does anyone have suggestions for software that 
can generate stand-alone
executables, resembles C enough to be useable immediately, and still 
gives access to the
serial port?

----

- Drew.