Quote:
Originally Posted by dcb
Have you been able to dial in the trip distance?
I've noticed that the trip on the metro seems pretty accurate despite the jumpy instant speed reading, which means it is getting most/all of the vss pulses anyway.
The cheap fix is to skip the timing of the vss pulses and just compute "instant" speed based on last few seconds worth of pulses instead of the last .5 seconds worth.
|
Do we make a change in here:
unsigned long instantmph(){
cli();
unsigned long vssPulseTimeuS = (lastVSS1 + lastVSS2) / 2;
sei();
init64(tmp1,0,1000000000ul);
init64(tmp2,0,parms[vssPulsesPerMileIdx]);
div64(tmp1,tmp2);
init64(tmp2,0,3600);
mul64(tmp1,tmp2);
init64(tmp2,0,vssPulseTimeuS);
div64(tmp1,tmp2);
return tmp1[1];
}
unsigned long instantmpg(){
cli();
unsigned long vssPulseTimeuS = (lastVSS1 + lastVSS2) / 2;
sei();
init64(tmp1,0,1000000000ul);
init64(tmp2,0,parms[vssPulsesPerMileIdx]);
div64(tmp1,tmp2);
init64(tmp2,0,3600);
mul64(tmp1,tmp2);
init64(tmp2,0,vssPulseTimeuS);
div64(tmp1,tmp2);
// return tmp1[1];
or somewhere else? If it's in here, I've been trying to figure it out but haven't had much success. It kinda looks to me like the second paragraph is doing what the first one describes, I think. I was wondering if the 3600 in the second init64 was where the number would change?
I'll certainly admit that the abstract thought processes used in programing aren't my strong point, if it were I wouldn't be getting greasy and my knuckles beat up working on cars for a living...
Many thanks,
Mark