## AVR speedometer.

62 posts / 0 new
Author
Message

Hey, im making an AVR speedometer, and i need to see if my math is right.

I have an 8 inch tire. i am going to set a tiny eye up to measure approximately 4 ticks per 1 revolution of the tire.

lets see if i got this right: the circumference of the tire from 8 inch diameter is 25.12inches. meaning the tire would move 25.12 inches in 1 revolution.

in those 25.12 inches, the CPU will measure 4 ticks.

if i divide 25.12 / 4 ticks in one rev. i get 6.28 inches per tick.

here is how i am going to do it:

take the number of ticks the processor gets from the sensor for 1 second. then multiply this by 6.28 (distance per tick).

then i multiply it by 60, to give inches per minute, then multiply again by 60 to give inches per hour.

then take that divide by 12, to get feet per hour. and then take that and divide by 5,280 feet to get miles per hour.

Do i have my math right? or no. it just doesnt seem right. for example if i am going 25 miles per hour, thats 70 ticks per second. that seems kinda fast..

im working on a similar project, well thinking how it works so far. Anyways, from what I have read, division (floating point) operations are very CPU intensive as it doesn't have a floating-point processor, so if you are going to multiply tick's by a number to get inches, why not multiply it by ticks/mile instead?

well im using BASCOM for floating point. so floating point isnt an issue.

i am just wondering if my math is right. because ive had people follow behind me in a car to get my speed and ive went well over 30 with my cart. but the issue is the tire just didnt seem like it would pick up 70 ticks per second. LOL. thats what my math works out to be if you work backwards.

well the carts tires are 8 inches in diameter. that means the cart would travel 25.12 inches in 1 revolution.

but the sensor is setup to pick up 4 ticks per revoultion, meaning thats 6.28 inches per tick. or 25.12 in 4 ticks. hehe.

so from that info, how would i get miles per hour?

distance=rate x time. 30mph=20ft/sec=240in/sec=9.6 tire revs/sec (576 tire rpm), and about 38 sensor tics per sec (4 per rev). You can measure the ms between tics or count how many in an interval of one sec, which ever way is easier. Both use a timer.

Imagecraft compiler user

Try this:

1 MPH = 5280 feet per hour
5280 * 12 = 63360 inches per hour
63360 / 6.28 = 10089.17 ticks per hour
10089.17 / 60 = 168.15 ticks per minute
168.15 / 60 = 2.8 ticks per second

So you get 2.8 ticks per second for every mile an hour you are going.

1 mph = 2.8
2 mph = 5.6
3 mph = 8.4
4 mph = 11.2
5 mph = 14
6 mph = 16.8
7 mph = 19.6
8 mph = 22.4
9 mph = 25.2
10 mph = 28
11 mph = 30.8
12 mph = 33.6

So anything beyond 3 ticks per second and you know you are going at least 1 mph. Anything beyond 6 ticks is at least 2 mph. 9 ticks, 3mph

12 ticks, 4 mph
14 ticks, 5 mph
17 ticks, 6 mph
20 ticks, 7 mph
23 ticks, 8 mph
26 ticks, 9 mph
28 ticks, 10 mph

So if you want speed, just count ticks per second and write code that does this:

IF ticks > 3 THEN speed = 1
IF ticks > 6 THEN speed = 2
IF ticks > 9 THEN speed = 3
IF ticks > 12 THEN speed = 4
IF ticks > 14 THEN speed = 5
IF ticks > 17 THEN speed = 6
IF ticks > 20 THEN speed = 7
IF ticks > 23 THEN speed = 8
IF ticks > 26 THEN speed = 9
IF ticks > 28 THEN speed = 10

No math involved, short and guaranteed to work.

Of course you have to have as many IF/THEN statements as miles per hour you want to measure but I bet it will be a more processor efficient process than doing floating point and it will be just as accurate.

Good luck,

Some Guy

or i could use a for loop. i love that concept. :-) Thanks.

Someguy22 wrote:
Try this:

