GPIO and Spurious Hits

Apr 07, 2016 21:31

I built a simple power relay controller and then wired some buttons in it to turn on different extension cords. The buttons hit input GPIO pins to set and then the relay is controlled with GPIO pins set up for output. The simplistic thing to do is roll and poll, but the Internet is smart and says, "Use interrupts!" So I did.
Code )

Leave a comment

Comments 5

markgritter April 8 2016, 06:41:42 UTC
Or put in a debouncing circuit? Or do you get spurious triggers on the *other* interrupts?

Reply

I had bounce problems ... freelikebeer April 8 2016, 11:52:30 UTC
... but the way I put the apparatus together, I didn't really have time to make an external bounce circuit. The GPIO.add_event_callback takes a bouncetime parameter, and I mucked with the numbers. I left it at 4000ms because it didn't seem to make a difference. What I perceived as bounce eventually caused me to put the delayed unlocker in there [though I hate creating circular object references like I did]. At home [this is notionally a game show controller that will light some lights and make some noises when a player hits their button], I let it run for an hour and it was well behaved.

I took it to the school [where we are doing the show], and when I turn it on everything is fine and quiet. Once I hit a button, then I get spurious lights and noises on that button's circuit. Hit all the buttons and the spurious starts move all over. There can be anywhere between 0-10ish seconds between spurious starts.

I'm going to mull it over and see if I can come up with something by lunchtime. Maybe I just need to put it in a metal box.

Reply

Re: I had bounce problems ... freelikebeer April 8 2016, 12:13:49 UTC
The only upside is that the pace of buzzing-in should mask the spurious starts.

Reply


And as I talk this through ... freelikebeer April 8 2016, 13:41:58 UTC
... I'm basically built like this, but reading the buttons and switches tutorial I wonder if I need a capacitor to slow down the transients, or even something more robust.

Reply

RE: And as I talk this through ... freelikebeer April 8 2016, 15:21:46 UTC
The tl;dr version of this is that the add_event_callback() for GPIO.FALLING uses a hardware trigger that fires on transitions through 1.12V-1.16V, and is not dependent on the actual logic level. So, hardware fixes aside, one should add a short-delayed-read of the logic level in software to make sure this was a true event.

Reply


Leave a comment

Up