speed sensor resoultion

[peaty]

Hello,

I'm trying to determine the resolution of a speed sensor -hall effect- but I'm struggling a bit. The sensor I'm using is the honeywell GT1, the front wheel diameter is 530 and the rear one 570. The range I need to measure is from 0 to 280Kph. The diameter and the number of tooth is to be determine. Can anyone help me out with the math!? I don't remember how to do this -I'm not an electronic/data guy-.

I know I'll be limited by the available space and sensor recommendations, but I'm not interested in that right now. I just want to remember the math behind it. It would be great if we could make an example so that I can see how the process and the math are.
Can anyone help me!?

Cheers

[Greg Locock]

That's more complicated than you think, I think. What do you mean by resolution? In engineering we often talk about precision vs accuracy.

Think about the difference you'd see in 'resolution' with one tooth per rev vs two teeth per rev. Then think about the difference in 'resolution' between two different clock rates.

[peaty]

That's more complicated than you think, I think. What do you mean by resolution? In engineering we often talk about precision vs accuracy.

Think about the difference you'd see in 'resolution' with one tooth per rev vs two teeth per rev. Then think about the difference in 'resolution' between two different clock rates.

Essentially, resolution is the smallest measurement a sensor can reliably indicate. I was given an example year ago where this clearly seen, but I don't find my notes. It depend on different factors, that's why I'm so interested on the math behing it

[R_Redding]

As pointed out ..its wrong to attribute resolution to your sensor , as it has a binary output.. either high or low....It does however have a maximum frequency that it can detect. Resolution will be an attribute of the measuring system.

Were it for me.. the first step I'd make is to calculate the wheel/axle shaft RPM based on the speed and wheel diameter. I'm not going to show this,just in case this is homework ... but I get a figure of 2819.2rpm at 280KpH (assuming that 530 means 530mm).

As the Honeywell GT1 has a maximum frequency of 100kHz , I'd choose a toothed wheel that will give a nice easily converted resolution/granularity for the 0 - 280KpH scale.

Lots of ways to proceed from here ... but a nice granularity would be to have 10 pulses per KpH so at 280KpH the toothed wheel will need to give 2800 pulses per second at 280KpH and it will rotate ~47 times ..so 2800/47 give a 60 tooth gear approximately,just short of 12bit resolution. Higher pulse/bit counts could be used ,but do they need to be?.

Now my electronics only has to count the number of pulses per second and divide by 10 to give the speed. There will be slight errors as 59.6 tooth gears are hard to make.

Rob

[Tim.Wright]

The resolution of a speed sensor like this is not a constant value. It depends on the sampling rate of the acquisition system, the number of teeth and the wheel speed at any instant. What you are actually measuring is not the velocity of the wheel but rather the time period between 2 successive teeth. Then from this the speed is calculated.

In the end the number of teeth will be determined by what you want to use the data for. If you need high resolution for an ABS sensor or you need it to be accurate at low speeds, you need something like this:


If you use it for comparing setup changes on a track car, then 10-15 teeth will do the job.

[peaty]

As pointed out ..its wrong to attribute resolution to your sensor , as it has a binary output.. either high or low....It does however have a maximum frequency that it can detect. Resolution will be an attribute of the measuring system.

Were it for me.. the first step I'd make is to calculate the wheel/axle shaft RPM based on the speed and wheel diameter. I'm not going to show this,just in case this is homework ... but I get a figure of 2819.2rpm at 280KpH (assuming that 530 means 530mm).

As the Honeywell GT1 has a maximum frequency of 100kHz , I'd choose a toothed wheel that will give a nice easily converted resolution/granularity for the 0 - 280KpH scale.

Lots of ways to proceed from here ... but a nice granularity would be to have 10 pulses per KpH so at 280KpH the toothed wheel will need to give 2800 pulses per second at 280KpH and it will rotate ~47 times ..so 2800/47 give a 60 tooth gear approximately,just short of 12bit resolution. Higher pulse/bit counts could be used ,but do they need to be?.

Now my electronics only has to count the number of pulses per second and divide by 10 to give the speed. There will be slight errors as 59.6 tooth gears are hard to make.

Rob

These where the basic math I was trying to apply. Thank you very much! I just didn't get why your example is a short of 12 biits resolution. Another thing is that I didn't understand this:

"Lots of ways to proceed from here ... but a nice granularity would be to have 10 pulses per KpH so at 280KpH the toothed wheel will need to give 2800 pulses per second at 280KpH"

could you please explain it to me!? I just didn't get it!

All these lead to 2 more questions:
1-Error, how can I calculate the error between the real speed and what I'm measuring!?
2-How can I compensate for this error!?


"Higher pulse/bit counts could be used ,but do they need to be?." I need a good resolution because this sensor will be used for a TC.

[peaty]

The resolution of a speed sensor like this is not a constant value. It depends on the sampling rate of the acquisition system, the number of teeth and the wheel speed at any instant. What you are actually measuring is not the velocity of the wheel but rather the time period between 2 successive teeth. Then from this the speed is calculated.

In the end the number of teeth will be determined by what you want to use the data for. If you need high resolution for an ABS sensor or you need it to be accurate at low speeds, you need something like this:
http://c.shld.net/rpx/i/s/pi/mp/26937/p ... n=1&qlt=85

If you use it for comparing setup changes on a track car, then 10-15 teeth will do the job.

I'll use the data for a TC, so I need it to be as accurate as possible!

[hollus]

Is this the same method used to measure speed in F1? The one generating the numbers we get as a telemetry overlay in TV? Measured at the wheel axle?

[langwadt]

As pointed out ..its wrong to attribute resolution to your sensor , as it has a binary output.. either high or low....It does however have a maximum frequency that it can detect. Resolution will be an attribute of the measuring system.

Were it for me.. the first step I'd make is to calculate the wheel/axle shaft RPM based on the speed and wheel diameter. I'm not going to show this,just in case this is homework ... but I get a figure of 2819.2rpm at 280KpH (assuming that 530 means 530mm).

As the Honeywell GT1 has a maximum frequency of 100kHz , I'd choose a toothed wheel that will give a nice easily converted resolution/granularity for the 0 - 280KpH scale.

Lots of ways to proceed from here ... but a nice granularity would be to have 10 pulses per KpH so at 280KpH the toothed wheel will need to give 2800 pulses per second at 280KpH and it will rotate ~47 times ..so 2800/47 give a 60 tooth gear approximately,just short of 12bit resolution. Higher pulse/bit counts could be used ,but do they need to be?.

Now my electronics only has to count the number of pulses per second and divide by 10 to give the speed. There will be slight errors as 59.6 tooth gears are hard to make.

Rob

for such low frequencies you don't want to count pulses per second that'll give you a very slow update rate

you'd want to do the reciprocal, measure the time between pulses and calculate the speed from that

[riff_raff]

As others noted, your sensor arrangement would only measure the passing frequency of the target wheel. This would not provide an accurate measurement of road speed due to factors like loss of tire traction or changes in tire diameter at high speeds.

[jz11]

just a thought - if the OP needs the sensor for traction control purposes, then he may not even need to calculate speed for every wheel and then do comparison - which will take certain amount of time (because of the need to determine specific frequency before math functions), the output of his sensor is essentially a frequency, and you can use high speed frequency comparator circuitry to compare those frequencies and, for instance, get an output of high/low when the difference is detected, voltage level output could even be better, you could sample that on ADC and write your traction control rules around the detected voltage differences