1 MPH = 5280 feet per hour
5280 * 12 = 63360 inches per hour
63360 / 6.28 = 10089.17 ticks per hour
10089.17 / 60 = 168.15 ticks per minute
168.15 / 60 = 2.8 ticks per second

So you get 2.8 ticks per second for every mile an hour you are going.

1 mph = 2.8
2 mph = 5.6
3 mph = 8.4
4 mph = 11.2
5 mph = 14
6 mph = 16.8
7 mph = 19.6
8 mph = 22.4
9 mph = 25.2
10 mph = 28
11 mph = 30.8
12 mph = 33.6

So anything beyond 3 ticks per second and you know you are going at least 1 mph. Anything beyond 6 ticks is at least 2 mph. 9 ticks, 3mph

12 ticks, 4 mph
14 ticks, 5 mph
17 ticks, 6 mph
20 ticks, 7 mph
23 ticks, 8 mph
26 ticks, 9 mph
28 ticks, 10 mph

So if you want speed, just count ticks per second and write code that does this:

IF ticks > 3 THEN speed = 1
IF ticks > 6 THEN speed = 2
IF ticks > 9 THEN speed = 3
IF ticks > 12 THEN speed = 4
IF ticks > 14 THEN speed = 5
IF ticks > 17 THEN speed = 6
IF ticks > 20 THEN speed = 7
IF ticks > 23 THEN speed = 8
IF ticks > 26 THEN speed = 9
IF ticks > 28 THEN speed = 10

No math involved, short and guaranteed to work.

Of course you have to have as many IF/THEN statements as miles per hour you want to measure but I bet it will be a more processor efficient process than doing floating point and it will be just as accurate.

Good luck,

Some Guy

yea but my sensor is setup to pick up 4 ticks per revolution. How would i plug that into your formula.

mbates14 wrote:
yea but my sensor is setup to pick up 4 ticks per revolution. How would i plug that into your formula.

It's built right in this calculation for the constant when I divide inches per hour by 6.28 inches per tick. See line 3.:

1. 1 MPH = 5280 feet per hour
2. 5280 * 12 = 63360 inches per hour
3. 63360 / 6.28 = 10089.17 ticks per hour
4. 10089.17 / 60 = 168.15 ticks per minute
5. 168.15 / 60 = 2.8 ticks per second

Which you have to trust me on, or calculate yourself when you change the wheel size or ticks per revolution.

bobgardner wrote:
distance=rate x time. 30mph=20ft/sec=240in/sec=9.6 tire revs/sec (576 tire rpm), and about 38 sensor tics per sec (4 per rev). You can measure the ms between tics or count how many in an interval of one sec, which ever way is easier. Both use a timer.

can you expand on your formula a little bit? for example how do you get 30mph into ft/sec?

Someguy22 wrote:
mbates14 wrote:
yea but my sensor is setup to pick up 4 ticks per revolution. How would i plug that into your formula.

It's built right in this calculation for the constant when I divide inches per hour by 6.28 inches per tick. See line 3.:

1. 1 MPH = 5280 feet per hour
2. 5280 * 12 = 63360 inches per hour
3. 63360 / 6.28 = 10089.17 ticks per hour
4. 10089.17 / 60 = 168.15 ticks per minute
5. 168.15 / 60 = 2.8 ticks per second

Which you have to trust me on, or calculate yourself when you change the wheel size or ticks per revolution.

oohhh ok, I see. bare with me, my math skills are about shot. hehehe

For count = 0 to ticks step 3
mph = mph + 1
next

That works. :-)

Which can be calculated using integers as:

```mph=(ticks*357)/1000
```

No floating point ;)

The only catch is that ticks must be < 92 otherwise it will overflow (assuming signed int, unsigned ticks must be < 183)

More efficiently by replacing the division with a shift:

```mph=(ticks*91)>>8;
```

I made a digital speedometer for my car part of a fuel computer which receives 8000 pulses per mile. I measure the time between pulses using Input Capture which is more accurate at these fairly low speeds. I don't like readouts that update only once every 5 seconds ;) And I have seen cars with a digital speedo do that :(

Your analysis is correct. But, why perform two multiplies of 60?

