You could get a lot of nice data to massage if you did that..

Update rate will be critical in getting good data.

A vacuum gauge will give you engine load..

Essentially the engine will be most efficient at a given vacuum setting and rpm.

Vacuum doesn't necessarily equate strictly with tps.

I should hope not. Except in DBW cars, TPS equates strictly with your right foot.

I was trying to be nice. :)

Sorry I've been away for a while. Thank you for acknowledging me.

I think these various efforts to create BSFC measurements sound very promising. I hope to hear more about what kind of results people come up with.

I got my ELM327 in the mail today.. After a little experimentation this evening I think I may have found the software that will calculate a BSFC map from the OBD2 data..

Take a look and tell me what you think..

https://www.edgeanalysis.com/obd2.asp

That's an interesting product. Thanks for pointing it out.

I see that they are displaying and logging lots of OBD2 data. But I don't see where they are attempting to do any power calculations, like BSFC. So I guess you could export the raw data and apply your own procedure for deriving BSFC, but I think most of that work is going to happen outside this program. They're giving you raw speed data, but you have to translate that into acceleration, and then translate that into power, and then relate that to fuel use.

The power calculation includes tricky factors like whether or not you're traversing a grade, and the effect of aero drag at different speeds. These calculations are much simpler if you live on a planet with no hills and no atmosphere. Anyway, I don't see where that program attempts to tackle these issues. But maybe it's in there and I didn't notice!

And there's a separate issue, which I think you already know about. OBD (at least for most makers) doesn't read the injectors. So any fuel-use calculation is some kind of calculated approximation, based on things like air flow. This is how the Scangauge works, and I think under certain conditions it creates problems with accuracy.

Either way, I'm interested in hearing more about what you're doing, because I think you're on the right track and you're inevitably going to make helpful discoveries.

I haven't had time to do any more testing, but I got the impression that there was the option to do custom math in the program..

One problem I see with the program on the old laptop I have is that that it uses Microshaft's dot net framework and the update rate is considerably slower than a couple of other similar but less capable programs I have tried. The newer high level programming languages can be glacially slow on older machines, it took nearly half an hour to install the dot net framework on my laptop.

I know that there are some potentially tricky calculations to do and a few different factors to take into account.. Anywhere near my home there is no such thing as a flat, straight and actually level road so I plan on taking multiple measurements over the course of probably ten or twenty miles of driving and averaging the results.

I think one of the reasons that Scangauge loses accuracy sometimes is because many cars go into DFCO sometimes and Scangauge does not allow for that. As you say, OBD2 does not seem to directly access injector pulse width so all fuel consumption figures are inferred from other data.

However, as long as the engine is closed loop I think the fuel useage measurements from OBD2 data are probably pretty close, for this reason I intend to monitor the open loop/closed loop status and only process data that is taken during closed loop running.

One piece of data that may help you: OBDII reports Open Loop during DFCO, at least on my VW.

I'm really not sure. I think it depends a lot on the circumstances. For example, I suspect the SG/OBD2 approach also has a problem with cars that have a wideband O2 sensor (e.g., most modern VWs, I think). I think the SG calculations assume AFR that's stoich. With a wideband sensor, real AFR could differ quite a bit from stoich.

I also suspect the problem is insidious, in that the accuracy issues might tend to equalize over the course of a fill. Tracking fills is the traditional way to calibrate a SG. Therefore certain kinds of accuracy problems might be concealed. An instantaneous reading, or a trip-based reading, might be wrong, even though we see good accuracy on a fill-to-fill basis. Therefore I suspect some people might feel confident that they are looking at accurate readings, even though the confidence is misplaced.

But I don't want to overstate the point, since it's far better than what most people have (nothing), and the accuracy problems are probably relatively insignificant for most people, most of the time. And being aware of open-loop vs closed-loop will probably help a lot.

Anyway, I see various smart people (like you folks) trying to tackle these issues in new ways, so I'm hopeful that a lot of the mysteries will start getting solved.