• AVR Freaks

Hot!Digital filter for an I/O input

Author
DominusT
Super Member
  • Total Posts : 1324
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
2019/08/10 09:01:48 (permalink)
0

Digital filter for an I/O input

Hi.
 
I have several digital inputs isolated by optocouplers on a PIC32.


These inputs are connected with pushbuttons that will be several meters in length from the electronic board that contains the MCU with its optocouplers.


Because the wiring will be very long in an industrial environment, it is possible for electrical noise to reach the inputs and the MCU interpreted as correct logical values.
 
The most logical solution is to place a filter to the inputs in the MCU, but the problem is that these inputs can also be used as rapid pulse counters and said filter would distort or cancel the pulses that are to be counted.
 
That depends on the user who can configure the inputs as simple digital inputs or as inputs for pulse counters based on software that is useful for configuring the system.
 
A cumbersome solution that I can think of is to use two pins for each input, one pin would be used for the pulse counter and the other (isolated with a buffer) would have a filter to eliminate the possible noise, depending on the user's configuration it would be used the one pin or the other.
 
The other solution that I can think of is to implement a digital filter in the input that will be used or not depending on the user configuration.
 
My question is:


Is there an example of such a digital filter?
 
Any comment or suggestion is welcome.
post edited by DominusT - 2019/08/10 09:03:20
#1

