Shop OBEX P1 Docs P2 Docs Learn Events
Reed switch speed sensor Coding question — Parallax Forums

Reed switch speed sensor Coding question

stevoveestevovee Posts: 18
edited 2013-11-07 15:33 in Propeller 1
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.

Comments

  • jmgjmg Posts: 15,173
    edited 2013-10-31 13:01
    stevovee wrote: »
    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.

    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
  • stevoveestevovee Posts: 18
    edited 2013-10-31 14:59
    I more or less went with your suggestion for method 2. I'm capturing the number of edges in a period of time slightly less than the display refresh time. It delivers a very steady and pretty accurate measurement, set it up on a small milling machine to test and it holds through a pretty good rpm range. Then i'm going to run the whole thing through a simple moving average code to keep my gauge stepper speedo from being jerky and it should work for me.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2013-11-01 09:04
    I think that reed switches are particularly bouncy, so there would be a limit to sencing speed verses de-bouncing times.

    Alan
  • Mark_TMark_T Posts: 1,981
    edited 2013-11-02 04:49
    I think that reed switches are particularly bouncy, so there would be a limit to sencing speed verses de-bouncing times.

    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).
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2013-11-02 09:02
    These days, I wish I could get my bike wheels to do a couple of rotations per second (without having to fit 6" diameter ones) ;-)
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-11-03 01:22
    I think that reed switches are particularly bouncy, so there would be a limit to sencing speed verses de-bouncing times.

    Alan

    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
  • jmgjmg Posts: 15,173
    edited 2013-11-03 19:25
    stevovee wrote: »

    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.
  • stevoveestevovee Posts: 18
    edited 2013-11-05 10:47
    My frequency based system that I Initially came up with was jumpy at lower speeds so I am trying to implement a period based system. I'd like to use CTRA and CTRB function and count the number of clock cycles between two negative edges. Unfortunately I don't have much experience using these counters. Would they be something that I could implement for this?
  • stevoveestevovee Posts: 18
    edited 2013-11-05 11:05
    Also I already have the magnetic collar/ reed switch combo and have my PCB already laid out so I'd like to try and make this work as good as I can with the reed switch setup.
  • jmgjmg Posts: 15,173
    edited 2013-11-05 12:13
    stevovee wrote: »
    My frequency based system that I Initially came up with was jumpy at lower speeds so I am trying to implement a period based system. I'd like to use CTRA and CTRB function and count the number of clock cycles between two negative edges. Unfortunately I don't have much experience using these counters. Would they be something that I could implement for this?

    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.
  • stevoveestevovee Posts: 18
    edited 2013-11-07 12:10
    what I ended up doing which is actually working well is using the logic counter mode. When the reed switch is not net to a magnet the switch is closed (pin is high) when the reed switch is near a magnet its open (pin is low) I have my counter set in logic mode so that pin A is the pin the reed switch is hooked up to and when A is high it begins counting. I also have it set so that the counter is reset back to zero when the pin is low. Now there is the issue of bounce, my output will show many different small counts before the larger counts (what i'm actuallly looking for show up) I could work up some kind of logic so that when a change of state happens, it waits a short duration-at least long enough for the bounce to be over, and following this begins counting. Instead I just made a minimum value for my counter and said that if at least X number of cycles isn't accumulated don't save the counter and chose a value well under what I will have at my max rpm but much higher than the accumulation during bounces.

    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.
  • jmgjmg Posts: 15,173
    edited 2013-11-07 15:33
    That may not be the best ? - a direct gated counter is going to read pulse width, not a whole period, and not 4 periods.
    - so that will vary with magnet strength / reed sensitivity ?
Sign In or Register to comment.