Multiplying 60 x 60 = 3600 so, just perform one multiply by 3600 and save some computation time and FLASH...

Also, 8" x 3.141593 = 25.132741", which will only be a small amount more accurate but, none the less, more accurate. You did not specify your end application so, that minute accuracy difference may not matter.

But, as the tire diameter and Pi are both constants, and, as you already know that you are going to use 4 ticks per revolution, 25.132741" / 4 = 6.283185", 6.283185" can simply be a constant, as well.

Not that it matters but... Oddly, 6.283185" = 2 x Pi and is directly related to radians! So, you could also express the rotational data as radians per second, radians per minute and, radians per hour.

Now your equation becomes:

```      Ticks * 6.283185"
MPH = ----------------- * 3600S
12"
```

Generally, if the sample period was over a 1 second interval and you accumulated 4 ticks:

```      4 Ticks * 6.283185"
MPH = ------------------- * 3600S = 1.427996MPH
12"
```

But:

```6.283185" * 3600S
----------------- = 1884.955592 <--- This is a constant...
12"
```

So:

```      Ticks x 1884.955592
MPH = -------------------
5280'
```

So for Integers, if the sample period was over a 1 second interval and you accumulated 4 ticks:

```      4 Ticks x 1884.955592
MPH = --------------------- = 1.427997MPH
5280'
```

If you are going to use floating point:

```1884.955592
----------- = 0.356999
5280'
```

So here:

```MPH = 0.356999 x Ticks
```

If the sample period was over a 1 second interval and you accumulated 4 ticks:

```MPH = 0.356999 x 4 Ticks = 1.427997 MPH
```

Finally:
As all but the sensor Ticks resolve to constants, the sample interval can be recalculated to reflect MPH directly - with out any math calculations at all.

As I chose a 1 second sample interval to determine MPH and, as MPH for a 1 second sample interval = 1.427997 MPH, simply take the ratio of 1 MPH and the 1.427997 MPH value that was calculated in the above examples.

```                 1 MPH
Sample Rate = ------------ = 0.700282 Seconds
1.427997 MPH
```

So, for the direct reading interval method, the time between samples will be 0.700282 seconds. That is, if you use a sample rate of 0.700282 seconds (700.282 miliseconds), the result will be direct reading (in MPH) without any math at all.

Incedentally, this was the very reasom I initially chose a 1 Second sample interval.

I use the direct reading sample interval method in PLC programming quite often in my "Day Job."

Edit:
Please note the formula below that was produced by jayjay. Now compare that to my floating point example above...

jayjay's example formula confirms my example and, my example confirms his formula, as well.

jayjay1974 wrote:
Which can be calculated using integers as:

```mph=(ticks*357)/1000
```

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Why is my post suddenly before Microcarl's one? My post was a reply to his ;)

microcarl wrote:
Your analysis is correct. But, why perform two multiplies of 60?

Multiplying 60 x 60 = 3600 so, just perform one multiply by 3600 and save some computation time and FLASH...

Also, 8" x 3.141593 = 25.132741", which will only be a small amount more accurate but, none the less, more accurate. You did not specify your end application so, that minute accuracy difference may not matter.

But, as the tire diameter and Pi are both constants, and, as you already know that you are going to use 4 ticks per revolution, 25.132741" / 4 = 6.283185", 6.283185" can simply be a constant, as well.

Not that it matters but... Oddly, 6.283185" = 2 x Pi and is directly related to radians! So, you could also express the rotational data as radians per second, radians per minute and, radians per hour.

Now your equation becomes:

```      Ticks * 6.283185"
MPH = ----------------- * 3600S
12"
```

Generally, if the sample period was over a 1 second interval and you accumulated 4 ticks:

```      4 Ticks * 6.283185"
MPH = ------------------- * 3600S = 1.427996MPH
12"
```

But:

```6.283185" * 3600S
----------------- = 1884.955592 <--- This is a constant...
12"
```

So:

```      Ticks x 1884.955592
MPH = -------------------
5280'
```

