Thank you for your donation!


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


Problem: GPIO button false trigger on startup
#1
I have one button connected to GPIO 3 that turns on the power amp and it sometimes executes the action on startup, about 1/5-10 times.
Looking at the log, it happens around the time the GPIO handler is started. Maybe there's some other log I should check?


Attached Files
.zip   moode.zip (Size: 1.65 KB / Downloads: 5)
Reply
#2
You could try adding some print statements to /var/www/command/gpio-buttons.py script and then run it manually from the cmd line after moOde boots up.

1. Add the print statement after the line below. I assume you are using Button 1.

Code:
subprocess.call(sw_1_cmd)
print('button 1 command executed')

2. Turn the GPIO button handler off in System config
3. Reboot
4. Run it from the command line

Code:
sudo /var/www/command/gpio-buttons.py

If 'button 1 command executed' is printed even though you physically did not press the button then it would suggest a possible wiring issue thats causing the GPIO pin to be in the wrong state after boot.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#3
(06-24-2020, 04:46 PM)Tim Curtis Wrote: If 'button 1 command executed' is printed even though you physically did not press the button then it would suggest a possible wiring issue thats causing the GPIO pin to be in the wrong state after boot.
Sometimes it does, sometimes it doesn't.
Should I just set that pin to as pullup input in config.txt? That didn't help
Also, I have a cap added between GPIO 3 and ground because the relay switching was causing interference.
Reply
#4
If I check the state of the pin with this script before running gpio-buttons.py, it always returns 1
Code:
import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM)
GPIO.setup(3, GPIO.IN)

print(GPIO.input(3))
Reply
#5
@waffle

Some random thoughts.

  1. If you are seeing spurious behavior during startup, then you need to devise a test which executes during startup, not a test which is run manually after everything has initialized.
  2. GPIO 3 is also used in I2C communications. I'm just saying....
  3. From my reading, GPIO 3 includes an internal 1.8 kohms pull-up to 3.3v., so telling the software to pull it high is effectively a "no op".
  4. How big is that capacitor you wired between GPIO 3 and ground? (Because of #2 you have created an RC-network.) 
  5. How long are the wires connecting it to the GPIO pin and to ground? Did you wire directly to a GND pin on the RPi or somewhere else.
  6. As above, how long are the wires connecting the switch to the GPIO pin and to ground? Did you wire directly to a GND pin on the RPi or somewhere else.
  7. How are you triggering the relay which turns on the amp? How have you made certain the flaw doesn't lie in this portion of the circuitry and software rather than in the input-button portion?
Like I said, random thoughts.

Regards,
Kent
Reply
#6
GPIO
https://www.raspberrypi.org/documentation/usage/gpio/
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#7
(06-24-2020, 08:51 PM)TheOldPresbyope Wrote: @waffle

Some random thoughts.

  1. If you are seeing spurious behavior during startup, then you need to devise a test which executes during startup, not a test which is run manually after everything has initialized.
  2. GPIO 3 is also used in I2C communications. I'm just saying....
  3. From my reading, GPIO 3 includes an internal 1.8 kohms pull-up to 3.3v., so telling the software to pull it high is effectively a "no op".
  4. How big is that capacitor you wired between GPIO 3 and ground? (Because of #2 you have created an RC-network.) 
  5. How long are the wires connecting it to the GPIO pin and to ground? Did you wire directly to a GND pin on the RPi or somewhere else.
  6. As above, how long are the wires connecting the switch to the GPIO pin and to ground? Did you wire directly to a GND pin on the RPi or somewhere else.
  7. How are you triggering the relay which turns on the amp? How have you made certain the flaw doesn't lie in this portion of the circuitry and software rather than in the input-button portion?
Like I said, random thoughts.

Regards,
Kent
1. The spurious behavior happens when I launch gpio-buttons.py. I was testing the pin state before launching it because Tim mentioned that the GPIO pin could be in the wrong state after boot.
4,5. The capacitor in an smd one placed directly between pins 5 and 6 on the underside of the board. The value is around 1nF if I remember correctly.
6. Here are the internals. Power button is green wire, gnd is black.
7. GPIO handler launches a python script that toggles the relay and an led on the front panel. I can't think of anything else that could launch this script. Also, this button was previously set to reboot the system, and I sometimes got reboots after I started the system, but couldn't understand wth was happening.

I moved the button to GPIO 12 and gonna be testing for a while. It's a very nasty bug because you have to do lots of reboots to catch it..
Reply
#8
It's not clear, but from the photo it looks very much like the green wire (button) is connected to header Pin 3 - which is actually GPIO8, not GPIO3.

GPIO3 is header pin # 15.

Plus you mention you've connected a capacitor between 5 & 6. Pin 5 is GPIO9.

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.
Pi-4B[1GB] with Allo DigiOne SPDIF

'This is the time. And this is the record of the time.'
Reply
#9
@waffle

POST EDIT: I didn't see the response from @gbh_uk until after I posted. For sure take care of his observations first.

For sure, intermittent bugs are the worst. One my first jobs as an electronically minded teenager was to sit and watch several TV sets in the back room of a local repair shop in hopes of catching them when they misbehaved. That way the real tech could concentrate on repairing sets he'd already diagnosed. He got an extra pair of eyes on the cheap and I got to play with real testing equipment that I would never have been able to access otherwise.

Sorry, I overlooked the bit about this happening specifically when you start the Python script. 

The bit about occasional reboots in your prior work seems pretty conclusive about the script being the culprit, while a 1nf capacitor is too small to cause worry about a possible RC-time constant effect in this applicatoin.

I forgot to ask. Just for completeness, what model RPi and, if an RPi4B, have you tried the same with an earlier model? The Model 4 is a different beast internally but I'm not sure this would matter in your application [Compare https://elinux.org/RPi_BCM2835_GPIOs and https://elinux.org/RPi_BCM2711_GPIOs]

RPi.GPIO V0.7.0 supposedly dealt with two relevant issues: 1) Updated RPI_INFO to include RPi 4B and 2) Fixed pull up/down for Pi4 (issue 168).

Since GPIO 3 is pulled high internally I'm not sure how it might be in the "wrong state" when you start the script but I'll have to think about this some more.

Regards,
Kent
Reply
#10
(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)
Reply


Forum Jump: