Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Problem: GPIO button false trigger on startup
#11
(06-25-2020, 01:52 AM)waffle Wrote:
(06-25-2020, 12:50 AM)gbh_uk Wrote: So, potentially the bug could be that the button is connected to GPIO 8, the capacitor is connected to GPIO9, and the script is controlling GPIO3, which is not connected to anything at all.
Here's the pinout that I believe is correct
If I'd used the wrong pins neither the button nor the relay would work at all Smile

I've tried it with the button on gpio 12 (that doesn't have any capacitors or any interfaces like i2c) and I also tried powering the system with power bank to avoid any kind of interference, but the problem didn't go away. The next step is to try a clean install on another sd card I guess.

(06-25-2020, 01:08 AM)TheOldPresbyope Wrote: I forgot to ask. Just for completeness, what model RPi and, if an RPi4B, have you tried the same with an earlier model?
Sorry, forgot to mention that, but you can see it in the logs I posted:
Code:
20200624 185221 worker: Raspbian (10.3)
20200624 185221 worker: Kernel   (4.19.115-v7+ #1305)
20200624 185221 worker: Platform (Pi-3B 1GB v1.2)
20200624 185221 worker: ARM arch (armv7l, 32-bit kernel)

Just goes to show that not all GPIO pinout diagrams are created equal:

https://pi4j.com/1.0/pins/model-2b-rev1.html

And that I should start to read the small print and 'attention' notices  Blush
Pi-4B[1GB] with Allo DigiOne SPDIF

'This is the time. And this is the record of the time.'
Reply
#12
(06-25-2020, 01:52 AM)waffle Wrote: The next step is to try a clean install on another sd card I guess.
Still happens on a fresh install
Reply
#13
I haven't done any digital control work with a RPi and its GPIO. With other SBCs and microcontrollers, we used software filtering, aka software debouncing, to deal with mechanical switches. I expect the technique would work for you but I'm not in a position to to work through it with you. Google is your friend.


Regards,
Kent
Reply
#14
Another observation: unlike normal button presses, the false trigger doesn't appear in gpio-buttons.py output (GPIO handler is disabled in settings and run manually as Tim described in post #2):
Code:
pi@moode:~ $ sudo /var/www/command/gpio-buttons.py
/var/www/command/gpio-buttons.py:54: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
  GPIO.setup(sw_1_pin, GPIO.IN, pull_up_down=GPIO.PUD_UP)
/var/www/command/gpio-buttons.py:54: RuntimeWarning: A physical pull up resistor is fitted on this channel!
  GPIO.setup(sw_1_pin, GPIO.IN, pull_up_down=GPIO.PUD_UP)
2020-06-28 20:53:31 sw_1: pin=3, enabled=1, bounce_time=500, cmd=python,/home/pi/scripts/relay_toggle.py

(06-28-2020, 09:13 PM)TheOldPresbyope Wrote: I haven't done any digital control work with a RPi and its GPIO. With other SBCs and microcontrollers, we used software filtering, aka software debouncing, to deal with mechanical switches. I expect the technique would work for you but I'm not in a position to to work through it with you. Google is your friend.
Moode already has debounce feature. It registers all button presses with no error, no problems here.
Reply
#15
You have me there. Like I said, I haven't done any digital control work with an RPi and haven't explored RPi.GPIO.

If I understand your intent, it shouldn't matter if the event is triggered when you press the button or when you press and release the button.

Looking at /var/www/command/gpio-buttons.py, right now you're detecting the release, e.g., GPIO.RISING.

What happens if you reverse the detection polarity to GPIO.FALLING? [added in edit: along with an appropriate change to the call-back function, of course.]

This is a band-aid solution but nothing ventured, nothing gained. I'd still want to understand what's causing the occasional detecting of a rising edge with no button activity, but I think that's a question better suited asked of the RPi.GPIO maintainer Ben Croston (see, e.g., https://sourceforge.net/p/raspberry-gpio...n/tickets/).

Regards,
Kent
Reply
#16
(06-29-2020, 12:23 PM)TheOldPresbyope Wrote: What happens if you reverse the detection polarity to GPIO.FALLING? [added in edit: along with an appropriate change to the call-back function, of course.]
Not sure what I should change in the call-back function, but it seems like switching to falling edge detection fixed it, huh
Reply
#17
@TheOldPresbyope Thanks for your help
Reply
#18
I switched from my fresh install sd card which is 6.5.0 to my usual one with 6.5.2 and it doesn't register GPIO.FALLING button presses...
I think I'm gonna stay on 6.4.2 for now.
Reply
#19
@waffle

What I mean by appropriate change to the call-back function is that if you change from detecting a rising edge to detecting a falling edge, then the call-back function has to be changed to check that the signal is still '0' after a suitable timeout instead of still '1'.

There's some interesting information in the "Debounce and Delay" section of this reference. The author suggests there's a bug in RPi.GPIO. On the face of it, his fix is the same as what is done in moOde's GPIO handler, but I was struck by his comment about the appropriate length of the timeout.

Without a testbed here, I can't contribute anything beyond this.

Good luck.

Regards,
Kent

Note added: There are plenty of resources on line.  This is just the last article in a series of 9 called collectively "Ultimate Guide to Switch Debounce." Good illustrations and good discussion.
Reply


Forum Jump: