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

Groups > comp.arch.embedded > #13927

Re: Counting 2ms long pulses on several input pins

Show all headers | View raw

Il 25/09/2013 08:37, Don Y ha scritto:
> On 9/24/2013 10:39 PM, pozz wrote:
>
>>>> 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?
>>
>> It's a complete "sensor assembly" (plastic enclosure with holes for
>> mounting, rope, cam, microswitch, electrical wires) that the installer
>> of the intrusion detector system mounts on the shutter.
>
> There are no other products?  E.g., if you had *two* staggered cams
> in the assembly (and two "switches"), you could detect direction
> of rotation.  (or, two staggered switches tracking one cam track)

Yes, you're right, but I never saw those kind of sensors on the market.
Consider that an hypotetical "two switches" sensor should have a 
three-wires interface (supposing one common pole for the switches) 
instead of only two-wires for the sensor I'm talking about.

Anyway I'm not interested to develop a new type of sensor, it's a 
different business.

> Better yet, a pair of hall effect sensors watching a magnet on
> the shaft, etc.

Yes. Or a simple photodiode and associated LED with two wheels with 
alternate holes (like old mouses).

> What do *you* have control over?  I.e., are you designing your
> own hardware to monitor this stuff?  Or, is that also "predetermined"?

No, the hardware that will read the sensor signals is under my control, 
the sensor assembly is as is.



>>>> 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?
>>
>> Yes, you got it.  I don't like this method to detect shutter movement by
>> humans, but it's a common solution on the market.  It's a low-cost
>> low-reliability system, but it's for consumer products.
>
> How much "nuisance" do customers perceive with the existing systems?
> Is there some *value* to coming up with a system that does not
> exhibit the same problems?

I wouldn't use this sensor in a professional system, but for consumers 
application it's ok.  The false alarms could be maintaned low with a 
correct configuration of the detector (number of puses in a time).

Of course, if an alarm is raised if a single pulse is detected, the 
false alarms would be too high.  But if the alarm is raised after 
reading 10 pulses in 2 seconds, the false alarms should almost zero.
Indeed it's difficult, in real situations, the wind and consequent 
vibration of shutter generate many pulses in a short time.

I know that a smart thief could move the shutter so slowly that the 
detector wouldn't detect the shift.  Having a three-wires sensor that 
detect direction/rotation, this problem wouldn't be present.


>> Anyway, if you experience problems like the one you described (in my
>> tests it's very difficult, see below), you can always decrease the
>> sensitivity of the system.
>
> Taking this to the extreme, at what point does the system become
> ineffective?

The system become ineffective if the shutter is slowly moved.  It's a 
tradeoff between false alarms (high sensitivity, a few pulses in a long 
time) and ineffectiveness (low sensitivity, a lot of pulses in a short 
time).


>>>> 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)?
>>
>> Yes, you got it again. This is the reason why it's difficult to have
>> false alarms caused by vibration at the "switching" point of the
>> microswitch.
>
> OK.  But, you can't be *guaranteed* that it won't happen.
> Sort of like tossing a coin and NOT expecting it to land on
> it's edge!  :>

Yes, for my market this low probability it's ok.  I will never use it in 
a civil airplane :-)


> What is the cost/consequence of a "false alarm"?  Are the properties
> that have these blinds "occupied"?  So, the alarm is just a nuisance?
> ("Bob, there's someone at the window!")
>
> Or, are these "shuttered" properties and the false alarm causes
> someone to be dispatched to that location to "investigate"?
> (I'm trying to get a feel for how much value a "better" solution
> might have)

The possibilities are a lot and both your scenarios could happen.


>>>> 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)?
>>
>> Good questions, but those sensors are for low-quality market.  The
>> datasheet specifies just the number of pulses per rotation, mechanical
>> drawings, nothing more.
>
> But, other folks are using them, right?  So, what has the market's
> experience been with them?  How do they tend to hold up over time?
> Are they replaced often as problems turn up?  Or, is the alarm
> just "turned off" after a while because of too many nuisance alarms?

