Page 8 of 13 FirstFirst 12345678910111213 LastLast
Results 71 to 80 of 122

Thread: Calculating MPG from VSS and MAF from OBD2

  1. #71
    Newbie
    Join Date
    Nov 2009
    Posts
    4

    MPG from psuedo MAF

    Thanks Bruce. I haven't gathered any data of engine load yet but I will later and report back.

    I did sample rpm, map , speed and air intake temp over a 20 minute drive and used your psuedo MAF calculation and the MPG results look pretty good. My average MPG was 33 and I used a VE of 80. Ive attached a plot of instantaneous MPG versus time sample.


    I'm also having overflow problems with my microcontroller calculations but at least I know this formula will work now.


  2. #72
    Newbie
    Join Date
    Nov 2009
    Posts
    4

    Load compared to approximate IMAF

    *disregard*

  3. #73
    Constant Bitrate
    Join Date
    Jan 2010
    Posts
    130
    I have to say, I wish I had found this forum/thread months ago! There is a lot of good information. But, it not clear to me how any of the methods discussed could be a particularly accurate MPG measurement. Useful as general gauges of fuel consumption/economy, yes. But a good predictor of fuel tank use? I'm having a hard time seeing it. But, perhaps I'm missing something.

    Take Mr. Lightner's method with MAF and VSS, which he has reported gives him very good accuracy. I'm trying to reconcile it with 30 seconds of routine driving:



    One nice side effect of having just developed a Wi-Fi OBD-II interface is all the cars at my house are an iPhone click away from logging (at least until someone gets wise at work and I have to give some of the units back)! In this case I took a short trip in my daughter's Saturn ION. She was blocking me in and it was pouring rain today.

    I haven't wired any of our other modules, like one of our wideband controllers, into her car, but the ECU (or ECU's, two respond to OBD-II requests), are CAN and pretty fast, so I generally grab a lot of channels out of it. So, at first glance, the raw log above is probably gibberish. But if we turn off everything but RPM and VSS, you can see what I was doing:



    I was stopped (or nearly so) when I started to log. I then pushed the gas a little bit to get up the steep side of a small hill. I then coasted down the hill, breaking to a stop at the stop sign. A few seconds after leaving the stop sign, I went ahead and stopped the log. Now let's put MAF back in:



    Because of the scale, it might be a little hard to see (even if you click on the image for a larger view). But we can see that at about 20 seconds into the log, MAF was very low and VSS still pretty high. So let's drop in a marker:



    MAF is actually 3 and change, but because of the scale it is being shown in the marker as "3". So, it would seem that we should get a high number from Mr. Lightner's formula, but not an astronomical one. Let's confirm that by creating a math channel (and hopefully I got the basic formula right):



    If you click on the image, you will see that we are calculating 81.8 MPG at that coasting point. This is not at all an unreasonable estimate, but is it right? The assumption is that we are running at 14.7 AFR, but let's take a look at one of the narrow band O2 sensors in the car:



    Prior to the 15 second mark, we can see the ECU chasing stoich, which is normal for closed loop operation, but then it indicates a solid lean of stoich signal for about 10 seconds. So, we are not at lambda 1.0 (or *approximately* an AFR of 14.7, but that is another story). But how lean? Narrow band O2 sensors have a pretty steep curve very near stoich.

    In this case, we get a little break, because the ECU reports EQ_RATIO, which is not a wideband measurement of actual mixture, but is the mixture that the ECU declares that it is attempting to achieve. Let's turn that on:



    It's saying that during that period it is trying to achieve 1.11 lambda, or about 16.3 AFR. 16.3 sounds pretty close to 14.7, but it actually is a pretty big error, percentage wise computationally. But that assumes that we are even running 16.3:1. That is as high as I can ever get that ECU to report, and the RPM trace makes a distinct change there. It seems to me that it is quite possible that we are in overrun and the injectors are closed. We could tell for sure with a wideband, or possibly a vendor specific PID, but I would bet good money (or at least OK money) that I had nothing but free air in the exhaust for part of that period.

    Either way, we can see that for chunks of time in routine driving, 14.7:1 is not correct, sometimes way incorrect. In fact, as I start away from the stop sign at the end you can see that the O2 sensor swings rich and the ECU claims to be targeting a value quite a bit richer than lambda 1.0.

    Don't misunderstand me. I'm not trying to belittle the work that has been done. I'm just wondering how these readings and computations could ever be true MPG measurements (as opposed to more general 'fuel economy' measurements).

    MAP based calculations seem like they would be worse to me. I believe that MAP (OBD-II mode 1, pid 0xB) is a 1 byte value. That seems pretty course for the calculation. Aside from the question of VE, there is the issue of ECU speed. With MAP, RPM, IAT, and VSS, you are talking 4 channels of OBD-II data. Obviously, that wouldn't be a problem on my daughter's ECU. But my wife's older Lexus? Definitely an issue. It uses ISO 9141 and is slower than average to boot.

    Remember, we are taking little snapshots in time. If, as above, you are grabbing the important values 12-13 times a second, you are above the Nyquist frequency for typical 'right foot' changes and have a pretty good idea of what the vehicle is doing. If you are getting a complete set of samples 1-2 a second, the gaps between your 'snapshots' is getting pretty big. Also, the relationship between the individual values starts to get distorted (if it took a second to gather all four, then the individual values are time shifted from each other over that second).

    I'm sorry if I'm missing something obvious, I'm just trying to matchup the work here against what I've actually measured myself. And, again, I *really* wish that I had found this thread a couple of months ago!

    -jjf

  4. #74
    Maximum Bitrate
    Auto Apps:loading...
    VegasGuy's Avatar
    Join Date
    May 2009
    Location
    Las Vegas
    Posts
    618
    I think you're missing a couple of points.

    1. Your sample size is exactly 1. You've examined behavior in a single car with a single set of components over a very small time frame. Go back and do this for 15 brands and 30 models and then I think you can fairly assume that tha data you are seeing is representative.

    2. Average vs Instantaneous. Drive the car for a week and record your calculations and then compare the result with the general formula and see what the difference is. If it's greater than 5%, maybe you have a point and all the effort was worth it. If not, there you go.

    The question that needs to be asked is: Why are you interested in MPG? If it is to try and achieve the best mileage possible, then the precise values returns are irrelevant. As long as you "behavior" results in increased milage, that's all that matters. If you goal is to track variations or changes in engine performance, it seems to me that you already have access to far better indicators of that than calculated MPG.

    GREAT looking data, by the way. looks to me like you have a really neat product.

    Cheers,

    VegasGuy

  5. #75
    Low Bitrate
    Join Date
    Mar 2006
    Posts
    95
    jff,

    i brought this up a while back, about the assumption that the vehicles are always running at stoich. the general consensus around here is that it's "good enough". i'm with you though, i'd like to see another solution that is not based on AFR assumptions.
    2006 Corolla S Ex-Audio 7" Epia MII ATI AIW VE 512MB Mini-Box.com M300 Case 100GB 2.5" HDD Z-COM XI-325HP+ Linksys WSB24/WRT54G w DD-WRT Treo 755p BT Modem Lite-On Slotload DVD GPS JVC AVX2 2x JL Audio 8" Alpine Type-S F/R

  6. #76
    Constant Bitrate
    Join Date
    Jan 2010
    Posts
    130
    Quote Originally Posted by VegasGuy View Post
    1. Your sample size is exactly 1. You've examined behavior in a single car with a single set of components over a very small time frame. Go back and do this for 15 brands and 30 models and then I think you can fairly assume that tha data you are seeing is representative.
    I should have been clearer. I posted a snippet by way of example. The reason I wish I'd found this months ago is I was trying to come up with a solid, generic set of calculations for a product. I didn't have a hundred cars, but I had 7 pretty diverse ones, and I was the 'fill-up Nazi' about tracking actual fill-ups (my own daughter was the worst offender).

    I didn't do the computations at the time, but logged lots of raw data, all the time. Then tried various computations after the fact and compared it to actual fuel consumption. A couple of the vehicles were also equipped with widebands.

    Quote Originally Posted by VegasGuy View Post
    2. Average vs Instantaneous. Drive the car for a week and record your calculations and then compare the result with the general formula and see what the difference is. If it's greater than 5%, maybe you have a point and all the effort was worth it. If not, there you go.
    When I use the simple simple MAF and VSS formula here, I see errors ranging from about 50 to 150%, heavily leaning towards overestimation of MPG. Oddly, it doesn't change the range of error much if you average the MPG calculations themselves, or average MAF and VSS and do the calc. Given the way the MAF sensors work, I would have expected something different.

    In any event, my results don't make the computation 'wrong', but they do make it clear why CARB would love to see a more robust O2 sensor and more wideband closed loop operation.

    Despite my example above, which is 'leaner', think about it. Edmunds found that changing driving habits to less aggressive changes fuel consumption an average of 37%. The other thing that turned up in my data is that people take a lot of short trips. When we gun it, the ECU's go rich to slow down the flame front and move peak pressure. They don't want detonation under heavy load, so they error rich. Similarly, when we start the car, it is open loop for awhile, since the O2 sensors are often heated and all the condensation in the exhaust can easily shock cool them and crack the ceramic.

    So, it's quite possible that, when we correct for all that rich operation, the calculation is 'good enough'. I'd love to hear more from the people who have been getting good accuracy from them (really).

    Quote Originally Posted by VegasGuy View Post
    The question that needs to be asked is: Why are you interested in MPG? If it is to try and achieve the best mileage possible, then the precise values returns are irrelevant. As long as you "behavior" results in increased milage, that's all that matters. If you goal is to track variations or changes in engine performance, it seems to me that you already have access to far better indicators of that than calculated MPG.
    Actually, for me, that is THE question. It probably sounds odd, since my meal ticket is a motorsports company, but both I and my boss are more of the Sierra Club mold. So, the projects I've really enjoyed of late have been things like putting our wideband technology in power plant emissions systems (talk about BIG engines!) So I was thrilled we were up for some attention to economy in this latest project.

    Aside from finding that true MPG is hard, I started wondering if these sorts of readings, accurate or not, are really the best way to modify driving behavior for economy (and the planet). Look at the calculation above, it swings from single digits to over 80 in a moment, all with very modest TP change.

    These sorts of sensitive readings got me thinking about the Deming Funnel experiment (Google it if you aren't familiar with it, there is probably a virtual version you can play with online). I wondered, if I am chasing a sensitive reading with my foot, am I potentially being less fuel efficient? That is, could I be losing some efficiency to overcorrection?

    That was a lot harder to get good data on. First, I can't harp at people to stare at something other than traffic! Second, judging from the other logged data, modifying driving behavior is hard.

    In the end, I wound up with 3 methods all on the same 'economy' screen. One is a crude MPG calculation akin to the sorts we are talking about here. It is actually weird and a bit complicated, not because it is particularly accurate, but because it has to work with lots of ECUs, with varying PIDs and speeds.

    In addition to the big number that swings, I put a trip average and a day average below it. I actually think that chasing the 'trip' running average may be more economical than chasing the instant readings, but that is more of a hunch than a measured fact. In any event, it is an 'expected' reading for the car guys here, so I had to put it in.

    The rough MPG (which I only call "Fuel Economy") is then factored with an evaluation of reported load and drives a simple animation. That is also dampened. My hope is that it is less demanding, but demanding enough so that keeping the tree alive will result in a modest improvement in economy for average drivers (though the 'average' I'm trying to help incrementally improve is all based on my 7 drivers, who may not be very representational).

    The last measurement displayed is weird. I got the idea from a thread at an 'ubber MPG' site (I can't remember what the forum rules here are on outside links, but it is one of the easy ones to find). I take all axes of the accelerometer and sum their absolute values, feed it through a first order filter, and then inverse the scale. Basically it punishes rate of change and higher frequency noise. If you isolate the acc's from things like plastic on plastic vibration, keeping the value as high as you can will save gasoline, but it might also get you shot. I vowed to do it for a whole week for data three times, and never stuck with it for more than four days. Even so, I could see huge swings in my fill-up data (which inspired us to put a fill-up log in the economy portion as well).

    As much time and effort as I put into these, I still think they could be a lot better. That's why I was excited to see this thread. Fairly sensible and technical, and quite a change from the other online discussions I find on this - which normally start with something like 'have I over inflated my tires yet to cut down on surface friction?' I have no idea if that works or not (from my data, the only three recommendations I feel comfortable making to save cost/fuel are: slow down, use cruise control when you can, and buy your gasoline early Wednesday mornings...) but it is a step well beyond what our typical users are willing to take!

    Quote Originally Posted by VegasGuy View Post
    GREAT looking data, by the way. looks to me like you have a really neat product.
    Thanks! Those screen shots are from our desktop app, which is still free, but getting a little long in the tooth. I actually grabbed the data with our new interface and mobile software, but emailing it to myself and opening it on the desktop makes for a bigger view. Besides, those screens are pretty generic looking, but the mobile stuff has a bit more brand stamping. Even though the mobile software is free, the interface is not and I did not want to come across as a viral marketeer. I'm actually interested in this subject.

    -jjf

  7. #77
    What can I say? I like serial. Curiosity's Avatar
    Join Date
    Mar 2004
    Location
    Florence Yall, BFKY
    Posts
    2,684
    I agree that average is much more useful than instantaneous, but really is MPG the most useful information that can be provided? It all boils down to consumption and cost. Costs change per fill-up so that's somewhat difficult, but just for a layer above MPG, how accurate would it be to calculate oz/ml per instantaneous reading? That would be interesting to see on a graph, adding all those little values up, while grouping into short time frames between each noticeable change in rate. It could reduce averaging delay and pinpoint the times of more and less fuel use. The idea is eventually seeing how much it costs to sit at a light, and to accelerate to driving speed, and of course total trip cost. Would be cool.

  8. #78
    Constant Bitrate
    Join Date
    Jan 2010
    Posts
    130
    Quote Originally Posted by Curiosity View Post
    how accurate would it be to calculate oz/ml per instantaneous reading?
    I think you mean a layer below. Fuel consumed is basically the MPG calculation without the speed/distance component. In other words, to report MPG, fuel consumed at the moment has to be measured (or, really, estimated).

    In terms of accuracy, it would basically be the same problems. It actually isn't a trivial matter to measure/estimate fuel consumption. Small aircraft care *a lot* about fuel. And, although there are various commercial systems sold, none is really much more accurate than a calibrated dipstick and careful use of throttle positions and a watch.

    In terms of usefulness, I'm not sure I understand the benefit. MPG at least equates consumption vs. a standard of work. Do you mean this as a way to improve MPG estimates, or a different way of analyzing consumption altogether?

    -jjf

  9. #79
    What can I say? I like serial. Curiosity's Avatar
    Join Date
    Mar 2004
    Location
    Florence Yall, BFKY
    Posts
    2,684
    I mean as a different way of analyzing or bringing information to the user in simple form. MPG has been the industry standard to sell cars for a long time, but how useful is it when it changes drastically each millisecond or even second? But let's say we could see short term costs plus real time counting total costs from home, work, home, store, home, McDonald's, gas station, home, work, restaurant, work, home, bar, Walgreen's, cheap motel, home... then we would get a feel for what we're spending our gas money on. So the question is what's more practical or useful information?

  10. #80
    Low Bitrate
    Join Date
    Mar 2006
    Posts
    95
    Quote Originally Posted by jfitzpat View Post
    In addition to the big number that swings, I put a trip average and a day average below it. I actually think that chasing the 'trip' running average may be more economical than chasing the instant readings, but that is more of a hunch than a measured fact. In any event, it is an 'expected' reading for the car guys here, so I had to put it in.
    i spent some time trying to figure out the best way to display mpg data because you're right, the instantaneous data is useful, but it doesn't tell the whole story. the conclusion that i came to is that i want a bunch of weighted moving averages. if you can imagine a 2d graph, the x-axis would be the timeslice, the leftmost would be instantaneous, and as you move the right, the slices would get bigger, 5sec, 15sec, 30sec, 1min, 5min, etc., y-axis would be fuel consumption. you could go one step father and have historical values on the z-axis.

    do you know if any of the manufacturers provide injector pulse width through the ecu? that'd be my preferred way of computing mpg. injector size, number of cylinders, rpm & speed ought to get you a pretty good value (assuming fuel pressure is pretty constant, which it should be).

    also, if you really want to change people's driving behavior, you need to show how fast dollars are being burned, not gas. people understand and are motivated by dollars. and be annoying about it. play a cash register noise for ever 10c you burn.
    2006 Corolla S Ex-Audio 7" Epia MII ATI AIW VE 512MB Mini-Box.com M300 Case 100GB 2.5" HDD Z-COM XI-325HP+ Linksys WSB24/WRT54G w DD-WRT Treo 755p BT Modem Lite-On Slotload DVD GPS JVC AVX2 2x JL Audio 8" Alpine Type-S F/R

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •