Using Inj Pulse Width to calculate

[toc]

MPGuino does this low level - by counting the number of seconds the injector is pulsed on for = amount of fuel consumed.

I can get the same parameter via ECU coms (Inj. Pulse Width). It's advantage will be in DFCO - MAF would show a reading, whereas Inj Pulse Width would equal 0.

So if reading Inj Pulse width via comms, I think this wouldn't be as accurate - right?
Can I do that? Read the Inj Pulse Width, I should manage several reads a second (I think > 5). And with that, add up the time it's open for, and count the speed as per normal.

I can't think of any obvious reason not to do that (as the current one relies on reading MAF anyway, and Inj Pulse Width has to be better).

Calculation would be something like:
const InjFlowRate = 50mls
(i.e. if the injector was open for 1ms, it would flow 50mls of fuel).

Time Inj Open = 300,000 milliseconds
(This is simply calculated and added to - read the inj Pulse width, assume it's constant between reads, multiply it by the time between reads, and add that to the variable).

Speed: Similar to Injector, but using speed variable. Add it all to an odometer variable.

Then fuel consumption merely equals:
Fuel Consumed (L) = (Inj Flow Rate x Time Inj Open) x no of Injectors
Fuel Economy (KM per L) = Odometer / Fuel Consumed

Any thoughts on the above ? Must be some reason that's not done in OBDuino.?

[toc]

Actually a thought would be the injector time to open and close - this would make the data in error - but then that's probably why MPGuino and OBDuino have fudge factors in them..

Any downsides to injector pulses over MAF via Data monitoring.?
Wouldn't I get the same result as if I monitored the low level output to the injectors anyway?

[ps2fixer]

Interesting idea, question is though, can you read if an injector is open/shut atleast 1000 times per sec (1ms readings) to accurately time the injectors? I would think you would want to read it for all injectors indepently, but I don't know that much about the inner workings of the car's computer system.

[toc]

Probably not, but it won't change that often I would think.

Inj Pulse Width is the variable I'd be reading, and at 10.4kbps it should be OK to query the parameter once every 100ms or 200ms. For the 100ms (or 200ms) between reads, I'd assume it was identical.

This is what happens with the OBDuino *anyway* using the MAF sensor - with an assumed stoich, so I fail to see it being any less accurate. It should be more since I would be monitoring the pulse width of the injectors and won't care if it's rich, lean or at stoich..

I think the conclusion is - for the most accuracy you need two flow meters - fuel supply and return, and that gives you true flow of fuel.
I won't have that, so the next best are:
- MAF - somehow convert V to Gm/s and use OBDuino and assume Stoich, calibrate it to the tank so that variations in Lean / Rich are part of the calibration..
- Monitor speed & Inj Pulse Width, calibrate that so that the inj open /close times worked into it's calibration just as per OBDuino.
- Low level, monitor injectors for open close, and speed low level, and calibrate that for the error margin it also has worked into it.

No matter which monitoring method, there'll always be calibration to try and adjust it to suit.

MAF doesn't know about lean / rich so assumes stoich (and I have to find a way to convert from V to gm/sec - sounds difficult).
Inj Pulse Width - there's a delay added which is the time spent asking for the data, it ignores the open /close times, but that falls into the calibration just as the MAF version of OBDUino would.
Low level - this doesn't consider inj open / close times, and so is fudged to suit using calibration.

Of those 3, I think Inj Pulse Width is more accurate compared to MAF as the engine wouldn't always run at stoich. I'm just concerned I haven't thought of something.. (why would OBDuino not use Inj Pulse Width?)

The difficulty for 'en masse' usage might just be knowing the size of the injectors..?