Scanguage vs MPGuino - 96 Prizm

[justjohn]

Aye, that's what I'm expecting. I want to compare different methods of acceleration, and I don't want to hit open loop without the penalty being registered.

I'm also hoping to be able to see when I hit open loop so that I can go just under that point for one of the tests.

P.S.
A hole or two if I want to mount it in the dash, no? Although I did see a setup with the wire coming up to a little mounted box on on the dash that didn't look too bad.

[dcb]

The extra data provided by an obd tool (i.e. scangauge) like rpm, throttle position, load, and open loop indicator would be helpful if you want to monitor those items.

the guino can only sense the injector pulse width and the speed (distance) sensor and the 4th dimension. and is oblivious to the concept of open loop, unless it is marked by a large change in consumption that the user can notice.

[justjohn]

Right. Ideally I suppose I would have both. I need the guino for more accurate measurement while in open loop though.

I used the word hope precisely because of what you said. I'll only be able to see it if there's a distinct jump. That's alright with me for now though.

[dcb]

it is always challenging to measure best acceleration, cuz things are happening so fast.

One part of the problem is how do you compare the efficiency of two acceleration profiles?

Assuming you are going to run several tests and take an average, do you compare fuel consumption for:
a. just accelerating up to a given speed at different rates?

b. accelerating on a fixed distance up to a a given speed and holding that speed for the remainder of the distance (so you measure fuel used over a given distance in all tests)?

c. require that slower acceleration exceed the given speed so that they finish the same distance in the same amount of time?

d. etc. etc.

I would like to see a "best acceleration for a given amount of fuel" indication, i.e. change in speed/fuel used. that might help, but would be affected by things like hills and wind. maybe if you have an average figure from the last 3 seconds and an instant figure it would be driveable. And you just adjust the throttle (or even the gear shifts) to seek the most fuel efficient acceleration.

It may be something you can do with an xgauge on a sg (and you can see if best accell peaks below open loop then), I'm sure a guino could be hacked to do it too with an external programmer and a knowledge of programming atmegas. I may have to think about adding that to the official version.

[justjohn]

Yes, I thought it through briefly beforehand and I was planning on doing b, as that seems the most fair. (It should be change in speed per fuel used, but with distance covered factored in so that slow modes don't come out falsely disadvantaged)

My rough plan was to try 4 modes of acceleration (just slow medium brisk and full, nothing fancy to start with) to a specific speed, both ways on a short course and compare. Probably another couple sets at different speeds.

[automd]

Originally Posted by Daox

I'd go for the scangauge. The mpguino is great for preOBDII, but the SG just has so many more features.

Accuracy can be tweaked pretty close, but you really just need to get a baseline. From the baseline you can tell if you are doing better or worse.

Scangauge. We're in the same side. I totally agree. I can't say more. Be sure to check if your car is OBD compliant

[jfitzpat]

Forgive me, I'm trying to thread a needle. The important part of the post is the principles, but it will sound like a sales pitch and that is not my intent. There are lots of ways to get the job done, I just happen to be familiar with our stuff.

First, it is important to understand why OBD-II MPG is inaccurate. I cover a bit of it here:

http://ecomodder.com/forum/156981-post21.html

The fundemental problem is that the unit doesn't typically know what the lambda, or AFR, of combustion is. This is 14.7:1 (really lambda 1.0, which is not quite the same thing), a lot, but not always, and it can depend on even the route being driven.

So, when you are calibrating such a unit, you are not just adjusting for sensors, but also for driving style and typical routes and terrain. If you are trying different driving styles, then your calibration becomes moot.

So, from a strict instrumentation standpoint, measuring injector duty cycle is much more accurate for comparative purposes. It also has to be calibrated, because of the mechanical properties of the injector, but even without calibration, comparisons of readings have merit.

Second, instantaneous readings are not a very good way to make meaningful comparisons, at least not when gauging small changes.

I'm not saying that such devices aren't useful, but the instant reading and the actual results are two different things. For example, and instant reading will reward any decrease in TP, but if you are going up an incline, this is not the most fuel efficient way to operate.

I think that when you are trying to make comparisons, logging and post operation analysis is the way to go. That's how we do it in performance operations. You are really interested in the total result, not instant by instant readings. Also, logging lets you focus on executing the techniques.

If I were going to try to collect data for quantitive comparisons, I'd start by logging OBD-II data (like I did in the post above). This is nice because it lets me also review the consistancy of execution of the technique as well as measure the fuel results.

If my need for fuel consumption accuracy was fairly precise, I'd add a wideband O2 setup. In the case above, I'd put the wideband in the pre-cat bung for the regular O2 sensor, then have the wideband controller simulate narrow band output for the ECU. This would save me installing a new bung. Then I'd chain that through the OBD-II module so that the wideband data is logged in sync with OBD-II data.

Wideband + MAF is pretty accurate for MPG. Plus, it let's me have a glimpse into how much economy is really about the technique, and how much is ECU specific behavior.

If that precision is not enough (limited by ECU response rate), I'd wire up injector duty cycle as well to a little analog/clock input module and chain it in as well.

For 'real time' monitoring, I might wire up a gauge (there is a serial output as well as USB/Wi-Fi), but you get the idea...

Now, again, none of this meant to sell gear. I bet it would be easy to apply the same principles to something like the MPGGuino. My points are ultimately just:

1. Understand that OBD-II is generally only air side monitoring, so different technique throws off precision

2. Meaningful evaluation is a lot easier (and I think a lot more accurate) if you log the data and analyze it after the fact.

Regards,
-jjf