So for Integers, if the sample period was over a 1 second interval and you accumulated 4 ticks:

```      4 Ticks x 1884.955592
MPH = --------------------- = 1.427997MPH
5280'
```

If you are going to use floating point:

```1884.955592
----------- = 0.356999
5280'
```

So here:

```MPH = 0.356999 x Ticks
```

If the sample period was over a 1 second interval and you accumulated 4 ticks:

```MPH = 0.356999 x 4 Ticks = 1.427997 MPH
```

Finally:
As all but the sensor Ticks resolve to constants, the sample interval can be recalculated to reflect MPH directly - with out any math calculations at all.

As I chose a 1 second sample interval to determine MPH and, as MPH for a 1 second sample interval = 1.427997 MPH, simply take the ratio of 1 MPH and the 1.427997 MPH value that was calculated in the above examples.

```                 1 MPH
Sample Rate = ------------ = 0.700282 Seconds
1.427997 MPH
```

So, for the direct reading interval method, the time between samples will be 0.700282 seconds. That is, if you use a sample rate of 0.700282 seconds (700.282 miliseconds), the result will be direct reading (in MPH) without any math at all.

Incedentally, this was the very reasom I initially chose a 1 Second sample interval.

I use the direct reading sample interval method in PLC programming quite often in my "Day Job."

Edit:
Please note the formula below that was produced by jayjay. Now compare that to my floating point example above...

jayjay's example formula confirms my example and, my example confirms his formula, as well.

jayjay1974 wrote:
Which can be calculated using integers as:

```mph=(ticks*357)/1000
```

Wholy crud. thats WAY over my head. LOL. its been so long.

```      4 Ticks * 6.283185"
MPH = ------------------- * 3600S = 1.427996MPH
12"
```

I cant get the same answer. i must be putting it in the calculator wrong or something.

oh BTW, its for a golf cart. im building an instrument panel to go above the cupholders.

It becomes even more complicated when you measure the interval between ticks using ICP. Then you get higher values the slower the speed and vice versa, and usually bigger numbers. So you need to divide a constant by the interval time to get to a frequency. And the input capture only captures the current count value, you have to subtract the previous reading and account for overflows too :D

And it all boils down to a simple division of a constant by a measured time :D

Quote:

lets see if i got this right: the circumference of the tire from 8 inch diameter is 25.12inches. meaning the tire would move 25.12 inches in 1 revolution.

Now that you've computed everything to many decimal places, in practice you [probably] will need to calibrate the actual device and tweak the numerator/denominator, just as with a bicycle "computer". Nominal diameter is fine, but under load there may be some compression. So you find a level spot and move the machine for, say, 100 revolutions and measure the distance. A drive wheel can also have slippage (e.g., tractor).

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

well this is a golf car that is used in a camping RV resort thats driven on the park streets.

What do you output to? Needle? LED display? LCD display? Might be cool to also have a watt meter or batt charge meter. Does the phrase Peukert Effect ring a bell?

Imagecraft compiler user

http://en.wikipedia.org/wiki/Peukert%27s_law

Seems like a fun and useful addition :)

jayjay1974 wrote:
Why is my post suddenly before Microcarl's one? My post was a reply to his ;)

Because I have the magic!

Seriously, after I made the initial post, I didn't like what I wrote. So, I pulled it off of the thread to re-work the thing by selecting all, cutting, and then deleating my original post. You must have read it just before I pulled it, and then posted your response after I pulled it

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

theusch wrote:
Now that you've computed everything to many decimal places...

Lee

Well, I have my trusty HP calculator set to 6 decimal places. I was just too lazy to change it. But then, I guess I was much less lazy taking the time entering all of those decimal digits.

Does that even make sense?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

It is certainly good to go through the calcs and see how close you can get with integer ratios, etc.

The point I was making is "premature optimization is folly", or GIGO, or something like that--an inflated rubber wheel/tire will compress under its working load, and perhaps slip. You can do the "static" calculations to a whole bunch of decimal places, but you are going to find yourself much farther off that you thought.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

theusch wrote:
It is certainly good to go through the calcs and see how close you can get with integer ratios, etc.

