Reed switch speed sensor Coding question
stevovee
Posts: 18
To give a little background information on my project. I have an electric vehicle that I'm making a speed sensor for. I have picked up an edelbrock qwick data driveshaft speed sensor
http://www.summitracing.com/parts/edl-91196?seid=srese1&gclid=CP786ubbwboCFWxo7AodnAcALg
Edelbrock offers a few different versions of that, some have a hall effect sensor, others a reed switch. The version I have has a reed switch.
My hardware is all hooked up and working well. My questions lies on the coding side of things.
I have considered doing this a few different ways and I wanted to get a few opinions on both options and also if there are more efficient suggestions I would love to hear them.
Method 1) The first way I have considered arriving as speed is a to count the number of high pulses for a given period of time, Then divide pulses by unit of time to get rotations per minute (i will convert to speed later for now I'm only worried about rpms). Each given period of time will be saved into an array and a simple moving average algorithm will be used to get less jerky values (I'm outputting to a gauge stepper motor being used as a speedometer (tachometer for now until I can calibrate for speed later))
Method 2) The second method I am considering is using cnt and recording an array of cnt values where one is recorded everytime a pulse is detected. Then I can use those to find the amount of time in between pulses and use that data to calcualte out RPMs and once again run into a moving average algorithm to speed things up
Which do you think is more efficient, counting time between pulses or number of pulses per given amount of time? Or is there a better way to do this.
http://www.summitracing.com/parts/edl-91196?seid=srese1&gclid=CP786ubbwboCFWxo7AodnAcALg
Edelbrock offers a few different versions of that, some have a hall effect sensor, others a reed switch. The version I have has a reed switch.
My hardware is all hooked up and working well. My questions lies on the coding side of things.
I have considered doing this a few different ways and I wanted to get a few opinions on both options and also if there are more efficient suggestions I would love to hear them.
Method 1) The first way I have considered arriving as speed is a to count the number of high pulses for a given period of time, Then divide pulses by unit of time to get rotations per minute (i will convert to speed later for now I'm only worried about rpms). Each given period of time will be saved into an array and a simple moving average algorithm will be used to get less jerky values (I'm outputting to a gauge stepper motor being used as a speedometer (tachometer for now until I can calibrate for speed later))
Method 2) The second method I am considering is using cnt and recording an array of cnt values where one is recorded everytime a pulse is detected. Then I can use those to find the amount of time in between pulses and use that data to calcualte out RPMs and once again run into a moving average algorithm to speed things up
Which do you think is more efficient, counting time between pulses or number of pulses per given amount of time? Or is there a better way to do this.
Comments
Depends on your desired reading-rate, dynamic range, and precision needed.
1) is the simplest, but may not give enough precision.
You can choose any time axis, so to RPM simple, easiest is to pick some binary divider, as that is just a shift, and you can also
decide the LSB is something other than 1 RPM.
2) can be simplified a little, by counting edges, and capturing time (no need to store each time), and when you have some nominal elapsed time (typically a display refresh time) then you take the next EdgeCount and TimeValue, subtract from Previous ones, and
RPM is Scale* dEdgeCount/dTimeValue
2) has more maths, but can give high precision especially ay low RPM
Alan
Yes, can be bouncy, but I think they are quick to stabilise compared to bigger switches (less contact mass
means everything is quicker).
They do have a limited number of operations, though, so there could be an issue with lifetime - depends
what sort of pulse is involved (they are used in bicycle speedos, for example, but that only a few rotations
per second or so). Hall switches are worth looking at (and most have hysteresis so don't need debouncing).
A hall-effect sensor might be a saner alternative. In some cases, they can actually count the rotation of some many teeth on an existing gear instead of needing to have a magent provided. The reed switch will always requiire that magnet. The only bit of learning required is that they are generally open-collector ouputs that require a pullup resistor to 3.3 volts to assure a proper read on a Propeller.
I think you want a uni-polar hall-effect sensor. The OTHER problem is that even with onlly 3.3v pullup to the open collector, nearly all require at least 4.5 volts to power the internal logic.... so you need both a 3.3volt and 5.0volt supply. Some have internal linear voltage regulators and require even higher that 5.0 volts for power... So shop carefull and read the fine print.
Jameco seems to have good prices for small quantities.
http://www.jameco.com/1/3/hall-effect
http://web.diegm.uniud.it/petrella/Azionamenti%20Elettrici%20II/Tesine/Petrella%20et%20al.%20-%20Speed%20Measurement%20Algorithms%20for%20Low-Resolution%20Incremental%20Encoder%20Equipped%20Drives_a%20Comparative%20Analysis.pdf
Interesting link, but they seem to have completely missed Reciprocal Counting.
Taking their sample time of 1ms in FIg 4, and a moderate 10MHz Timebase, gives a Reciprocal Counter granularity of 99ppm, independent of RPM, (provided at least one sensor cycle is available) which is a lot better than their curves.
There are a number of ways you can use CTR for period, but first you should check how much jitter a single period has, and work out how often you need this value.
eg if you have a sensor with 4 magnets, expect quite a bit of phase variation on each quadrant, but capturing 4*N cycles, should give best results.
The Prop CTR has no HW edge capture feature, so you need to track edges in SW, usually with a pair of WAITPEQ/WAITPNE instructions in a loop that counts cycles.
The Prop CTR can count edges, see Application Note AN001, Counter Modes, ( POSEDGE, NEGEDGE modes) and that can help at higher pulse speeds, and also tell you when the polling loop cannot keep up.
There will always be some delay between Pin-Edge, and time capture, but one easy way to manage that, is to have a single code point that does Edge->Read, and use an index variable to choose between storing start and finish points.
Because you calculate CyclesCountDifference/TimeDifference, reading delay offsets are removed.
My original system where I counted the number of pulses in a set time period would bounce as much as 15% when measuring a steady rpm value and this new method only bounces 0.5%-0.7% which I can smooth out with a bit of moving average code. Glad I learned to use the counters they can be pretty powerful.
- so that will vary with magnet strength / reed sensitivity ?