PDA

View Full Version : Converting period to Miles Per Hour



SFOdesigns
- 26th November 2013, 06:34
Hi,
I'm utilizing the 18F46K22 on a project. I'm using all of the CCP modules for other purposes.

My problem is that I cannot figure out a formula to calculate miles per hour using the period between two positive pulses. The pulses are generated by rotor bolts on a wheel. There are 5 bolts, and the circumference of the wheel is 78.4 inches. It seems to me that there should be a formula that will allow me to measure the period using an interrupt driven routine, and the calculate miles per hour. But I don't know how.

Can someone help? I'm using PicBasic Pro.

Roy

Acetronics2
- 26th November 2013, 07:28
Hi, Roy

1 wheel turn = 78.4 inches ... 5 bolts per turn

15.68 inches per pulse

1 mile is 63360 inches ... = 4040.816 pulses ( or 1 034 449 / 256 ... )

Done.

BTW ... does PBP Silver edition support the 46K22 ??? :rolleyes:

Alain

Amoque
- 26th November 2013, 14:20
Adding to Alain's expert analysis of distance.

RATE * TIME = DISTANCE, so... If 1 rotation takes 1 second then:

78.4 inches per second * 60 seconds = 4704 inches per minute. Multiply by 60 minutes to find distance per hour = 282,240 inches per hour or (dividing by 63,360 inches in one mile) = 4.45 MPH.

-OR-

[INCHES PER SECOND] * 3600 / 63360 = MPH

The above works only if the inches in one second are known. So, we must also know how to calculate the [INCHES PER SECOND]... Take the example of .4 seconds per rotation:

To calculate the [INCHES PER SECOND] multiply the reciprocal (1/X) of rotation period by the wheel diameter (78.4) to find:
1 / .4 = 2.5 rotations per second. 2.5 rotations (2.5 * 78.4) = 196 inches = [INCHES PER SECOND]. Now, complete the formula above (11.136 MPH) . Not remarkably this is 2.5 times the 4.45 MPH figure calculated for 1 rotation per second - allowing for rounding.


DISCLAIMER: The accuracy of these figures is only as correct as the time base from which they are figured. IE: timer overflow vs atomic clock.

Acetronics2
- 27th November 2013, 10:54
Hi, Amoque

Here we meet the precision problem with reciprocal calculations ....

sooo ... I would suggest, depending on the pulse count or the pulse duration, to choose the value that gives the minimum error to the result.

I.E. ... @ low speed, let's consider pulse duration ( big number gives better resolution ) and @ High speed let's consider the pulse count.

But ... as our "friend" didn't tell what he wants to measure ( snail or car racing ??? :D ) ...

Alain

Amoque
- 27th November 2013, 12:22
Hope is not lost, Alain. He may be back as he left his answer here - only leaving his wallet would motivate him to return more promptly. We need only wait for him to notice then... nab him and we shall have answer!

It may be we may cajole him into revealing where the [leftover] pumpkin pie is hidden as well!

Acetronics2
- 27th November 2013, 13:37
http://sfodesigns.com/aboutsfodesigns.html

that could match the question ... and create some ... :D

Alain

SFOdesigns
- 28th November 2013, 00:31
http://sfodesigns.com/aboutsfodesigns.html

that could match the question ... and create some ... :D

Alain

Hi,

as always, I'm either giving too much information, or not enough....

This is the rear wheel of a motorcycle. The bolts, 5 in all, mount the rear pulley (belt drive) to the wheel. The circumference I provided is an actual measurement with the rider mounted. I realize that tire pressure, load, and temperature all have an effect on circumference, but i'm not that worried.

The speed can reach 100 mph in actual riding.

Thanks,

Roy

Acetronics2
- 28th November 2013, 10:14
Hi,

as always, I'm either giving too much information, or not enough....

This is the rear wheel of a motorcycle. The bolts, 5 in all, mount the rear pulley (belt drive) to the wheel. The circumference I provided is an actual measurement with the rider mounted. I realize that tire pressure, load, and temperature all have an effect on circumference, but i'm not that worried.

The speed can reach 100 mph in actual riding.

Thanks,

Roy

mhhhhh ...

belt driven ??? ...

or it's one of these awful Harleys ... or it's a real vintage lovely one ! ( a steam powered one ??? )

100mph ... a bit over 40k pulses an hour

11, ... Hertz @ Maximum ... then, the pulse duration method is to use.
i'd use some soft dividers switching for the basetime choice vs speed.

the 46K22's Timer 0 looks fine for that purpose ...

But do not ask too much to a Kawa H1 owner ( yesss ... the 3 smoking cylinders !!! ) to do for a ... Harley ...:D

Alain

Amoque
- 28th November 2013, 14:47
I think Alain has digressed to thoughts of wind in his hair and horsepower under his seat... "Write when you find work!" - is an old expression used by my instructors to recall attention when a student's mind drifted away.

More to your concern, Roy: I think that you will want to pick a sample time that yields results near full scale as at high rotations per hour (RPH), small errors will compound quickly. Perhaps you will consider changing the calculation period over different speed ranges as 0 - 10 MPH, 11 - 25, 25 - 50, 50+ (or some such) so that your results don't follow Alain down the path to fantasy :).

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

Acetronics2
- 28th November 2013, 14:55
Oh, belatedly I see this is Alain's suggestion as well. At least he has not yet disappeared over the horizon.

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

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

Alain

Art
- 29th November 2013, 10:00
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
- 1st December 2013, 01:26
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
- 1st December 2013, 07:13
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
- 1st December 2013, 12:34
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
- 1st December 2013, 13:15
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.