Counting 2ms long pulses on several input pins

The "modification" would be fixing it to handle real world constraints.

E.g., what if you have to debounce the *trailing* edge of the signal as well? Or, if the signal bounces for its *entire* "operated" period (i.e., it never "settles" before the cam has "passed" completely)? Or if each switch operates at different rates (some fast and some slow). Or if "where" (in the cam cycle) the output is generated needs to be tweeked? Or, if the profile of the cam is altered (e.g., inverted so what was a trailing edge now becomes the leading edge) -- for example, to convert a very low dwell angle signal to the complementary high dwell signal (cuz little blips on cams wear down and become even smaller/narrower; while short "notches" have lots more room to "grow into")

Or if the algorithm doesn't initialize favorably ("As soon as we turn the power on, it reports a leading edge of a cam even though the mechanism hasn't started moving, yet"!)

A more complicated algorithm is more likely to be implemented correctly *once* and copied thereafter. Then, tweeked in well defined ways ("to generate signal on switch *release*, insert statement HERE")

E.g., for keyboards/keypads, I implement up/down encoders: X has been depressed; X has been released

"Bat Blinds"

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?

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?

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

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

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.

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?

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

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

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.

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.

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

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.

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.

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.

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

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

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.

Sorry, I don't understand.

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

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

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?

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

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)

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?

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

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

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

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"

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.

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.

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

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.

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.

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

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

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.

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

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

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

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.

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

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.

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.

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.

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

Yes, changing the sensor should be better.

OK.

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

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

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

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

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

Good Luck!

--don