Yes, those sensors are already used.  I heard that sometime they create 
many problems (false alarms) so they finally are replaced with other 
similar sensors (some guys think the problem is a defective sensor).
I think it's a problem of a high sensitivity with the detector, indeed 
many times the false alarms go away decreasing sensitivity.
Does the system become ineffective this way?  I don't think if a good 
sensitivity is configured.  Anyway, as I already wrote, if the shutter 
is moved very slow, the detector could be faked.


>>> 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"?
>>
>> I have 10nF cap and 10k pull-up and 10k series resistance.
>
> OK.  Is the "alarm" battery powered?  I.e., could you afford to
> "burn some power" to keep the contacts burnished?

The system is connected to the power line with a high capacity backup 
battery in the case of a black-out (or if the thief cut the power).


>>>> 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.
>>
>> Ok, better alternatives?
>>
>> With this method, I'm not able to detect only very fast pulses. Consider
>> that the pictures above were for very slow and very fast rotation.
>
> Given what you've described, the idea that comes to mind first is
> to add something that "catches transitions" that you can "poll"
> (at some rate).  I.e., a latch/counter that catches the transition
> that you can examine at your leisure and "clear" (to re-arm for the
> next transition).
>
> But, you would like not to have to add parts as that increases cost,
> etc.
>
> So, two possibilities:
> - if you have *spare* counter/timers in the MCU you are using,
>    then let them count transitions and just poll the counter values
>    periodically.  If a value has changed, then an edge was detected
>    "since the last poll"

I think using an hardware counter with a so noisy signal isn't a good 
idea.  The bouncing effect would be taken in the counting.


> - if you have edge catching digital inputs, configure them to
>    "catch edges".  This is typically the case for an input that
>    can directly trigger an IRQ.  The problem with letting these
>    UNCONDITIONALLY trigger IRQ's is you then have to worry about
>    an interrupt storm (i.e., from "noisey" inputs).  So, in each
>    ISR, record the fact that the IRQ occurred (i.e., "an edge was
>    detected").  Then, disable THAT interrupt and schedule a task
>    to reenable it some time later -- ideally, before you are
>    likely to encounter another *normal* edge (NOT a "bounce").
>    This can get tricky to manage as you have to ensure you don't
>    leave an IRQ disabled and, therefore, "blind" yourself to
>    activity on that signal (it also requires an MCU that has
>    this ability)

It's a possibility I have already thought, but I think a polling 
mechanism at a sampling frequency would be better.
I wouldn't trust an edge trigger interrupt on a digital input if the 
signal isn't digital but so noisy.


> There are other "hacks" that you can exploit to do similar
> things.  E.g., an unused serial port can act as a detector
> (depending on how small the "glitch" you are trying to catch)
> just by watching the "data"/character that is received on
> that line.
>
> Or, "modem control signals" can signal IRQ's on certain transitions.
>
> Or, a "DMA request" signal (your software simply watches to see
> *if* the DMA has been activated since last poll).
>
> If you want to get *really* clever, you can store a charge on
> an input pin and wait for the switch closure to dissipate that
> charge (because the switch closed after you created the charge).
> Then, poll the pin (i.e., without a pullup to restore that charge)
> and respond accordingly.  [I'm not sure how reliable this would
> be in your environment as you'd need high impedance inputs, etc.!]

The cable between sensor and detector should be even 20-30m long.  I 
think it's not a good idea to use high impedance input.


> A lot depends on the MCU you've chosen and its capabilities
> and limitations.
>
>>>> 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?
>>
>> Sorry, I don't understand.
>
> If a slow input is high for 10ms, then it can't result in "fast
> pulses" (e.g., 2ms)
>
>>>> 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?
>>
>> This could be a customization in charge of the installer that can decide
>> number of pulses and monitoring interval.
>
> Yes, but your software would have to support whatever parameterization
> it requires.  I.e., ten *sets* of "10 pulses in 2 seconds" vs.
> "100 pulses in 20 seconds", etc.

Yes, I think the customer/installer can tune those two parameters 
without great difficulties.


> I'd be much happier with something that watches direction of rotation.
> That would implicitly involve some debouncing just because of
> the sequencing of the signals involved.  I.e., 01-11-01-11 is
> "jitter" while 01-11-10-00 is "rotation"

Yes, changing the sensor should be better.


>>> (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