Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13864
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Counting 2ms long pulses on several input pins |
| Date | 2013-09-24 16:36 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <l1t7kp$8ph$1@speranza.aioe.org> (permalink) |
| References | <l1qck1$9dd$4@dont-email.me> <l1t40d$sma$3@dont-email.me> |
On 9/24/2013 3:33 PM, pozz wrote: > Il 23/09/2013 23:42, pozz ha scritto: >> Do you have better ideas? > > Ok, this is the full story. I want to interface a microswitch-based > sensor (http://www.utk.it/img/img_prodotti/00279.jpg) that is normally > mounted to a rolling shutter > (http://www.pakuya.com/upload/20111128/China_luhaitian_Aluminum_insulation_roller_shutter.jpg) "Bat Blinds" > in order to detect its movement and prevent unauthorized access by thiefs. > > When the shutter moves vertically, the thin rope attached to it creates > the circular movement of the cam inside the sensor. I have seen sensors > with 6 cams per rotation, but there are so many low- and high-quality > sensors on the market that I expect some differences among them. So, the cam (note I am only talking about the cam right now, not the whole sensor) is something that you will *add* to the shutter? Or, is it present in every shutter -- though possibly different based on shutter model/manufacturer? Or, is it some complete "sensor assembly" that you add to a shutter? > The final goal of the project is to detect movement of the shutter > caused by humans (i.e., not caused by wind). This can be achieved if > I'm able to count the debounced pulses of the microswitch. For example, > I can raise the alarm when I see 10 pulses in a second (low sensitivity) > or just 2 pulses in 5 seconds (high sensitivity). Depending on the > sensor used, I can change the sensitivity of the alarm detector by > changing the number of the pulses and the period of counting. From your comments, it seems like the sensor contains no *directional* information? I.e., if the cam was sitting on the "threshold" between the switch being engaged and released and "jiggling" back and forth, you would see this as motion -- perhaps FAST motion -- even though the shutter wasn't moving? > So I connected the two wires at the output of the sensor (connected > internally to the microswitch) at a microcontroller-based circuit: one > pole is connected to 0V and the other to a pulled-up input of the > microcontroller. Normally the switch is closed so the level is 0V when > the shutter isn't moving (it's impossible to stop the shutter when the > microswitch is open). I don't understand. Are you saying that the lobe of the cam is so small that the switch can't (in practical terms) STAY open for more than a few ms just because the spring force of the switch tends to *push* the cam out of the way (allowing the switch to close, again)? > I made some tests pulling/releasing manually the rope of the sensor and > the pulses frequency, width and bouncing changes dramatically. > Here two pictures with a high rotation speed: > http://imageshack.us/a/img191/6538/5v63.jpg > http://imageshack.us/a/img545/2902/nrw5.jpg > Here a picture with a low rotation speed (just one pulse): > http://imageshack.us/a/img843/4931/2ebz.jpg > As you can see, the frequency of the pulses changes from 0 to about > 300Hz, width (including final bouncing) from 2ms to 11ms, final bouncing > from 1ms to 3.4ms. The positive edge is usually sufficiently clean > (without bouncing). Ick. Presumably, this is with a "new" shutter and sensor? How do things change with age? E.g., as the cam wears and wobbles? As contact resistance increases in the switch? Does the sensor manufacturer provide any endurance ratings for his sensor? Is it (semi-)exposed to the elements (and likely to degrade rapidly over time)? Do you have any sort of filter (cap) on these lines or are we just seeing a high impedance pull up on a "long wire"? > As I wrote in my previous email, the best solution I found that minimize > the not-detected and false pulses is to sample the switch line at 1ms > rate and count the pulse when I see the 0-1 sequence. After this > sequence, I wait for 1-0-0 sequence to consider the pulse finished and > start waiting for the next pulse (sequence 0-1). It doesn't even look like that would "reliably" detect pulses with the inputs you've provided -- depending on where in the waveform that 1ms sampling comb falls. > Of course there's no problem with low rotation speed: the pulse is > sufficiently long to detect it correctly. The problems come with short > pulses that have a very small stable interval (where the signal is > stable high, so the switch is open without bouncing). For low speed, the PERIOD where the signal is high inherently limits the number of "false pulses" that you detect/report. I.e., if the high speed (fast) condition is the only time you see *extra* pulses (even bogus ones!), then it just looks like the shutter is moving even *faster*, right? > I know I should sample at a higher frequency (maybe 100us) to increase > reliability, but I prefer to avoid stressing the microcontroller too > much, because it has other tasks (consider I have 8 similar inputs) to run. > > I know the pulses are very noisy and an optical/magnetic sensor could > solve many problems, but I can't change the sensor. Moreover for this > application I could tolerate a few errors in the counting process. You're really looking at a few different things to make your final decision. Not just how many pulses in a given time interval but, perhaps, how many in an even *longer* time interval. E.g. if 10 pulses means the shutter has moved, linearly, 2 inches, does that mean anything to your final criteria? Or, does it have to move *100* pulses for it to be open enough to represent a threat? (also, revisit my comments regarding a shutter that is motionless but "jiggling" the cam -- possibly quickly!)
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-23 23:42 +0200
Re: Counting 2ms long pulses on several input pins mike <ham789@netzero.net> - 2013-09-23 15:00 -0700
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-23 16:12 -0700
Re: Counting 2ms long pulses on several input pins Paul Rubin <no.email@nospam.invalid> - 2013-09-23 18:45 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 08:06 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 00:37 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 10:24 +0200
Re: Counting 2ms long pulses on several input pins Paul Rubin <no.email@nospam.invalid> - 2013-09-24 02:05 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 11:01 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 09:55 -0700
Re: Counting 2ms long pulses on several input pins Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-24 18:13 +0100
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 11:03 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 19:38 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 11:13 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 20:30 +0200
Re: Counting 2ms long pulses on several input pins Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-24 21:20 +0100
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 16:08 -0700
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 00:34 -0700
Re: Counting 2ms long pulses on several input pins Andrew Smallshaw <andrews@sdf.lonestar.org> - 2013-09-24 04:31 +0000
Re: Counting 2ms long pulses on several input pins Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-24 11:15 +0100
Re: Counting 2ms long pulses on several input pins Paul <paul@pcserviceselectronics.co.uk> - 2013-09-24 15:51 +0100
Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-25 00:33 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 16:36 -0700
Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-25 07:39 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 23:37 -0700
Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-27 15:54 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-27 12:35 -0700
Re: Counting 2ms long pulses on several input pins mike <ham789@netzero.net> - 2013-09-24 16:43 -0700
Re: Counting 2ms long pulses on several input pins j.m.granville@gmail.com - 2013-09-24 17:32 -0700
Re: Counting 2ms long pulses on several input pins Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-25 09:52 +0300
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-25 00:09 -0700
Re: Counting 2ms long pulses on several input pins j.m.granville@gmail.com - 2013-09-25 16:53 -0700
csiph-web