fuel mileage calculation based on pulse width

[Craig 94 TA GT]

I'm trying to develop an app that shows your real-time miles per gallon based on output from scanning software. Is this logic correct? It seems like it really accurate based on initial calculations. Again, it's real-time only to calculate what MPG you're getting at that instant. This would be to figure out why your car is getting low mileage, how easy you need to be on the throttle, etc.

Here it is:

1) Get RPM
2) Divide #1 by 60 to get to Revolutions per second.
3) Divide #2 by 2 since the injector opens only once per 2 RPM
4) Get current pulse width
5) Multiply #3 by #4. This is how long your injector will stay open (in milliseconds) per second.
6) Multiply #5 by 3600 to get the number of milliseconds the injector will stay open per hour.
7) Divide #6 by 1000 to get the number of seconds it would be open for,given an hour of driving at that flow rate.
8) Multiply #7 by the number of cylinders. (Or calculate by bank if you have split BLMs/pulse widths). This is the number of seconds of using fuel per hour, for all cylinders.
9) Get injector rate (lb/hr). If you know gal/second rate, skip tp #12
10) Divide #9 by the weight of a gallon of gas (this can vary, but generally 6.25 is close).
11) Divide #10 by 3600 to get gallons/sec rate of injectors.
12) Multiply #11 by #8. This is the number of gallons consumed when running an hour.
13) Get MPH.
14) Divide #13 by #12. This is miles/gallon.

Example driving an LT1 on the freeway:
2100 RPM, 70 mph, 5 mS PW/injector, 24.9 lb/hr injector flow rate
1) 2100
2) 2100/60 = 35
3) 35/2 = 17.5
4) 5
5) 17.5 * 5 = 87.5
6) 87.5 * 3600 = 315000
7) 315000/1000 = 315
8) 315 * 8 = 2520
9) 24.9
10) 24.9/6.25 = 3.984
11) 3.984/3600 = 0.001106666666667
12) 2520 * 0.0011066666666667 = 2.788
13) 70
14) 70/2.788 = 25.108

If you were driving for one hour at exactly 70 mph at 5 mS pulse widths with A4/3.23 gears (2100 RPM) and perfect throttle control, you'd get 25.1 mpg.

Does this seem right?

[Kevin - Blown 95 TA]

That might work for comparison only, of different types of steady-state driving. If you are accellerating, the instantaneous mileage would be changing.

In your calculations, you are assuming instant on/instant off and full rated flow during that time and FP might be affecting it as well. Guarantee it looks more like a spike and a rounded hump than a perfect square wave if you were to plot it and there's also inductance in the injector coil which causes a less than instant rise time and fall time. So while the coil on-off time looks mostly like a square wave, the actual fluid flow probably will not.

Even if you could do it accurately, it would give you only instantaneous mileage, as you stated. To do it correctly, it would be a complicated calculus problem, assuming you could get a time/flow curve of the fuel.

What would be interesting to do is get it to work and see how it compares to a car with an on-board computer, like a Lincoln that has a travel calculator built in and see how close you get. The problem is getting a car with that feature that you can tap into. You might have to use a generic scanner and record pulsewidths and then compare it to what's on the screen. It's interesting to watch those approach infinity miles per gallon as you decellerate from interstate speed and the car goes into DFCO.

[Craig 94 TA GT]

Thanks for the input, Kevin. I was afraid it might look spikey. Well, I guess I'll give it a shot to see. My parents have an IS250 that has this onboard instantaneous mileage calculator...and it is helpful to see if your foot has something to do with poor mileage. Also to see how many mpg you get at 40, 50, 60, 70, mph comparitively. I thought it might be helpful, but I guess the accelerating won't be too accurate. The onboard computer of the IS250 shows maxed out when completely off the throttle, and travelling at 20+ mph, and 0 mpg when stopped at idle. It does seem to jump up and down very quickly when accelerating/decelerating, so I can only hope that this calculation can come somewhat close. If I can get a scanner on it, I'd try, but I'd have to find an adapter for the laptop.

[Kevin - Blown 95 TA]

OK, well good luck with it and let us know how it goes. ou might be able to figure out the constant for the turn on time and get fairly close.

[fastTa]

I think the mathematical logic looks......well....logical.

