Suggested MPGuino change: average speed

[poindexter]

I've been playing with my newly built MPGuino and thought I could improve on some of the features. I noticed that the mph of the current and tank trips would just trickle down after the car was stopped and even off. I want it to only calculate the average speed while moving. I've attached my suggested code changes.

I removed the "tankHold" variable and replaced it with "sleeping"

The code near "//currentTripResetTimeoutUS" has been changed and is a little cleaner. I also removed what I think are redundant calls to update().

Also changed:
"loopCount++;" -> "if(t.vssPulses) loopCount++;"

These code changes cause the mph average for the current and tank to not include when the vehicle is stopped and the timer on the last screen will only count up when the car is moving.

[dcb]

Interesting, you do not think sitting at a stoplight is part of the average mph?

[poindexter]

Originally Posted by dcb

Interesting, you do not think sitting at a stoplight is part of the average mph?

Before the modification it was counting time non-stop even after the backlight turned off causing the speed to asymptotically approach zero (with the car sitting for a long time). It appears the code intended to stop counting time after the backlight turned off, but that wasn't the case on my car. If it counts time for weeks on end while I'm not using the car, then the average speed it reports to me has no useful information.

I think both options would be good: stop counting at stops and stop counting after display timeout.

Most bicycle computers have the option to not count stops in the average, and that is what I prefer.

[dcb]

I have not experienced the behavior mentioned in your first paragraph. I just performed a test:
1. install latest code
2. go to CPU monitor screen
3. played with brightness button till T=000.20, left on brightness 2
4. confirm LED goes out at about 007.20,
5. pressed brightness button at T007.36
6. T reset to 000.20, the time of the last activity.

Are you able to reproduce this behavior with a fresh copy of the code installed? I'm not sure how you could be seeing this behavior if the engine is off and the car is not moving for more than 7 minutes. The data model tracks fuel used, distance and time, and only time needs to be preserved if the other variables won't be changing, and it is being preserved. How do you reproduce it?

[poindexter]

I just installed http://opengauge.googlecode.com/svn/...no/mpguino.pde and drove around the block (my neighbors must think I'm really weird because I keep doing this).

I confirm that the timer on the CPU screen does stop.

The problem I am seeing is on the "Tank" screen. The MPH drops as expected when I stop the car, but even after the backlight goes out, the tank MPH continues to decline. I probably wasn't as clear as I should have been earlier.

[dcb]

I reread it, It is a little clearer to me now.

The timer on the cpu screen does keep counting, even after timeout. It was kind of a troubleshooting aid so no "stop counting" logic was put in place. The tank mph is based on that, so you should see it start decreasing speed as you slow down and come to a stop. But if you stop more than 7 minutes (or whatever you set it to) then it will reset to the time of last activity at the next sign of activity, no matter how many weeks have gone by (though don't be surprised if you need a jumpstart)

The timeout business is a little tricky, but it is somewhat important so that we do keep track of the time spent at stoplights even (hopefully) with the engine off. Otherwise the time used for the distance traveled for any given trip would be too optimistic. If it takes 10 hours to get from point a to point b, it takes 10 hours.

I don't know exactly why bikes would not track it, but it could be more motivating to see higher mph figures after pedaling your but off, and if that gets you back on your bike then cool

[poindexter]

Just after I posted my last message I realized what was going on. I now expect to see the trip MPH reset to where it was. I tried to go out and verify this but my display is acting a little funny in the cold weather and is fine when I bring it in. Maybe I need to re-hit the solder on the display.