Counting 2ms long pulses on several input pins - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Counting 2ms long pulses on several input pins
Paul snipped-for-privacy@topmail.co.uk says...
Quoted text here. Click to load it

Not enough info on reprtion frequency and max latency for each input
amongst many other factors.
  
Quoted text here. Click to load it

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>
  
Quoted text here. Click to load it

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          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Counting 2ms long pulses on several input pins
Il 23/09/2013 23:42, pozz ha scritto:
Quoted text here. Click to load it

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.


Re: Counting 2ms long pulses on several input pins
On 9/24/2013 3:33 PM, pozz wrote:
Quoted text here. Click to load it

"Bat Blinds"

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

 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?

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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

Re: Counting 2ms long pulses on several input pins
Il 25/09/2013 01:36, Don Y ha scritto:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

Good questions, but those sensors are for low-quality market.  The  
datasheet specifies just the number of pulses per rotation, mechanical  
drawings, nothing more.


Quoted text here. Click to load it

I have 10nF cap and 10k pull-up and 10k series resistance.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

Sorry, I don't understand.

Quoted text here. Click to load it

This could be a customization in charge of the installer that can decide  
number of pulses and monitoring interval.


Quoted text here. Click to load it


Re: Counting 2ms long pulses on several input pins
On 9/24/2013 10:39 PM, pozz wrote:

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

Taking this to the extreme, at what point does the system become
ineffective?

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

OK.  Is the "alarm" battery powered?  I.e., could you afford to
"burn some power" to keep the contacts burnished?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

If a slow input is high for 10ms, then it can't result in "fast
pulses" (e.g., 2ms)

Quoted text here. Click to load it

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"

Quoted text here. Click to load it



Re: Counting 2ms long pulses on several input pins
Il 25/09/2013 08:37, Don Y ha scritto:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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



Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

Yes, changing the sensor should be better.


Quoted text here. Click to load it


Re: Counting 2ms long pulses on several input pins
On 9/27/2013 6:54 AM, pozz wrote:
Quoted text here. Click to load it

[much elided, throughout]

Quoted text here. Click to load it

OK.


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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Good Luck!
--don


Re: Counting 2ms long pulses on several input pins
On 9/24/2013 3:33 PM, pozz wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: Counting 2ms long pulses on several input pins
On Tuesday, September 24, 2013 9:42:25 AM UTC+12, pozz wrote:
Quoted text here. Click to load it

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

Re: Counting 2ms long pulses on several input pins
On 25.9.13 3:32 , snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it


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



Re: Counting 2ms long pulses on several input pins
Hi Tauno,

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Counting 2ms long pulses on several input pins
On Wednesday, September 25, 2013 7:09:33 PM UTC+12, Don Y wrote:
Quoted text here. Click to load it

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.

Site Timeline