[PROBLEM] GPIO button false trigger on startup - Printable Version +- Moode Forum (https://moodeaudio.org/forum) +-- Forum: moOde audio player (https://moodeaudio.org/forum/forumdisplay.php?fid=3) +--- Forum: Support (https://moodeaudio.org/forum/forumdisplay.php?fid=7) +--- Thread: [PROBLEM] GPIO button false trigger on startup (/showthread.php?tid=2700) Pages:
1
2
|
RE: GPIO button false trigger on startup - gbh_uk - 06-25-2020 (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 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 RE: GPIO button false trigger on startup - waffle - 06-28-2020 (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 RE: GPIO button false trigger on startup - TheOldPresbyope - 06-28-2020 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 RE: GPIO button false trigger on startup - waffle - 06-29-2020 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 (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. RE: GPIO button false trigger on startup - TheOldPresbyope - 06-29-2020 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-python/tickets/). Regards, Kent RE: GPIO button false trigger on startup - waffle - 06-30-2020 (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 RE: GPIO button false trigger on startup - waffle - 07-01-2020 @TheOldPresbyope Thanks for your help RE: GPIO button false trigger on startup - waffle - 07-03-2020 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. RE: GPIO button false trigger on startup - TheOldPresbyope - 07-05-2020 @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. |