Kevin eluded to something that will be a significantly altering variable. Pulse widths are not the amount of time the injector is open from seat to seat. Rather it is the amount of time that the injector's circuit is completed. There is voltage steadily being supplied to the injectors as soon as you turn the key to ON. The PCM controls the ground to the injectors and applies that ground in order to energize the solenoid. When the computer removes the ground to the injector, the solenoid (electromagnetic coil) becomes demagnetized and a spring forces the pintle, ball, or disc shut to cut off fuel flow.

There would be a miniscule delay in opening the injector due to the electrical resistance within the injector (and that electrical resistance would vary with temp), however that is a moot point because by the flip side of the coin, there would also be a similarly measured amount of delay in closing the injector once it is de-energized. So those two delays resultant of electrical resistance would effectively cancel each other out in regards to using time as a variable in a mathematical formula.

What is more significant is the fact that the pulse width is only the amount of time the injector is energized.

High impedance injector's solenoids are subject to a much slower to respond time than low impedance injectors. This not only affects the seat to open (peak) time, but also the closing time. After the injector has stopped receiving it's energetic signal the injector's solenoid will close slightly faster than it opened from the disc or pintle seat to open (peak), but not by much.

So say the measured pulse widths are 5 m/s, there is still fuel being squirted out of the injector after the solenoid has peaked at a time of 5 m/s. The close time is likely just slightly less than the open time.

Then you also have another quirk with pintle and disc injectors. They behave very much like the valves in our valvetrain. They are subject to what is called "bump" just like our valves in our motor are subject to bounce when they close. The noticeable difference being that injectors are subject to a measurable bounce not only when they close, but also when they open. This can also increase the overall time that the injector is releasing fuel.

This formula also assumes a perfect spray pattern/atomization.

You would also need to make sure to accurately adjust the injector's "rated" stiatic flow rate to the actual fuel pressure. And of course that could be difficult to the potential for variance while driving and within the fuel rails and system.

The only other real potential for error that I see, is in the weight of gasoline. The 6.25 lb ROT may be fairly accurate at ~2 deg F. But, the fuel is likely much warmer than that sitting in the fuel rail and obviously decreasing it's specific density.

Other than all the BS rambling I have just done , I think this is a great tool if taken for what it is.

Are you going to integrate the math into a spreadsheet or a software app?

[Craig 94 TA GT]

Thanks for the info, Kevin. I'm trying it anyway, hoping that it will be "close enough." I have a feeling it won't be, though. I have a test app that can read from a csv and get the estimated mpg based on readings. This is similar to how it would look, when I'm going to port it out to real-time. However, it's a bit more jerky than I'd hoped. It does seem to work, but this isn't even close to a release version. It's just a rough outline of the program. If anyone tries it, please let me know how it turns out. By the way, it only reads from FreeScan csv files. Nothing else because, again, it's just for testing to see how it would look for now.

http://s94938520.onlinehome.us/fuelMileageCalc.zip

[fastTa]

Thanks for the info, Kevin. I'm trying it anyway, hoping that it will be "close enough." I have a feeling it won't be, though. I have a test app that can read from a csv and get the estimated mpg based on readings. This is similar to how it would look, when I'm going to port it out to real-time. However, it's a bit more jerky than I'd hoped. It does seem to work, but this isn't even close to a release version. It's just a rough outline of the program. If anyone tries it, please let me know how it turns out. By the way, it only reads from FreeScan csv files. Nothing else because, again, it's just for testing to see how it would look for now.

http://s94938520.onlinehome.us/fuelMileageCalc.zip

Seems to run good on Windows XP, 2000, and Server 2003. I tried on several systems and the only one it wouldn't run on was my Windows 98 laptop. I am guessing that this is a .NET only app since it is dependant on several .NET specific .dll files, namely "MSCOREE.DLL."

Are you using an actual database or an emulator file?

[TraceZ]

Nice work Craig.. I just tested it on a couple .csv files I stored during my dyno pulls. It looks like my car gets around 5mpg under full throttle. LOL.

[Kevin - Blown 95 TA]

Nice work Craig.. I just tested it on a couple .csv files I stored during my dyno pulls. It looks like my car gets around 5mpg under full throttle. LOL.

It would actually be more accurate at WOT because the turn on/off time is minimized as a percentage of the total and it flows for a much longer time.

