Tested: The Most Efficient Way To Accelerate With An Automatic (Toyota Matrix)

[Arragonis]

Originally Posted by christofoo

Am I wrong in believing the OBD-based-MPG-gauges are calculating fuel rate primarily from the MAF sensor? OBD-II PIDs - Wikipedia, the free encyclopedia.

Possibly - you may be right or wrong.

My point is that the SG2 is pulling the data from the OBD port at regular intervals, so if you acclerate fast and it has fewer data points to average from, accelerate slowly and it can more or less log every change and be more accurate.

IMHO based on this idea I suspect the overall result between fast and slow acceleration is equal in terms of real fuel cost.

The real way to test this is to top the tank from a can, do some runs with sharp accel, top it again and measure the fuel used. Then top it off and repeat with slow accel for the same number of runs on the same circuit.

Otherwise this data doesn't really mean much IMHO.

[MetroMPG]

Originally Posted by Arragonis

My point is that the SG2 is pulling the data from the OBD port at regular intervals, so if you acclerate fast and it has fewer data points to average from, accelerate slowly and it can more or less log every change and be more accurate.

Confirmed by Linear Logic just now:

The RATE adjustment is both for the ScanGauge display update, and the sampling rate.

Accelerating slower would give a more accurate average based on having more data points to compute the average with.

Also note: RATE is user-configurable to update "Fast" about every half second, compared to "Normal" about once per second. "Normal" is the default rate, and it resets to that every time the SG goes to sleep (on my release).

[mechman600]

Mine is set to "Fast". If the screen refresh rate is the same as the actual data sample rate, that's about one sample per second.

[pgfpro]

Normal sample rates for todays ecu's are over 1000 per second.

[Arragonis]

Originally Posted by Linear Logic via MetroMPG

Accelerating slower would give a more accurate average based on having more data points to compute the average with.

This is what I meant.

[Arragonis]

Originally Posted by pgfpro

Normal sample rates for todays ecu's are over 1000 per second.

Do you have a source for that ? I think you are right but I would like to know. I remember reading stuff about ECUs in the late 80s and the computers even then (8bit "industrial" CPUs) had to be underclocked to even know that an engine was connected.

The on board displays are just as bad - the one in Hermann is hopelessly optimistic by as much as 10% more or less all the time.

[mechman600]

Originally Posted by pgfpro

Normal sample rates for todays ecu's are over 1000 per second.

Everyone here knows/assumes that. But we are not talking about ECU sample rates at all. We are talking about ScanGauge sample rates, which seems to be one per second.

[Arragonis]

Originally Posted by mechman600

Everyone here knows/assumes that. But we are not talking about ECU sample rates at all. We are talking about ScanGauge sample rates, which seems to be one per second.

With respect you are confusing the rate at which the SG2 refreshes it's display with the rate at which it samples data behind the scenes.

[mechman600]

Originally Posted by Arragonis

With respect you are confusing the rate at which the SG2 refreshes it's display with the rate at which it samples data behind the scenes.

Are they not the same? I cannot find any published information about display vs data sampling rates.

I assumed by your original argument that the data sampling rate also must be quite slow if it is inaccurate during fast acceleration.

[leafvillage]

Awesome information! I will have to look and see how this reflects in my Auto CRZ