[t vago]

Originally Posted by skybolt

Excellent work. I always thought the original code was very ham-fisted.

MPGuino was (and is) a very good idea, and the original author was really ambitious, with regard to his programming skills.

Originally Posted by skybolt

Are you grabbing both 0-30 and 0-60? I originally had it 0-speed, where speed was configurable as a parameter. Catching both removes the need for a parameter -- the only edge case I can think of is calculating 0-100, which I wouldn't even do. I assume for metric you're taking 0-50kph and 0-100kph, which are typically the values quoted by manufacturers.

I take the parameterized speed value, convert it into a cycle time value equivalent to the speed, then mulitiply that by two to get the cycle time equivalent to 1/2 of the speed. I do something similar to obtain the 1/4 mile equivalent VSS pulse count. These values are used by the accel test function as checkpoints.

Yah, I have both the speed and the distance figures parameterized, mainly because I'm lazy about having to code for separate metric and SAE calculations, and parameterization makes it really easy to convert between SAE and metric. However, removing those two parameters may be better in terms of freeing up EEPROM space. I still have yet to come up with a decent SWEET64 routine that calculates estimated engine power, so I may just re-write my existing accel test functions to remove the parameterization.

Originally Posted by skybolt

I still haven't created a working mpguignio shield (car-to-duino interface, basically two resistors and two zener diodes, with a voltage regulator for full compatibility). Once I've figured out how I messed up so simple a design I'll start in-car testing. My other choice is to simply overwrite my production MPiGuino, but it's a pain to deploy code to that one given the short wires involved, and there are benefits to having a dedicated dev mule that can be hooked up to the car.

I know what you mean. I have my production MPGuino installed in the Magnum, and while it does have a ISP header on it, I still have to take it out and hook it up to a power supply in the house, then use my computer to program it. Meanwhile, I have both an AtMega2560 and a TinkerKit LCD module that serve as development platforms.

Originally Posted by skybolt

Only catching instantaneous at the 1/4 mile causes a problem -- many ecomodders won't keep accelerating all the way to 1/4 mile, nor do I when the 1/4 mile time approaches 100mph and I'm testing on a freeway on-ramp. 0-60 is relatively safe and perfectly legal (in a 60mph zone). We don't want to capture end speed if it's less than maximum speed during the run. I'd originally solved this by taking updating trap_speed with MAX(speed, trap_speed), but as I recall you terminate the run when the speed begins to drop.

Actually, the accel test function cancels on speed only when speed drops down to zero and stays at zero for 1/2 a second. The accel test function also cancels when it senses the engine is no longer running, or if the user cancels the accel test.

The code is not sophisticated enough to detect momentary dips in vehicle speed.

Originally Posted by skybolt

Once I have in-car testing running I will report. Slow shifting in particular can cause a loss of at least 1 mph. I expect to be able to cobble together, today, a breadboard version of a working car-to-duino interface. I've already verified I can push JSON from the new code to my in-car display unit, so in-car testing will be very full-featured.

Cool! Looking forward to seeing more video of your display. I am thinking of adding something like that to my truck, using a rear view mirror with a built-in backup camera screen.

I just hunted down two very subtle bugs that I think got exposed when I did some of my major re-writing to support using JSON as a primary output (such as for editing parameters). One of them caused the primary LCD screen to quit updating upon meeting certain input conditions, and the other caused the big number display to not output correctly. Hopefully, will have the estimated power routine written. Will also have to provide a modified time function that outputs in 1/10 seconds, but that should be very easy to code.