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.

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.

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.

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.

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?

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 :(

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:

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...

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:

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...

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

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.

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

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.

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

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.

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

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.

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

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:

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.

"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.

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]

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?

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.