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

Groups > comp.arch.embedded > #13828 > unrolled thread

Counting 2ms long pulses on several input pins

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#13852

In article <bad71fF7fdaU1@mid.individual.net>, 
Paul_E.Bennett@topmail.co.uk says...
> 
> pozz wrote:
> 
> > I have a 5 microswitches
> > (www.tamiyausa.com/images/product/470/75016/header_75016.jpg) connected
> > to some inputs of a microcontroller.  The switches are normally closed
> > and put the level to low.  When they are open, the level is high thanks
> > to pull-up resistors.
> > 
> > I have to count the pulses generated from the microswitches.  They are
> > managed by a rotating cam (en.wikipedia.org/wiki/Cam) that push/release
> > continuously the switches.
> > 
> > The rotation speed could change. When it is slow, the complete pulse
> > width could be up to 15-20ms, where the last part (about 3-5ms) is
> > composed by many bouncing oscillations.
> > When the rotation is fast, the complete pulse width is about 1-2ms and
> > the boucing oscillations takes about 2-3ms.
> > 
> > What is the best approach/algorithm to debounce and detect/count pulses
> > on all the lines, without stressing the microcontroller too much?
> > 
> > My approach is to sample each input lines every 1ms in the ISR of a
> > timr.  Usually it is at low level.  When I see the first 1, I increase
> > the counter and change to HIGH status.  Now I have to see two
> > consecutives 0 to go back to LOW status.
> > 
> > Do you have better ideas?
> 
> There is insufficient information here to determine:-
> 
>   1.  Is the use of mechanical switches adequate to the task being
>       undertaken.

Not enough info on reprtion frequency and max latency for each input
amongst many other factors.
 
>   2.  The best de-bounce method (in either hardare or software) that should
>       be employed.

Whether even an simple MAX6817 would do all the work and one interupt 
pin to micro..... up to complex hardware filtering, or simple filtering
and software.

Whether counters for each are needed etc. etc...

<pedant>
Most likely all solutions will be h/w and s/w even. minimal h/w pull up 
resitor and software.
</pedant>
 
>   3.  Whether polling or edge triggered inturrupts are the best strategy.
> 
> So Pozz, a simple test on which you should then report the results here. 
> Mount one of the switches as intended and strap it into a circuit 
> configuration that will resemble the input circuit you are using. Attach a 
> scope across the points where the input would be taken and set the trigger 
> to capture the resultant input. Rotate the cam-shaft over the full range of 
> rates you expect it to operate at and report the results in the form of 
> shoing us the scope traces (on a link) or tabulated as figures relating how 
> long the contacts bounce for at what speed.
> 
> Of course, once you have done this you may discover your own answer to your 
> problem. Either ay I think the other responders and myself will be 
> interested in your findings.

Also any relationship between the switches/cams, as to are we measuring 
the pulse characteristics for each cam in isolation, or related to other
cams.

The cams could for example be paper feed related in a printer and time 
differences could detect paper jam/empty/page ejected.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

[toc] | [prev] | [next] | [standalone]

#13861

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) 
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.

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.

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 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).

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).

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).

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.

[toc] | [prev] | [next] | [standalone]

#13864

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!)

[toc] | [prev] | [next] | [standalone]

#13869

Il 25/09/2013 01:36, Don Y ha scritto:
> 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?

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.


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


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


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


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


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


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

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


> (also, revisit my comments regarding a shutter that is motionless
> but "jiggling" the cam -- possibly quickly!)

[toc] | [prev] | [next] | [standalone]

#13870

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)

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

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

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

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

>>> 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!  :>

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)

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

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

>>> 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"
- 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)

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.!]

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.

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"

>> (also, revisit my comments regarding a shutter that is motionless
>> but "jiggling" the cam -- possibly quickly!)

[toc] | [prev] | [next] | [standalone]

#13927

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!)
>
>

[toc] | [prev] | [next] | [standalone]

#13929

On 9/27/2013 6:54 AM, pozz wrote:
> Il 25/09/2013 08:37, Don Y ha scritto:
>> On 9/24/2013 10:39 PM, pozz wrote:

[much elided, throughout]

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

OK.

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

So, the cost of a false alarm can be "considerable" in some cases.

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

You may have misunderstood.  I am not advocating using the
counter/timers to *count*.  Rather, I am using them as a
"one bit, edge triggered input".  For example:

      if (new_count != old_count) {
         edge_detected = TRUE;
         old_count = new_count;
      }

So, you look at "edge_detected" to determine is an edge has been
seen in this "sampling period".  Then, reset it to FALSE and
wait for the next sample period.

This is just a different way of implementing below...

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

Use the IRQ solely to detect the *edge*.  Have the ISR disable the
IRQ until the next time you are interested in an edge...

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

It just seems so "indirect".  I.e., if you could sense rotation,
a user could think of this as:  "How far do I want the shutter
to be opened BEFORE I consider it an alarm?  1 inch?  2 inches?"

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

<shrug>  You live with what you've been given!  :-/

Good Luck!
--don

[toc] | [prev] | [next] | [standalone]

#13865

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)
> 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.

What does the vendor technical support team recommend for using their 
sensors?

As an engineering manager, over the years, I've watched many a very
bright engineer get fixated on a particular issue and waste lots
of energy on a losing battle.

If I were managing the project, we'd be having discussions about
your motivation.