The point I was making is "premature optimization is folly", or GIGO, or something like that--an inflated rubber wheel/tire will compress under its working load, and perhaps slip. You can do the "static" calculations to a whole bunch of decimal places, but you are going to find yourself much farther off that you thought.

Lee

I agree! At the time, I didn't know what the application was. In the past, and at work, all of the diameters of spur gears and pulleys are fixed (not like a bicycle tire or golf cart tire) and precision to about 4 or 5 decimal places is the norm.

While your statement about the folley of using greater accuracy then you need is true, when dealing with conveyors, where millians of items (beer can) travel on them per day, a few thousands of an inch error greately adds up over hours, days weeks and years. So, if that conveyor is running say, a half FPM (foot per minute) slower than what is thought, and that conveyor sets the pase for the entire rate of the line, that will add up to a lot product loss over time.

I think you and I have had this discussion before in the past, regarding a thread involving Trigonometry issues. :wink:

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

ok. i went to the campsite and measured my tires. they are actually 18" tires with 8" rims. hell i thought they were 8 inch tires, well i thought wrong.

so they are 18inch tires.

let me see if i got this right.

18" = 56.52" circumference.

14.13 inches per tick. 4 ticks per rev.

so 14.13 * 3600S / 12 is 4239

4239 / 5280 = .803

so that means .803 x 4 ticks = 3.212MPH?

or (ticks * 803)/1000?

just making sure i have this right.

bobgardner wrote:
What do you output to? Needle? LED display? LCD display? Might be cool to also have a watt meter or batt charge meter. Does the phrase Peukert Effect ring a bell?

a 2 digit blue LED display. inside an old speedometer case. it has a 5 digit VFD right below that which contains my odometer. its going in the dash just above the cupholders.

i dont give a rats a** about the battery, its a petrol cart. 2 cyl.

im adding a 4x20 VFD right next to it thats going to display the clock, engine RPMs, fuel level, and battery voltage. i need to tap off the engines hall-effect for the RPM since its electronic egnition.

now my next problem is the sensor on the tire. im thinking about epoxying 4 magnets on the backside of the rim, and using a hall-effect sensor i have here. the problem is the hall effect sensors range is REALLY short, i mean the sensor has to be a quarter of an inch away from the magnet before it looses "sight" of the magnet. the issue there is, that means my mount between the rim and sensor cant shift. if it does, it could literally smack the sensor or magnet off. oops.

any ideas?

Can you mount the magnets off of the drive shaft? If you can figure out how to mount the sensor where the drive shaft and sensor are a stable distance (relative to each other) that would solve that problem.

If the vehicle is not front wheel drive, some re-calculation will be needed to compensate for the reduction on the rear axle.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

no its a golf cart. an ordinary EZ-go golf car. it has a CVT transmission, which is nothing more than a drive clutch, a driven clutch on the rear gearbox, and a belt between the two.

the front wheels are on nothing more than a berring and a tie-rod to the steering box. to steer it.

what i could do is mount A magnet on the back of the gearbox driven clutch where the belt goes, and then use a gear ratio calculation. I THINK the gear ratio is 4 to 1. i think, i dont exactly know. if it was 4 to one, would that mean i do the basic miles per hour calculation then divide by 4?

