Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Inconsistent gpio values on raspberry pi

I'm building a device to assist my disabled wife, part of which is the detection of water levels within a tank. I resorted to the RV (recreational vehicle) method of conductors through the tank wall as being simplistic. I'm controlling this with a raspberry pi, using GPIOs for each level, pulling them high, then grounding when the water reaches each conductor. I started having problems with this, not getting correct values after the first one or two input() calls. I've been using 3.3v, btw.

While troubleshooting, I wrote a very simple test program that configures a GPIO for input and then I manually grounded/ungrounded that GPIO with test leads, getting the same inconsistent results as when I was connected to the tank.

What happens with the tank is I get spurious reports of rising/falling edges on the pin, but no changes to the pin occurred, and I get the same value as before the interrupt. Without the tank, just manually grounding the pin, I don't get spurious events, but the data I read from the pin is random (unpredictable). I even issue two consecutive reads and sometimes get different values. I've done "tankless tests" with and without a 330 ohm resister.

I've performed all of my tests (with and without the tank, and without any hardware except two test leads) with two raspberry pi's, getting the same results.

Being a novice with circuits - Does this sound like the RPi is flaky or am I ignorant of basic circuit "design" (what I've done should not be considered a design)???

Update --- I should have mentioned that I used debounce values from 10 to 2000 ms, all with the same results, just slower with the longer debounce times.
 
Last edited:

danadak

Well-Known Member
Most Helpful Member
Not interrupt handler.....https://www.valvers.com/open-software/raspberry-pi/bare-metal-programming-in-c-part-4/

Or need to debounce GPIO inputs for mechanical inputs like switches ?

iu


Regards, Dana.
 
Not interrupt handler.....https://www.valvers.com/open-software/raspberry-pi/bare-metal-programming-in-c-part-4/
Yes, it is not a true "interrupt handler", it is a call back from a service that probably gets its own call back from another service ultimately leading to the code that is the interrupt handler.

Or need to debounce GPIO inputs for mechanical inputs like switches ?

Regards, Dana.
Thanks for the response. I updated my OP to reflect the debounce values I have used during those tests.
 

Latest threads

New Articles From Microcontroller Tips

Top