Quote:
Originally Posted by t vago
Yah, that was one of the first things I noticed with the existing 0.86 MPGuino code, and one of the first things I canned by having the system timer take care of doing timing and having the main loop just poll a status flag to see if the loop had completed.
|
Excellent work. I always thought the original code was very ham-fisted.
Quote:
Originally Posted by t vago
The first three trip variables can be treated exactly as the current or tank trip variables. You can get the total period, which corresponds to either 0-30 time, 0-60 time, or 1/4 mile time.
|
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 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.
Quote:
|
The fourth trip variable is special, as it actually does capture the instantaneous vehicle speed when the 1/4 mile marker is reached.
|
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.
I believe your approach will work, but real-world driving may result in eco acceleration runs having minor dips in speed, causing early termination of the run. 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.