[t vago]

Results of testing today - Partial success.

Today, on my drive to work, the calculated injector correction factor was a bit off, from what I expected, leading to lower-than-correct fuel consumption readings.

However, my code was easily able to read and process MAP sensor readings for each individual fuel injector event. Given that said events can occur from once every 150 ms to once every 19 ms, this represents a very significant capability.

Equation 1 below is used to correct the fuel injector pulse length reading for a returnless fuel system-equipped vehicle, when said vehicle uses a constant-pressure fuel pressure regulator.

(1) - F = sqrt( P(diff inj) / P(fuel pressure regulator) )

However, the equation for determining the pressure differential across the fuel injector,

(2) - P(diff inj) = P(fuel system) - P(intake)

has some complication associated with it. In particular, P(fuel pressure regulator) is a gauge pressure reading, while P(intake) is an absolute pressure. Or,

(3) - P(fuel system) = P(baro) + P(fuel pressure regulator)

Where P(fuel pressure regulator) is the rated fuel pressure of my fuel pressure regulator, and p(baro) is the absolute atmospheric pressure. Thus, equation 2 above turns into:

(4) - p(diff inj) = P(fuel pressure regulator) + P(baro) - P(intake)

Right now, my P(baro) estimator works by setting P(baro) to P(intake) when it senses that both the engine is turned off, and the vehicle is not moving. Ideally, this would give an accurate P(baro) right before the engine is turned on. However, in real life, this isn't always the case. The MPGuino hardware is always turned on, but the engine computer is sometimes shut off. When this happens, the power to the MAP sensor goes to 0 VDC, so the MAP sensor output itself goes to 0 VDC. This is what happened today.

I noticed that my estimated P(baro) was effectively at zero psi. This will (and did, of course) throw off the correction factor, rendering it useless for its intended purpose. Clearly, I will need to do something about that.

Now, I could recode the P(baro) estimator, but it would cause my code to grow more than it already is. As of right now, the code sits at 19640 bytes. Or, I could retain the existing code, and simply wait for a few seconds or so, after turning the ignition key to On, and before starting the engine. That would certainly give me an accurate P(baro). However, that would require that the driver wait before starting the engine every single time. Maybe the average MPGuino user would be this anal... I don't know. However, I don't want to depend on that.

Just had this thought - even if I did get an accurate P(baro) right before starting the engine, that P(baro) would only be accurate for a little while. Weather changes, elevation changes, and temperature changes all affect P(baro). My engine computer gets around this by estimating P(baro) based on throttle position, the MAP sensor, engine speed, and a lookup table. However, to implement something like that into my code would require both using the remaining analog input, and a calibration to generate a suitable lookup table. That could prove to be very challenging.

Were I to add a separate pressure sensor dedicated to solely measuring atmospheric pressure, that would certainly get rid of any costy estimation code, and any undue expectation on the part of the driver, but it would do so at the cost of using up the remaining analog input. This might not be a problem, but then again, it might be. For instance, I've read in this forum that other users saw how system voltage changes cause changes in injector reaction time, and went about coding to compensate for that. Well, that needs an analog input to be able to measure system voltage. If that input were instead used for barometric pressure, one would have to assume a more-or-less constant system voltage (which the base MPGuino code does, BTW).

Not to mention that a separate MAP sensor costs in the range of $40 or so.

I will probably end up going with adding a separate MAP sensor that is dedicated as a barometric pressure sensor. It will, of course, eat up that remaining analog input. However, it might be beneficial to members like KY Metro, who are looking to add a fuel pressure sensor due to how they operate their fuel pump. As long as the fuel pressure sensor would also read absolute pressures, this would not pose any problem with my code.