View Single Post
Old 12-14-2016, 11:35 AM   #40 (permalink)
Join Date: Oct 2016
Location: Seattle, WA
Posts: 69

s2k - '02 Honda s2000
Thanks: 12
Thanked 47 Times in 35 Posts
Originally Posted by t vago View Post
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.

Originally Posted by t vago View Post
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.

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.
  Reply With Quote