MPGuino release one workspace

[americasfuture2k]

ive been out driving all night, comparing different speeds. ive adjusted my VSS Pulses/Mile to 20625. its off by 1.75 mph at 60 mph. any suggestions on how to make this a lil more accurate?

im reading this "If the speed/miles displayed on the mpguino is low then decrease this number by the percentage that it is off and vice versa for high readings", so i need to mutiply 1.75 and 20625 to get my vss pulses? or subtract 1.75 from 20625? i cant subtract a decimal from that number on the mpguino.

[dcb]

Is the mpguino reading high?

If so, then the new number should be 20625 * (61.75/60.00) = 21227

If not, then the new number should be 20625 * (58.25/60.00) = 20023

But it is better to calibrate it with distance, the odo is far more accurate than the speedo usually, and/or next time you are on the hiway a long time use the mile markers to keep your odo honest.

P.S. rmccomiskie, it might help if you record both simultaneously, at cd stereo sampling rate but 8 bit depth. the raw wave format is pretty easy to decypher, don't know about compressed, but having both signals captured at the same time could be something of a rosetta stone for that ECU signal if other VW/Audi groups don't have the answers.

[americasfuture2k]

yes it is reading high. thank you, im going to go test this setting out, then its onto the microsec/gallon and so forth from there.

[americasfuture2k]

@ 60mph, it was pretty accurate. @ 30 mph, it was off by 2.2. and now my instant and current mpg jumped up to 9999999999999999. basically its stuck saying infinite.

[dcb]

sounds like a hardware/firmware issue. try unplugging it for 10 seconds for starters, then try going through the setup values again and seeing if any look totally off, then try reflashing it if that doesn't work, then poke around at the solder joints.

[americasfuture2k]

ADHD interruption.....

have a big MPH and a big instant MPG displayed at the same time? i guess since those both would be displayed at the same time, its would be medium MPH and medium MPG??

[wagonman76]

I calibrate mine from one fillup to the next using the trip odometer. All it takes is once or maybe twice. After that it is dead nuts within .1 miles over 400+ miles, every time. I prefer to keep mine set to the odometer.

As far as real distance, I don't go by mile markers because I have checked some before and found them to vary a bit. Also the only mile markers are on the freeway which not everyone has near them.

What might be a better way to calibrate to real distance is next time you go a considerable distance, check your exact trip according to Yahoo maps or something like that, then see how that compares.

[rmccomiskie]

Originally Posted by yetimus

I'd be very interested to hear if you find a way to use the ECU fuel consumption signal. I'd like to adapt the MPGuino to a VW Passat TDI which has no injector signal available (it's a rotary pump injection system), but it does have an ECU fuel consumption signal similar to yours.

Good luck and keep us posted!

I'm working on it!

[rmccomiskie]

Originally Posted by dcb

P.S. rmccomiskie, it might help if you record both simultaneously, at cd stereo sampling rate but 8 bit depth. the raw wave format is pretty easy to decypher, don't know about compressed, but having both signals captured at the same time could be something of a rosetta stone for that ECU signal if other VW/Audi groups don't have the answers.

OK. I've been capturing single signals so far just because I don't have a good stereo connector. I'll get one of those. The Scope program will display both signals superimposed.

[rmccomiskie]

I spoke too soon. Last night I saw the GPH jump high again while using the injector tapped signal. So, the problem is not solved and it's not unique to the ECU signal. I'm digging deeper into the code now.

To clarify, this may be a problem only with instantgph(). I suspect that when the injector signal goes flatline, the injector temp variables are reset in loop(). Because there are no injector events happening, the inj open/closed routines never run and the variables are not updated from their reset state. The next time through loop(), the reset values are passed to the display routine which calls instantgph(). instantgph() calls div64 with a zero denominator which then returns 0xFFFFFFFF. So, the GPH value displayed is a very large number.

I'm experimenting to confirm that's what's happening.