At this school I went to some of the students were building an experimental aircraft using wood construction and they were worried about the volumetric size of the disposable containers they were using for measuring out the glue ( it wasn't a straight 50-50 mix) so one student ( he was chinese and good at math)spent a whole day trying to determine the actual volume by measuring and doing some fancy math.

After some time,another student(not so bright but getting impatient) just poured in some water and put it into a measuring cup and came up with the answer.

mbates14 wrote:
what i could do is mount A magnet on the back of the gearbox driven clutch where the belt goes, and then use a gear ratio calculation.

Isn't that really along the same lines as planting everything at a drive shaft? The whole point of my previous post was simply to suggest that both, the magnets, as well as the sensor, be moved to a stable platform - relative to each other.

mbates14 wrote:
I THINK the gear ratio is 4 to 1. i think, i dont exactly know. if it was 4 to one, would that mean i do the basic miles per hour calculation then divide by 4?

If the gear ratio really is 4:1, just mount one magnet to the pulley. It will be the same as though you mounted 4 magnets to the circumference of the wheel.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

i talked to an EZ-go dealer, he said the rear-end is 12.25:1

so i assume this means the pulley will spin 12.25 times for one tire revolution.

Even being 10 years late in this conversation, this is why I love to do speed math in metric system... hehe.

Wagner Lipnharski
Orlando Florida USA

Well even ten years later, only 17/64ths of Americans understand the metric system.

So did you catch this, up near the top?

"Anyways, from what I have read, division (floating point) operations are very CPU intensive as it doesn't have a floating-point processor"

to which the answer was:

"well im using BASCOM for floating point. so floating point isnt an issue. "

Quebracho seems to be the hardest wood.

im adding a 4x20 VFD right next to it thats going to display the clock, engine RPMs, fuel level, and battery voltage.    plus the original question about measuring the cart's speed...

Given the difficulties encountered with the conversion of tire rotation to MPH, one wonders how he got along with the rest of the project...

"well im using BASCOM for floating point. so floating point isnt an issue. "

Well, I got a laugh out of that.

I'll ignore the slam on Basic programmers, however, , and just note that for a micro running at 16 MHz, and the typical update time for a human readable display, there is time for lots of FP math..., (regardless of the underlying language within which it is programmed)!

I guess the difference between 10 years ago and now is that these days the first reply would likely have been along the lines of:

"Isn't there already an Arduino library for that? !"

JC

I have never thought about an automobile speedometer.

A cycle computer just has a single pulse per wheel rotation.

You measure the time between pulses to calculate the rotation speed.  Hence MPH or KPH from the wheel circumference.

In practice,  you process the results for the display.   A human likes to see steady numbers.

But you can calculate stop / start, journey time,  journey average speed, max speed, ...

Cycle computers tend to do all this on a single CR2032 coin cell.    And have several thousand miles of battery life.

So processing power or speed is not much of a problem (in a well designed unit)

A golf cart speedo will get faster pulses from its smaller wheel circumference.   Do you really drive at 30 MPH on a golf course?

David.

Last Edited: Wed. Nov 1, 2017 - 11:00 PM

david.prentice wrote:

Do you really drive at 30 MPH on a golf course?

Depends how close it is to happy hour.

Ross McKenzie ValuSoft Melbourne Australia

It's good to hear that you are designing an auto speedometer.  However you will find yourself asking the same question that I do whenever I make an AVR clock radio or MP3 player;  WHY am I doing this?

In the civilized world, every car sold and many of the toy cars sold has a real legally-calibrated speedometer mounted in plain sight on the dashboard that is designed to operate error-free for the life of the car.  Can you do better?  Maybe, for hundreds of hours of development, testing, and calibration time.  How many hours have you spent on this already?

My clock radios use an Arduino Nano dev board, an RDA5807M FM-stereo module, a DS3231 real-time clock, a 320x240 TFT screen, an 18650 Lithium-Ion battery and +5V USB charger board, and a PAM8406 stereo audio amp.   I have a bank of about 30 NeoPixel LEDs that blink fully-off/on in various colors when the setting on the 'egg-timer' has expired.  The LEDs light gradually over the course of about 45 minutes from fully off to fully on to simulate a natural sunrise dawn instead of a buzzing piezo or screaming shock-jock to awaken the user.  And there is a second RDA5807 that scans the RDS text from a dozen stations so that I know what is being played on the other channels.  "Oh boy, the classic rock station is playing Stairway To Heaven again".

And the MP3 player (a DFplayer \$2.50 unit) plugs into a MIDI controller, so that I can play keyboards along with classic rock original recordings and adjust MasterTune, instruments, and effects with potentiometers and touch-screens.  Aside from that and the 50-70 hours that I spent developing it (half of that just to understand the elaborate C++ class construction that was scattered over four files), it's no different from a \$12 eBay MP3 player.  So spending 50 hours to emulate a \$12 MP3 device means I do mid-level microprocessor development work for about 25 cents an hour.  Hire Me!

But seriously, though,  Why are you developing/testing/debugging/troubleshooting/encapsulating a single unit automotive speedometer?   You should consider getting married if you have so much free time.

Realise that this thread had been dead for ten years!

John_A_Brown wrote:

So did you catch this, up near the top?

"Anyways, from what I have read, division (floating point) operations are very CPU intensive as it doesn't have a floating-point processor"

to which the answer was:

"well im using BASCOM for floating point. so floating point isnt an issue. "

Yeah, I guess BASCOM turns on the secret FP processor hidden in every AVR. :)

