[PROBLEM] GPIO debounce not working

[Jewa_TWN]

It seems that the debounce function in GPIO does not work in the way it should.
I use GPIO (pin 14) to initiate a smooth shutdown: "sudo shutdown -h now"
This signal comes from a glitch free source: a mini supercap based UPS, that powers the PI for at least 30 seconds to prevent SD card damage.
(0V = UPS OK, 3.3V indicates a powerfailure, and shutdown is required)

I tried different settings for debounde (1000ms...2000ms) but this does not add any delay in response, which I would expect.

Upon first detection (edge) of the pin level change, the shutdown is instantly carried out.


I started to notice this, as when a big transformer in the room next door was turned off, this also stopped the music.
Upon check, it was found that the PI nicely shutdown-ed itself...

As these EMI spikes from the transformer are very short, a 2ms debounce would have worked, a 1000ms for sure would make
the PI blind to any noisy input

@ Tim,
Could you have a check if my statement is correct?

Second: marvelous player you & the team put together!
i use a PI3B+, Allo BOSS DAC & 7" standard touch display.. it works really good.

Regards from Taiwan

[Tim Curtis]

According to the (i) help below the first change detected on the pin will trigger the command to be executed then the code will wait for Bounce Time ms before checking for another change.

"Bounce time in miliseconds (ms). This parameter is used to ignore all subsequent changes for the bounce time after the first change is reported."

-Tim

[Jewa_TWN]

According to the (i) help below the first change detected on the pin will trigger the command to be executed then the code will wait for Bounce Time ms before checking for another change.

"Bounce time in miliseconds (ms). This parameter is used to ignore all subsequent changes for the bounce time after the first change is reported."

-Tim

Oei....

That can result in unpredictable system behavior!
Specifically with very fast processing devices, as they see everything on these GPIO pins..

For all the FPGA boards, PLC's and other stuff we design that incorporate human interfacing, we:
- check on first change (assume it goes from 0 --> 1)
- wait a few ms (lets say 5..10)
- confirm if input has still same level / stable, on which it triggered (should be 1 in this case)
- Then execute the code.

- If the pin does NOT have the expected level (so a 0 iso 1) the firmware/software will judge that this
was just a glitch, and will subsequently ignore the event.
- as there is nothing executed, the system is ready instantly for the next event, there is no delay in system response.

This kind of filtering is not noticeable for humans, as it allows input frequencies of 100Hz easily...
But it kills for sure all anomalies picked up by slightly longer wires etc.
In the pretty (EMI) noisy environment we are in, we are immune for even the ion-implanter / wafer transport located next door


From my design philosophy, I believe its better to have this de-bounce delay/check as described above in the front.
As it does the trick equally good in preventing "race-track" kind of behavior, with the advantage to also deal properly with spikes etc.

Regards,
Jeroen

[Tim Curtis]

I don't disagree however I'm not the dev responsible for the GPIO class library used in moOde's GPIO Buttons module. You would need to contact the maintainer of RPi.GPIO https://pypi.org/project/RPi.GPIO/

The script used in moOde is located in the directory below
/var/www/command/gpio-buttons.py

-Tim

[Jewa_TWN]

I don't disagree however I'm not the dev responsible for the GPIO class library used in moOde's GPIO Buttons module. You would need to contact the maintainer of RPi.GPIO https://pypi.org/project/RPi.GPIO/

The script used in moOde is located in the directory below
/var/www/command/gpio-buttons.py

-Tim

Tnx,

Send the request / feedback to the maintainer of the RPI.GPIO
Once I got feedback, I will post it here.

For the meantime to "solve" my issue, i will invert the signal:
I will use a N-FET to have the GPIO at 0V (solid!!) when the supply is ok.
(The FET will five me a few milli-ohm connection, iso a 2K pull up)


This should reduce the EMI influence. Its not good, but should work.
Most likely after the weekend.

Regards,
Jeroen

[Jewa_TWN]

I don't disagree however I'm not the dev responsible for the GPIO class library used in moOde's GPIO Buttons module. You would need to contact the maintainer of RPi.GPIO https://pypi.org/project/RPi.GPIO/

The script used in moOde is located in the directory below
/var/www/command/gpio-buttons.py

-Tim

Tnx,

Send the request / feedback to the maintainer of the RPI.GPIO
Once I got feedback, I will post it here.

For the meantime to "solve" my issue, i will invert the signal:
I will use a N-FET to have the GPIO at 0V (solid!!) when the supply is ok.
(The FET will five me a few milli-ohm connection, iso a 2K pull up)


This should reduce the EMI influence. Its not good, but should work.
Most likely after the weekend.

Regards,
Jeroen

=================================
Update after the above:

NO reply from the GPIO maintainer yet : a pity..

Hardware changes:
Added a extra FET, to invert the signal:
The solid N-FET  + 330nF cap between Drain & 0V (0V when supply OK, 3V3 when about to shutdown) helps, but sensitivity is still there for touching the enclosure.
(Due to ESD discharge, as im walking on slippers indoor :-))

Next option is to solder a cap directly on the PI, not really preferred..

Keep you posted.
J

[Jewa_TWN]

I don't disagree however I'm not the dev responsible for the GPIO class library used in moOde's GPIO Buttons module. You would need to contact the maintainer of RPi.GPIO https://pypi.org/project/RPi.GPIO/

The script used in moOde is located in the directory below
/var/www/command/gpio-buttons.py

-Tim

Tnx,

Send the request / feedback to the maintainer of the RPI.GPIO
Once I got feedback, I will post it here.

For the meantime to "solve" my issue, i will invert the signal:
I will use a N-FET to have the GPIO at 0V (solid!!) when the supply is ok.
(The FET will five me a few milli-ohm connection, iso a 2K pull up)


This should reduce the EMI influence. Its not good, but should work.
Most likely after the weekend.

Regards,
Jeroen

=================================
Update after the above:

NO reply from the GPIO maintainer yet : a pity..  

Hardware changes:
Added a extra FET, to invert the signal:
The solid N-FET  + 330nF cap between Drain & 0V (0V when supply OK, 3V3 when about to shutdown) helps, but sensitivity is still there for touching the enclosure.
(Due to ESD discharge, as im walking on slippers indoor :-))

Next option is to solder a cap directly on the PI, not really preferred..

Keep you posted.
J

Slightly modified the PI...

Added a 1uF (0603 size) capacitor & 1K resistor between GND & the GPIO pin, directly on the board.
The 0603 nicely fits between the pins, & utilizes the GND pin/plane beside it. Cant get any shorter on the board  
Next, a 680-Ohm (trough hole!!) resistor to connect to the "UPS mode" signal.
A SMD resistor will not hold with a wire.


Reason to use 1K & 680 Ohm network, is that in this way I can use 5V signals. (gives 3V on GPIO, when 5V is applied)
Second, it has a pretty low impedance.

Pictures attached, for those who want to try as well.

Will try this modification for a while, then post if it works.

Regards,
J