Using Reed Switch to Measure Bicycle's Velocity
kotsos
Posts: 12
Hello Everyone,
I want to use a Propeller to measure the velocity of a bicycle using a Reed switch
I've been trying to find a counter module that will measure how many times the switch was ON over a specified duration.
I was using the COUNT function from the "BS2 Functions Library Object". However I get inconsistent values.
Basically, I am using a tact switch to send rising pulses to the propeller, but the COUNTER function returns values over a range of +/- 5 per click.
Is the COUNT function supposed to return the precise amount of rising edge pulses measured from a switch?
Do I need some short of filter in the input?
Ideas?
Thank you for your time!
I want to use a Propeller to measure the velocity of a bicycle using a Reed switch
I've been trying to find a counter module that will measure how many times the switch was ON over a specified duration.
I was using the COUNT function from the "BS2 Functions Library Object". However I get inconsistent values.
Basically, I am using a tact switch to send rising pulses to the propeller, but the COUNTER function returns values over a range of +/- 5 per click.
Is the COUNT function supposed to return the precise amount of rising edge pulses measured from a switch?
Do I need some short of filter in the input?
Ideas?
Thank you for your time!
spin
106K
Comments
There are a number of methods to do this.
Question, does your switch have both NO (Normally Open) and NC (Normally Closed) terminals along with the C (Common) terminal.
If you do have both NO and NC terminals you could use 2 Prop pins to positively determine the switch state.
Duane J
BTW, this method (a reed switch) is exactly how bicycle computers (speedometers) work. They are rugged, reliable, and good for millions of cycles. In reality, there's a maximum reasonable RPM for a bike wheel so you could calculate a timeout window to avoid contact bounce.
It does, but they may not quite be what you expect
See the images here
http://www.micahcarrick.com/avr-tutorial-switch-debounce.html
You can see from the image, that you need to avoid the bounce.
This can be done with an external R + C + Schmitt trigger,
or
you can work in the time-domain, and ignore any edges, that occur too close to the triggering original.
or
you can use 2 switches, and a Set-Reset latch which could be a Pin keeper design, or a more conventional SR latch.
On a prop, you can Wait for a Pin-State, then wait for some short time, then wait for Opposite pin state
The wait time is larger than any bounce time, and less than your fastest possible expected pulse rate.
For example, In the COUNT function, I set the duration to 10000 ms and turn the switch on 5 times.
The results I get are in the 100 scale. I assume that there is some scaling that I have to perform. I would assume though, that for digital signals, it would be really easy to get precise count values, especially at so low frequencies.
By the way, the switch I use has only two terminals.
Be a bit careful with the capacitor. Reed switches don't take kindly discharging capacitors as there will be a tiny spark.
You may need to adjust the resistor values.
The capacitor is probably 0.1uF to 1uF or so.
[/QUOTE]BTW, this method (a reed switch) is exactly how bicycle computers (speedometers) work. They are rugged, reliable, and good for millions of cycles. In reality, there's a maximum reasonable RPM for a bike wheel so you could calculate a timeout window to avoid contact bounce.[/QUOTE]
Good point.
Duane J
I was thinking, i am currently using a tact switch which has spring loaded contacts (therefore bouncing) however, does a reed switch cause issues like that?
If I am right, a Reed switch has no spring contacts inside, right?
Otherwise I will have to use a Schmitt trigger
Depends on what you mean by 'spring'
A reed has a torsional arm, that 'snaps over' above a magnetic field level (aka force) and I would call that a spring.
Get your ear close enough, and you can hear it.
- all moving-contact devices will bounce, but reeds tend to have shorter times, due to their lower mass.
You could also look at Hall Switches/sensors. They can be cheaper than Reeds these days, and smaller.
http://www.diodes.com/products/catalog/browse.php?parent-id=110
Or the Infineon TLV4906K etc
the switch mounted on the spokes of the wheel.
My experience with bicycle speedometer devices is this:
No matter what the instructions tell you, Place the magnet as close to the wheel's axle as is possible.
This makes the duration of the switch activated, as long as it can possibly be.
While you may have bouncing troubles on switch make because the Propeller is so fast,
counting the pulse on the falling edge will greatly
increase your chances of success.
If the magnet is close to the axle, the duration of time that the switch is activated should be long enough to have a good
solid contact in it's closed state.
When the switch opens, I don't believe there will be a bouncing happening on open.
I also believe that the BS2 should be fast enough to do this.
That's just my Two Cents worth.
I hope it helps you out.
I am pretty sure that this will remove any bouncing issues since their basis of operation is like that of a transistor.
Thoughts?
One could figure out the maximum possible speed and then a safe delay from that...
It would help you to calculate the revolutions per minute your wheel would travel at about 50 miles/hour
Chances are, you will not travel over that speed, but maybe you are a very fit individual.
When the 1st switch action that will trigger your microcontroller activates, install the delay so that
the wheel is only about 3/4 of the way around to make the switch again.
Make the count at that time.
I believe you will not have miscounting errors using that technique.
Keep in mind, all of the bicycle speedometers I've used, use a reed switch and magnet.
As long as I keep the magnet close to the axle, they always work well.
Mercury wetted reed switches have atiny amount of liquid mercury
that when the contact is made the closure is quite positive.
Sure the read itself still vibrates but the liquid mercury maintains the closure.
This type of switch doesn't need need protection from arcing caused by a capacitor.
Mercury wetted read switches are getting scarce though.
Duane J
Don't waste your time with capacitors. What will fix the debounce problem robustly is to debounce switch transitions in code. Keep a variable which remembers the current state of the switch. This variable is your output to other logic regarding changes in the state of the switch. But when your main loop detects that the switch is in a different state, don't change the output variable immediately; instead, count the number of samples that have disagreed with it. When that count reaches a certain threshold, go ahead and change the output state. If the loop is written in Spin a threshold of 10 will probably work fine with a reed switch.