Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #13864

Re: Counting 2ms long pulses on several input pins

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>

Show all headers | View raw


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


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