Why do you care if a human messes with your shutter?
If your concern is the safety of things behind the window,
you might be better off focusing on that...like lock the windows.
If the shutter is open, you don't need to move it to gain access.
If it's closed, the window should be closed and locked behind it.
Simple magnetic switch can detect a change from the fixed position.

It's difficult to follow what you're trying to do.
Your first picture of a switch was of a type that's easily
obtainable with form-C contacts.
This new "box" has been specified as "two wires".  Maybe there
really is a third contact that could be accessed to greatly simplify
your task.  Maybe a toggle-type switch with two cams.

I'd also be trying to force you off your fixation, at least temporarily,
by suggesting outside-the-box solutions.  Like, hook a stun-gun to
the shutter and use the contacts to fire it off.  Then use an
audio "scream detector" to fire the alarm.  Or maybe a piss detector.

Here on the interweb, nobody has a right to criticize your efforts,
even if they don't support the premise.
Have fun with it.

>
> 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.
>
> 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 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).

Your scope display has insufficient time resolution to tell much about 
the bounce.
You're looking more at the scope than the contacts.
Form-C contacts are your friend in this case...and a scope display
that shows whether moving pole alternately touches both fixed contacts
during the bounce interval.

Modifying the switch assembly may be far easier than trying to live
with what's there.

>
> 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).
>
> 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).
>
> 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.
>

[toc] | [prev] | [next] | [standalone]

#13866

On Tuesday, September 24, 2013 9:42:25 AM UTC+12, pozz wrote:
> The rotation speed could change. When it is slow, the complete pulse 
> width could be up to 15-20ms, where the last part (about 3-5ms) is 
> composed by many bouncing oscillations.
> 
> When the rotation is fast, the complete pulse width is about 1-2ms and 
> the boucing oscillations takes about 2-3ms.

Notice that your bounce time, is above your closure time, which makes reliable sensing more of a lottery, than engineering.

That said, since you seem to be able to tolerate false positives (wrong speed values) there are things you can do, as you push switches to their limits.

a) As you use 3 terminal Microswitches, rewire them to switch between Vcc and GND and operate no load (or a pin-keep load) on the Sense side.

 This wiring change removes contact bounce, as the first closure in either direction is what flips level. You use either the Pin capacitance, or the Pin-keep load, to store the value. (if using a uC, disable all pullups )

 Microswitches do not bounce across the whole switch action movement range, it is just on the contact-close that bounce occurs.

-jg

[toc] | [prev] | [next] | [standalone]

#13871

On 25.9.13 3:32 , j.m.granville@gmail.com wrote:
> On Tuesday, September 24, 2013 9:42:25 AM UTC+12, pozz wrote:
>> The rotation speed could change. When it is slow, the complete pulse
>> width could be up to 15-20ms, where the last part (about 3-5ms) is
>> composed by many bouncing oscillations.
>>
>> When the rotation is fast, the complete pulse width is about 1-2ms and
>> the boucing oscillations takes about 2-3ms.
>
> Notice that your bounce time, is above your closure time, which makes reliable sensing more of a lottery, than engineering.
>
> That said, since you seem to be able to tolerate false positives (wrong speed values) there are things you can do, as you push switches to their limits.
>
> a) As you use 3 terminal Microswitches, rewire them to switch between Vcc and GND and operate no load (or a pin-keep load) on the Sense side.


The canonical way of doing this is to feed a S-R flipflop with the
microswitch contacts (n/o to S and n/c to R). The flipflop toggles
at first touch on each side. As long as both sides do not bounce
together, this gives clean pulses to whatever is reading.

-- 

Tauno Voipio

[toc] | [prev] | [next] | [standalone]

#13872

Hi Tauno,

On 9/24/2013 11:52 PM, Tauno Voipio wrote:

>> a) As you use 3 terminal Microswitches, rewire them to switch between
>> Vcc and GND and operate no load (or a pin-keep load) on the Sense side.
>
> The canonical way of doing this is to feed a S-R flipflop with the
> microswitch contacts (n/o to S and n/c to R).

Or a cross-coupled NAND, etc.  Personally, I preferred hex inverters
with OC outputs ("cross coupled inverters", so to speak) as it gives
you more "latches" per package.

> The flipflop toggles
> at first touch on each side. As long as both sides do not bounce
> together, this gives clean pulses to whatever is reading.

With the sorts of high impedance circuits available now, you can
use a cap to "store" that state -- the input capacitance of the
pin driver itself!  Think "DRAM cell"  :>

[toc] | [prev] | [next] | [standalone]

#13880

On Wednesday, September 25, 2013 7:09:33 PM UTC+12, Don Y wrote:
> Hi Tauno,
> On 9/24/2013 11:52 PM, Tauno Voipio wrote:
> >> a) As you use 3 terminal Microswitches, rewire them to switch between
> >> Vcc and GND and operate no load (or a pin-keep load) on the Sense side.
> 
> > The canonical way of doing this is to feed a S-R flipflop with the
> > microswitch contacts (n/o to S and n/c to R).
> Or a cross-coupled NAND, etc.  Personally, I preferred hex inverters
> with OC outputs ("cross coupled inverters", so to speak) as it gives
> you more "latches" per package.

The Pin-keep (also called Bus-hold) I mentioned above, does this with fewer wires, and fewer pins consumed.

A device like 74LVTH573 has 8 bus hold IP, 1 wire per switch, or the 74LVTH2244 has bus hold, plus series terminators for cable drive.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web