[Craig 94 TA GT]

Thanks for the input guys Do the readings seem somewhat plausible? I'm trying to figure out how to cure the jerkiness problem. But I'm thinking it might be due to Freescan only reading +- 0.5 pulse widths. I believe Datamaster can run within tenths? I'll bet that might cure some of the "jerkiness." Of course, as Kevin pointed out, pws aren't the exact time the injectors are open.

I forgot to mention too, not all features of the app work. Like the Configuration settings, the pause button, and it has a few bugs. Also, sorry for the horrible path line in the zip file. I didn't realize that option was checked. I'll have a better version a bit later.

Kev, you're exactly right. It's being developed in C# .Net Windows Forms. Also, the file that it's running is the attached .csv. This was a scan I did several months ago. It contained a mixture of freeway and city driving, so I thought it's a good way to test the app. My ultimate goal is to have it running when Freescan or Datamaster is running. It would either share the .csv file that they're writing to, or communicate with the PCM directly. I'll have to plan the best route there. Of course, if this whole program doesn't seem accurate, I'll just scrap it.

Tracy, nice mileage! 5 mpg under WOT...does it actually increase as speed goes up?

[Craig 94 TA GT]

Just to give a quick update, I'm still working on this application. I have created and modified a serial port class in the application that can read in directly from the serial port of the laptop. However, it's going to be a PITA to get the data read and formatted properly from the PCM. So it will take a long time.

I verified that the mileage appears so "jerky" because Freescan rounds PWs to the nearest whole number. Which of course is terribly inaccurate. I will try to program the app to get the nearest tenth or even hundreth, but I don't know how accurate that'll turn out (it should be smoother though). I'll post the latest release if and when I finish this.

By the way, does anyone know if Freescan's source code is available on the internet? Thanks.

[fastTa]

Any plans to integrate the use of USB? I don't even have a serial port on my notebook! Neither does my new desktop.

I wonder if AKM has a Firewire(1394) cable made yet. Sure would make things easy.

I am interested to see as to what resolution the PCM actually works with in regards to pulse width. I would venture to guess the PCM works with a 3 place (1/1000) decimal to keep things precise.

If you are planning on getting serious and eventually marketing this app, maybe you could call AKM Electronics and just concisely present your goals to them and see if they would be willing to work with you on this. I'm sure Freescan is probably open source and I bet they would be willing to work something out as far as helping you to market this once you have a final product.

[Joe 1320]

Just to give a quick update, I'm still working on this application. I have created and modified a serial port class in the application that can read in directly from the serial port of the laptop. However, it's going to be a PITA to get the data read and formatted properly from the PCM. So it will take a long time.

I verified that the mileage appears so "jerky" because Freescan rounds PWs to the nearest whole number. Which of course is terribly inaccurate. I will try to program the app to get the nearest tenth or even hundreth, but I don't know how accurate that'll turn out (it should be smoother though). I'll post the latest release if and when I finish this.

By the way, does anyone know if Freescan's source code is available on the internet? Thanks.

I am curious as to what the factory uses for their computations. Several of the different car models include a digital fuel mileage readout, that figure has to be calculated from somewhere.

[fastTa]

I'd be willing to bet that the factory MPG gauges rely on a logic very similar to Craig's; obtaining the current pulse width and then figuring a rough estimate based upon that.

Drving habits, wind speed, wind direction, general weather, tire pressures, injector health, etc. are all factors that can skew the actual MPG our cars get. But, to a somewhat definite point, the pulse widths are resultant of those very outside contributing factors via the PCM monitoring the mass of air entering the motor, load, RPM, and TP.

Most of the factory vehicle's PCM's don't know the fuel pressure and that cause some erratic readings but it will be fairly close. I'm curious if the factory PCM's use a fixed specific weight for the fuel, or if they actually factor it in as an obtained variable based roughly upon maybe engine coolant temp or something to that effect.

[Craig 94 TA GT]

Interesting thoughts, guy...but I don't think it would ever be good enough (nor probably as accurate) to market. Just a tool for us car guys

First things first, though. Kevin, where else can you get a USB cable? I'll probably need one to test and implement a USB interface .dll. I also am using an old laptop for the serial port cable and am dying to move on, as well! Thanks...