10 Replies Related Threads

    crosland
    Super Member
    • Total Posts : 1603
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Bucks, UK
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/10 09:53:42 (permalink)
    0
    You can't have it both ways, or are you saying the rapid pulse counter mode does not have the long lines picking up interference?
    #2
    DominusT
    Super Member
    • Total Posts : 1324
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/10 09:58:17 (permalink)
    0
    crosland
    You can't have it both ways, or are you saying the rapid pulse counter mode does not have the long lines picking up interference?




    Whe the user uses the fast counter option, the device that produces the pulses will not be far from the main board containing the MCU.
    #3
    bg_blea
    Super Member
    • Total Posts : 139
    • Reward points : 0
    • Joined: 2014/07/02 06:02:02
    • Location: state of confusion- for reals
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/10 10:48:40 (permalink)
    3 (1)
    This might work for you:
    https://www.digikey.com/product-detail/en/IF-E10/FB104-ND/3724?utm_medium=email&utm_source=oce&utm_campaign=1140_OCE18RT&utm_content=productdetail_US&utm_cid=282153&so=56348212&mkt_tok=eyJpIjoiWlROaFlUWXpOekJrWWpJNCIsInQiOiI1SnM5eXdCRkpZQWZEZ2YxQXppXC9ialhpaCtcLzJRZVNDc2NCcm9jRDVvWU9WSUphR0lRUHJLTk9UVDkxYm5SMFVMb3YzY2EzbTFMdDZQVlhDQ01ZK3hib0QwVlEweVY1WmtcL29cL2RcL1puYVNSd2c0dnMrVTZMcSs1clwvTjRVcjl5VyJ9

     
    Edit: the link is to plastic fiber optics. Cheap and very easy to use

    Hobby. Juuuust hobby
    #4
    maxruben
    Super Member
    • Total Posts : 3354
    • Reward points : 0
    • Joined: 2011/02/22 03:35:11
    • Location: Sweden
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/10 15:19:22 (permalink)
    0
    What is the frequency of the rapid pulse inputs?
     
    /Ruben
    #5
    DominusT
    Super Member
    • Total Posts : 1324
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/10 15:21:00 (permalink)
    0
    maxruben
    What is the frequency of the rapid pulse inputs?
     
    /Ruben


    Maximum around 5 kHz
    #6
    NorthGuy
    Super Member
    • Total Posts : 5580
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/11 09:04:05 (permalink)
    5 (3)
    If your noise may have the same frequency as the signal you cannot filter it out.
     
    Instead, use a differential line.
    post edited by NorthGuy - 2019/08/11 10:42:24
    #7
    DominusT
    Super Member
    • Total Posts : 1324
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/11 14:34:38 (permalink)
    0
    NorthGuy
    If your noise may have the same frequency as the signal you cannot filter it out.
     
    Instead, use a differential line.


    That is a good idea that has not crossed my mind.
    #8
    DominusT
    Super Member
    • Total Posts : 1324
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    moser
    Super Member
    • Total Posts : 504
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/15 03:01:28 (permalink)
    0
    I don't really get the problem. You are talking about two use cases:
    1) filtering noise for button presses
    2) counting the fast pulses
    And you want do do both in the MPU and not outside of the MPU? And you said, the user can configure, which use case he has. So is it true, that your software knows how it was configured? Is this correct so far?
     
    If this is true, where is the problem? Your software can behave in different ways, depending on the setting from the user. Even if you intend to use the hardware features of the MPU (like the counters) you can usually reconfigure those during run-time, if the user changes the setting, or just ignore their result. The only real problem would be, if you want to filter outside the MPU in hardware.
     
     
    For debouncing a button I use a very simple software technique which is a bit similar as described in the second link, but with some differences.
     
    I have a counter which counts up and down between 0 and a fixed limit. Every few milliseconds in regular intervals (for example 1ms or 20ms or something like this), I check the pin state. If the pin is high I increase the counter by 1 up to the maximum limit. If the pin is low, I decrease the counter by 1 down to 0. If it reaches the maximum limit, I claim that the button is pressed. If it reaches 0. I claim that the button is released. For example for detecting a button press roughly after 0.1 second, and with a polling interval of 20ms intervals I just count to 5, which corresponds to roughly about 80 to 100ms for detecting the button press, and with noise a bit longer. With 1ms polling you could count up to 100. You can tweak all these values and the pin state polling interval depending on your needs and how quickly you want to react to a button press. But keep in mind, that humans are quite slow, and probably you don't need to be incredibly fast.
     
     
    My code is similar like this:
     
    Definitions:
    int counter = 0;
    bool button_is_pressed = false;
    #define MAX_LIMIT 5
     
    code which is executed in regular intervals:
    if (pin_is_high) { ++counter; } else { --counter; }
    if (counter <= 0) {
        // limit the counter and change to state "not pressed" (or keep this state)
        counter = 0;
        button_is_pressed = false;
    }
    if (counter >= MAX_LIMIT) {
        // limit the counter and change to state "pressed" (or keep this state)
        counter = MAX_LIMIT;
        button_is_pressed = true;
    }

     
    With some noise the counter just goes a few times into the wrong direction. But this does not matter. If the pin is statistically more in one state, this state will win in the long run. That is the main difference to the code in the second link, which needs a perfect sequence of a certain pin state without a single bit of noise until the button state is changed.
     
    One problem of the approach I'm using occurs if the noise is completely dominating, because then you will get wrong button events, which the code in the second link would not have. The other real problem with the approach I'm using occurs when the noise is in sync with your polling interval. But this also applies to the code from the second link. Since you have a lot of freedom with the polling interval, you should be able to avoid it. 
     
     
     
    And of course: Avoiding the problem is often better than trying to fix those. Therefore, using a communication channel, which is less influenced by noise is probably easier to handle, than filtering the noise.
    #10
    DominusT
    Super Member
    • Total Posts : 1324
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Digital filter for an I/O input 2019/08/15 03:17:20 (permalink)
    0
    moser
    I don't really get the problem. You are talking about two use cases:1) filtering noise for button presses2) counting the fast pulsesAnd you want do do both in the MPU and not outside of the MPU? And you said, the user can configure, which use case he has. So is it true, that your software knows how it was configured? Is this correct so far? If this is true, where is the problem? Your software can behave in different ways, depending on the setting from the user. Even if you intend to use the hardware features of the MPU (like the counters) you can usually reconfigure those during run-time, if the user changes the setting, or just ignore their result. The only real problem would be, if you want to filter outside the MPU in hardware.  For debouncing a button I use a very simple software technique which is a bit similar as described in the second link, but with some differences. I have a counter which counts up and down between 0 and a fixed limit. Every few milliseconds in regular intervals (for example 1ms or 20ms or something like this), I check the pin state. If the pin is high I increase the counter by 1 up to the maximum limit. If the pin is low, I decrease the counter by 1 down to 0. If it reaches the maximum limit, I claim that the button is pressed. If it reaches 0. I claim that the button is released. For example for detecting a button press roughly after 0.1 second, and with a polling interval of 20ms intervals I just count to 5, which corresponds to roughly about 80 to 100ms for detecting the button press, and with noise a bit longer. With 1ms polling you could count up to 100. You can tweak all these values and the pin state polling interval depending on your needs and how quickly you want to react to a button press. But keep in mind, that humans are quite slow, and probably you don't need to be incredibly fast.  My code is similar like this: Definitions:
    int counter = 0;</p>
    <p>bool button_is_pressed = false;</p>
    <p>#define MAX_LIMIT 5
     code which is executed in regular intervals:
    if (pin_is_high) { ++counter; } else { --counter; }</p>
    <p>if (counter <= 0) {</p>
    <p>    // limit the counter and change to state "not pressed" (or keep this state)</p>
    <p>    counter = 0;</p>
    <p>    button_is_pressed = false;</p>
    <p>}</p>
    <p>if (counter >= MAX_LIMIT) {</p>
    <p>    // limit the counter and change to state "pressed" (or keep this state)</p>
    <p>    counter = MAX_LIMIT;</p>
    <p>    button_is_pressed = true;</p>
    <p>}
     With some noise the counter just goes a few times into the wrong direction. But this does not matter. If the pin is statistically more in one state, this state will win in the long run. That is the main difference to the code in the second link, which needs a perfect sequence of a certain pin state without a single bit of noise until the button state is changed. One problem of the approach I'm using occurs if the noise is completely dominating, because then you will get wrong button events, which the code in the second link would not have. The other real problem with the approach I'm using occurs when the noise is in sync with your polling interval. But this also applies to the code from the second link. Since you have a lot of freedom with the polling interval, you should be able to avoid it.    And of course: Avoiding the problem is often better than trying to fix those. Therefore, using a communication channel, which is less influenced by noise is probably easier to handle, than filtering the noise.

    I just want a digital filter by software for a digital input (the examples that exist are for analog inputs). Everything else I know how to do and there is no problem. I have done some tests and it seems that I have solved it. Thanks for write
    #11
    Jump to:
    © 2019 APG vNext Commercial Version 4.5