Converting period to Miles Per Hour

[Acetronics2]

Oh, belatedly I see this is Alain's suggestion as well. At least he has not yet disappeared over the horizon.

you're a newbee here ... so, you're forgiven !!!

How sad is life without a touch of Humour ...

Alain

[Art]

Write a small program to count pulses, and give yourself a reset button,
go drive a mile. Some places have markers on the road to do this to check speedometer accuracy.
Then you will know in the real world.

[SFOdesigns]

Ok, here's my thoughts, after reviewing all of your (mostly) thoughtful replies:

First of all, I don't want to tie up my processor while a count takes place.
Second, here's what I came up with. Please poke the required number of holes in it.

My tire circumference is 78.4" and I have 5 rotor bolts. so between any two pulses, the tire travels 15.68". If I measure the time it takes to travel 15.68" and multiply it by 4040.82, I should have the mph. I divided 15.68 into 63360, which is the number of inches in a mile.

Does that make sense?

[Tobias]

One thing you might consider, look at mounting your sensor before the rear tire. You will get better resolution. Or make a reluctor wheel attached to the rear tire. For example, when I was doing data acq on race cars, it was normal to detect drive shaft rpm with a four count reluctor wheel on the driveshaft. I mounted the hall effect sensor on the housing of the rear end and counted ring gear teeth to determine drive shaft rpm. I would get 20 pulses per rev compared to 4.

[Art]

I only suggested driving a mile with a counter to determine number of pulses per mile in the real world.
Whatever you calculated the circumference of your inflated tyre.. it's incorrect on the road.
You can take a GPS to measure distance, inflate rear tyre to pressure, and then ride several miles,
divide the total pulses by the number of miles you rode, and that's your number of pulses per mile,
divide that by five and check that against how many times you think the bolts are going to pass right now.

Going back to your first post, you generally either time the interval between each pulse with an interrupt, and make the calculation each pulse,
or you count the number of pulses over a fixed duration. The first option is faster updating, less annoying when you go to
add to your PBP program... once it's working you can virtually forget about it.

When I went to make a vehicle speedometer the second way, I found the vehicle provided such a low number of pulses per second,
that there was no way for the speedo to tell the difference between say 66 and 67 KmPh.
Say I got 8 pulses a second at 60Kmph, I might have taken 65Kmph to get nine pulses.
So I did the speedo with interrupt, and the PBP program was fast enough to catch every tachometer pulse.

First of all, I don't want to tie up my processor while a count takes place.

It's only the second method that potentially ties up the chip, and even then,
that depends on how long the pulse is, as to whether or not you have to sit in a loop waiting for pulses.

[HenrikOlsson]

If I measure the time it takes to travel 15.68" and multiply it by 4040.82, I should have the mph.

Hmm...I don't think so. As the velocity increases the time between any two pulses (ie the time it takes to travel 15.68") decreases so your calculated mph value will decrease as the speed increase....

You can easily count pulses for a set period using one of the timers as a counter and another as a timebase. This would not lock up the processor. To determine the most suitable aproach (or possibly if two different aproaches is needed as outlines earlier) it would be nice to know the answers to the following:

1) What's your desired min/max velocity, and please don't say 0?
2) What kind of resolution do you need?
3) How often must the display update?

/Henrik.