GPIO problem

Had any thunderstorms recently? Suspect a hardware problem, damaged GPIO input, or the built in pull up/down resitors fried. A floating input can produce a stream of false transitions. Either try another GPIO for the guage or fit a 10 k or so pull up/down resistor as required.

Then think about adding some protection to try and reduce the chances of the Pi getting zapped again.

Thanks for the reply.

No thunderstorms that I'm aware of (we've been very lucky weather wise).

With the PI powered off, I put a meter on the connections this morning, and the resistance across the two pins was off the scale, I was starting to suspect a short circuit as it seemed to think that the "switch" was always closed.

I'll look at adding in a 10K resistor and see if that makes any difference.

Adrian

I have a feeling that electronic hardware is not your forte. B-)

Which two pins? Presumably the GPIO and either +3.3 V or GND. A resistance measure "off the scale" to me means a very high resistance, open circuit, not short circuit.

You also need to know if it needs to pull up (to +3.3 V) or down (GND). That's dependant on how that Python module you call handles the GPIO and what the software expects a switch closure to produce, high, +3.3 V, binanry 1 or low, GND, binary 0.

You might think that, ...

Exactly. The software appears to be detecting a closed switch (which a short circuit would look like), whereas I appear to be seeing an open circuit.

Not sure which pair of pins, I was looking at the two pins that the gauge plugs onto. Looking at the schematic, it appears to be pin 6 and end pin on the inside track at the USB/ethernet end.

Adrian

On Wed, 7 Aug 2019 23:52:56 +0100, Adrian declaimed the following:

Please look up a pin diagram for your model R-Pi.

On a 3B/3B+, when oriented so one can read the silkscreen text of the circuit board, the USB/Ethernet ports are on the right, HDMI and power are on the bottom, and the expansion pins are across the top.

Pin 1 is inside left, pin 2 is outside left, and ALL inside row pins are odd numbers (1, 3, 5, ...) with the even numbers (2, 4, 6, ...) on the outside/top.

The best I can make from your description is that you are on pin 29 (GPIO5) and pin 39 (GND). Note that your code (from the first post) wants GPIO6 (pin 31)!

On Thu, 08 Aug 2019 10:49:06 -0400, Dennis Lee Bieber declaimed the following:

And just a follow-up comment. Since the sensor connection is GPIO and GND, the odds are good that it is relying on a pull-UP (to 3.3V) resistor, and the sensor closes/shorts to ground when active.

In message , Dennis Lee Bieber writes

I think that I'm using pins 31 and 39, but I won't be able to take a look at it until tomorrow, I'll report back then.

Thanks

Adrian

In message , Dennis Lee Bieber writes

That makes sense as the gauge is basically a see saw with a reed switch to detect when it flips over.

Adrian

In message , Adrian writes

I've had a look, and it is (as expected) using pins 31 and 39.

Strangely, the behaviour today has changed. Rather than consistently registering an "on" state, it is doing it on an intermittent basis.

Adrian

On Fri, 9 Aug 2019 20:34:12 +0100, Adrian declaimed the following:

Sure sounds like it needs either a pull-up or a pull-down... random currents could be taking the voltage above and below the threshold for 1/0 state (Note that most IC modes have a dead zone between 1/0 where anything can happen. For CMOS that is normally 30-70% -- on a 3.3V system, that would mean ~2.4+V => 1, 1.0-V => 0, and 1.0-2.4 could give anything)

Documentation implies that it uses the internal pull-up (and the sensor tips it to LOW/GND) -- but if that has failed, you might need an external resistor connecting the GPIO to 3.3V

Alternatively, since this is a rain gauge (based upon your comments in the source code) -- possibly the switch circuit has gotten wet and is conducting (grounding) the output.

Just as an aside: given that you are relying upon a tight mesh of

open read/write close

you might want to consider using a context manager style in the code

with open() as fid: read/write

The context manager will automatically close the file on block exit.

In message , Dennis Lee Bieber writes

I'll look into adding that into the circuit.

My initial reaction was that the rain gauge was the source of the problem, however with it unplugged (and so there was an open circuit between the two pins), I was still seeing the problem, leading me to think the problem was with the PI.

Thanks for the suggestion.

Adrian

moisture and bad ground connections also a possbility. months of "sitting there" and you get galvanic corrision. If it's anywhere near rain, you might need to use some kind of coating to waterproof it.

Moisture plus electricity (even low current) can lead to galvanic corrosion, tin whiskers, mold, leftover flux turning into a conductor, insulation breakdown, lots of very bad things.

additionally, the idea of an external resistor (where you were using an internal pullup/down resistor) is probably a good idea anyway, to help protect electronics against static discharge and noise in general.

Thanks for the follow up.

I can only agree with the first two points, and I'm not in a position to comment on the last one.

The PI is in a IP55 enclosure

As stated elsewhere in the thread, the problem has been seen to persist when the rain gauge is unplugged, suggesting that the problem is with the PI Hat or the Pi itself. However, as time has passed, the problem has changed. The fault has become more intermittent, and now it tends to show up when there is rain, but not always. With rain expected later this week, it will be interesting to see what the outcome is.

Adrian

On Mon, 26 Aug 2019 11:26:05 +0100, Adrian declaimed the following:

I'd still look for moisture related points in/near the housing. What is the humidity registered near the housing when it glitches?

In message , Dennis Lee Bieber writes

The humidity (and temperature/pressure) sensor is on the opposite side of the wall (i.e. outside), but when I've had problems, it has been variously in the 50% - 80% range (which is not untypical), since it was installed back in February this year, the mean of the daily means is

Adrian

On Mon, 26 Aug 2019 18:34:44 +0100, Adrian declaimed the following:

Outside and inside humidity can differ greatly -- according to the "weather clock" sitting on one of my radios, my computer room is