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

Groups > comp.arch.embedded > #13929

Re: Counting 2ms long pulses on several input pins

Show all headers | View raw

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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-23 23:42 +0200
  Re: Counting 2ms long pulses on several input pins mike <ham789@netzero.net> - 2013-09-23 15:00 -0700
  Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-23 16:12 -0700
  Re: Counting 2ms long pulses on several input pins Paul Rubin <no.email@nospam.invalid> - 2013-09-23 18:45 -0700
    Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 08:06 +0200
      Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 00:37 -0700
        Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 10:24 +0200
          Re: Counting 2ms long pulses on several input pins Paul Rubin <no.email@nospam.invalid> - 2013-09-24 02:05 -0700
            Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 11:01 +0200
          Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 09:55 -0700
            Re: Counting 2ms long pulses on several input pins Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-24 18:13 +0100
              Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 11:03 -0700
            Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 19:38 +0200
              Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 11:13 -0700
                Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 20:30 +0200
                Re: Counting 2ms long pulses on several input pins Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-24 21:20 +0100
                Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 16:08 -0700
    Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 00:34 -0700
  Re: Counting 2ms long pulses on several input pins Andrew Smallshaw <andrews@sdf.lonestar.org> - 2013-09-24 04:31 +0000
  Re: Counting 2ms long pulses on several input pins Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-24 11:15 +0100
    Re: Counting 2ms long pulses on several input pins Paul <paul@pcserviceselectronics.co.uk> - 2013-09-24 15:51 +0100
  Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-25 00:33 +0200
    Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 16:36 -0700
      Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-25 07:39 +0200
        Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 23:37 -0700
          Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-27 15:54 +0200
            Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-27 12:35 -0700
    Re: Counting 2ms long pulses on several input pins mike <ham789@netzero.net> - 2013-09-24 16:43 -0700
  Re: Counting 2ms long pulses on several input pins j.m.granville@gmail.com - 2013-09-24 17:32 -0700
    Re: Counting 2ms long pulses on several input pins Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-25 09:52 +0300
      Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-25 00:09 -0700
        Re: Counting 2ms long pulses on several input pins j.m.granville@gmail.com - 2013-09-25 16:53 -0700

csiph-web