high speed wheel speed sensing

looking at sensing wheel speed on a motorcycle and logging it, I'm new to Arduino. there is a disc mounted on the wheel that gives around 100 pulses per revolution that allows great resolution for wheel speed. doing some quick math I'm not sure if Arduino is up to it. any thoughts?

thanks

The number of pulses per revolution is a meaningless value, without knowing how many revolutions per second/minute/hour/week you are talking about.

How does the disc generate pulses? Pulses are electrical in nature. The disc sounds mechanical, like a brake rotor or pulley.

What is your math showing? Here's mine:
60 mph = 88 ft/second
16" diameter wheel, 8" radius, circumference = 2PiR = ~37.3"
88/37.3 => 235 pulses per second at 60mph

1/235 = ~4.25mS between pulse edges, about 68,000 clock cycles to do stuff - what is your plan?

16" diameter wheel, 8" radius, circumference = 2PiR = ~37.3"

The way I work this equation, I come out with the fact that your calculator needs new batteries. :slight_smile:

well.. the speed can be close to 200 mph, but for fun we will go with 160 (have hit 190 at Daytona) the tire travels 5.3 feet per revolution, I promise I will do more math as it becomes possible that it can be logged and dealt with as far as data, the system I use now I will try and pick apart the sample rates and such, it logs wheel speed (front and rear).. throttle position, suspension travel (front and rear although rear not necessary at this point)

thanks

D

Ah ha, you are right! I think I used 7/3 for Pi instead of 22/7.
The scientific calculator in WinVista doesn't have Pi button.

I take that back, I am just going blind - has a little 'pi' in the bottom middle, I was looking for a symbol.

The issue of what is sending the pulses still needs to be addressed. If it is some kind of whole in the disc that allows light through, is it possible to block some of the wholes? If only every 10th hole was open, the pulses would be only 10% as frequent.

The scientific calculator in WinVista doesn't have Pi button.

I take that back, I am just going blind - has a little 'pi' in the bottom middle, I was looking for a symbol.

You'll be happy to know that in Win7, the button has the pi symbol on it. Though the symbol is awfully small.

a hall effect sensor would be used, the resolution of sensing is crucial in the next phase of the project. The ultimate is to use front and rear wheel speeds versus throttle position adding a factor of suspension travel and maybe even a accelerometer to show lean angle to work some algorithm and adjust some type of parameter of the bike to adjust power output (traction control).. a huge project I know... but at least being able to log the data would be a great start. there are many systems that do this, but the arduino seems to be a fun platform and a great community for it

thanks

D

but at least being able to log the data would be a great start.

Using a hall effect sensor, connected to an interrupt pin, with an ISR that just counts pulses is easy. The time-consuming part is logging the data. The more often you log the data, the less data to log each time, but the larger the file becomes, slowing logging speed.

Is it possible to use something like a XBee (pro, probably) to simply transmit the data, and let a PC log it? PCs can log data far faster than the Arduino can, plus it could be viewed in real time, instead of later.

it will need to be logged on-bike due to distances.. using an SD or something of the sort is not a problem... wheel speed with the rates that are used seem to be the least of the storage problems... the suspension travel seems to be the task.. but lets log wheel speed first...

it will need to be logged on-bike due to distances.

What kind of distances? There are some pretty long range XBees.
http://www.digi.com/products/wireless/long-range-multipoint/xtend-module.jsp#overview

Up to 40 miles

wheel speed with the rates that are used seem to be the least of the storage problems

It's not the amount of data being stored that is the issue. The SD card writing functions are not known for their speed at locating the proper place in the file to write to. Each write is completely independent of any other write. The library does not track where it last wrote to, so each write requires a new search for the end of the file.

The SD card writing functions are not known for their speed

Log to some form of NV RAM, battery-backed SRAM, Magnetosresitive RAM etc. No speed issues there.

16" diameter wheel

That's a pretty small motorbike wheel, 30+" would be more normal.


Rob

Well, 16" is what's on my car, it was just a number in a formula to get an idea of the # of pulses to deal with.

well, the front is smaller in diameter, but i measured a read tire and its Circumference is 77.750

here is an example of how wheel speed is being sensed by some.
http://hubpages.com/hub/The-motorcycle-traction-control-system

They write for hours at 10Mb/sec.

It is the Arduino that is not known for its speed.

Actually, in this case, at least, it is the SD card library that is not known for speed. Look at how the library finds where on the card to actually write the data. Once the write completes, that location information goes out of scope. So, the next write operation starts all over again looking for where to write data.

I presume that this is not the case with your camera.

"5.3 feet per revolution" (63.6")
"measured a read [rear] tire and its Circumference is 77.750"

Lot of variation there. Doesn't matter, size can be entered by the user as part of calibrating the program.
Anyway, "160mph for fun":

160 mph = ~235 ft/second
77.75" circumference wheel = 6.48 ft
235/6.5 => 36 pulses per revolution at 160mph. You said you were getting 100 pulses/rev, so there are 3 or 4 triggers for the sensor?

So you plan to do something like interrupt on every pulse, read millis() or microseconds() and store the unsigned long data (along with ?? shock compression, lean angle, throttle position, brake handle squeeze?) while waiting the next interrupt?

Well, 16" is what's on my car, it was just a number in a formula to get an idea of the # of pulses to deal with.

I'd suggest they're 16" rims not 16" wheels or you have a tiny car :smiley:

lets focus on the problem not the wheel size as much, the OD is 77.75" every revolution I would like 100 pulses (if this is too much I can reduce the number of "teeth" the hall effect counts) I guess I'm hearing some concern for writing to SD memory? what other alternatives are there?

Thanks

DD

It sounds like SD can work if you use the right technique, otherwise, as I said

Log to some form of NV RAM, battery-backed SRAM, Magnetosresitive RAM etc. No speed issues there.


Rob