Anyway, I'm definitely on the side of "use INT math unless you absolutely must use FP".  Even if the INT math has to be 32 bits.  And always work within (and not beyond) the precision of both your input data, and your output requirements (here, displaying MPH in either miles or perhaps tenths of a mile/hour).  That works out to a required math precision of only about 1 part in 100 in the (ancient) OP case.

Kartman wrote:

Pretty much like the content of Simonetta's post.

Simonetta seems to have no concept of what a hobby is, nor of doing stuff as a learning exercise.

Simonetta wrote:

"But seriously, though,  Why are you developing/testing/debugging/troubleshooting/encapsulating a single unit automotive speedometer?   You should consider getting married if you have so much free time."

To be fair, he did say it was for a golf cart. I haven't played golf for about a hundred years, but I'm guessing golf carts don't have speedometers as standard.

Quebracho seems to be the hardest wood.

There's golf carts and then there's GOLF CARTS!

This one looks like it comes pre-instrumented.

This one was in the doorway of a local Costco store, which is a bit like a Walmart store.

They sell food, household items, and this and that.

And cool grown up toys!

Too bad I don't still have my trailer, or I'd have had some explaining to do when I got home!

JC

Last Edited: Thu. Nov 2, 2017 - 03:54 PM

There are golf carts, and then there are GOLF CARTS!

A phone with GPS and speedometer app, let's you have a speedometer on anything, even horses. :)

It all starts with a mental vision.

david.prentice wrote:
Do you really drive at 30 MPH on a golf course?

I'd expect much higher velocities. See e.g. this: http://www.swingmangolf.com/aver... ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

So if you are trying to escape from an angry Golf Professional, you have to drive your golf cart at 150 MPH.
It all sounds rather dangerous.

KitCarlson wrote:
A phone with GPS and speedometer app

but how accurate are they ... ?

Y'all know this is a 10 year old resurrected don't you?

Yes - see #44 ...

EDIT

Perhaps all the banter from #36 on should be split to "Off-topic" ...

Last Edited: Mon. Nov 6, 2017 - 08:57 AM

Resolution to one mile per hour, compares well with my new cars.

GPS gets around errors related to tire diameter variation due to, inflation, wear, loading, and speed. Also, there is tire slip when wet or rough terrain.

It all starts with a mental vision.

Resolution != Accuracy

Surely a GPS speedo just measures localized ds/dt? As long as the difference between x1, y1 and x2, y2 used to determine ds are not a huge distance apart then any error in their true location is immaterial isn't it? The distance measurement itself should be fairly accurate shouldn't it?

So long as the position error is consistent...

Surely a GPS speedo just measures localized ds/dt?

Conceptually, Yes.

In practice, probably not.

Although the GPS uses trilateralization to determine location, at low speeds and therefore short distances traveled between successive measurements, the error of the delta distance, and therefore heading and velocity become significant.

Many GPS units, I think, actually use the Doppler shift in the received signal to measure velocity.

JC

There are GPS speedometers on the market. Custom vehicles like street rods use them for ease of installation, and lack of calibration requirements when changing gear ratios, tire diameters.

It all starts with a mental vision.

The GPS speed on my phone matches quite will with the speedo on my car, and with the cycle computer on my wife's bike.  Within 1 km/h.

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "Read a lot.  Write a lot." "We see a lot of arses on handlebars around here." - [J Ekdahl]