I was thinking about a "speedometer algorithm" this morning, after dissecting a speedometer. You know, add a "spring" component to reduce the speed towards zero, and weigh each pulse evenly and have that as a force input, and the balance would be the actual speed. BUT,
I went for a drive this morning, and watched the speedo more closely than usual, and the needle itself bounces. Like up and down 1mph 4 times a second at 20mph! I realized this is not just warn bushings, but the cable itself and it's sheath, and the junctions/gears, plus reed switch fun on top of all that for the guino.
I also took a look at the ecu circuit, nothing special there as far as I can tell. Just a diode for protection and a voltage divider. I think I realized that this particular car computer doesn't really care about accurate mph at lower speeds. When monitoring the speed value on the obd port, it is really slow to react, doesn't bounce like the mechanical speedo, so they probably just look at a lot of pulses over a longer period of time.
So, we could take that approach too, but I was encouraged by the discovery that keeping track of the maximum pulse length produced fairly consistent results. It may be that we add another setup parameter to compensate for the "slop", i.e. 1.6 (or 1600) for the metro. This would not be a memory or computationally expensive thing. Hopefully the "slop" isn't too speed sensitive
