I disagree (again).

It's not counting the pulses.
It's counting the time between pulses.

If the pulse period is 0.46 seconds, then that's how often you can update the display. Each pulse period gives you all the information you need when there's only 1 pulse per rev. With more than one, there would be differences between the pulse widths depending on placement of the sensors/magnets/optical whichever is used, and then you would have to average a number of samples to get the correct result. But with 1 pulse per rev, that does not apply, and a single pulse is all you need.

It would not jump from 5 to 10 kph, and in fact would give a nice linear response with at least 1 decimal.

If the CCP module were being used, and Timer1 extended to 24 bits, the lowest reading you could get would drop to well under 1 KPH. Of course, at 1 kph, the pulse period is 2.2 seconds, and that's how often you can update the display. But at 1kph, you don't need a faster refresh.

There's absolutely no reason why davewanna can't use the sensor that he has, and get excellent readings from 1 to 200 kph.
The car's computer already does it. Why wouldn't the PIC be able to do it too?

He just needs to find out the real distance per pulse.
Which can be done easily by driving the car 1km and have the PIC count how many pulses it received. From there, it's just math.
<br>