Ask Electronics @discuss.tchncs.de AggressivelyPassive @feddit.de 9 mo. ago

RPi Pico "disconnects" after a few minutes to days

I'm trying to use an RPi Pico W as a temp/humidity sensor using a DHT20.

It kind of works - at least sometimes, but I keep "losing" sensors more or less randomly.

I connected everything up like here (using MicroPython): https://github.com/flrrth/pico-dht20 There are currently 4 sensor-boards, 3 soldered, one on a breadboard.

The error modes I could observe are:

DHT20 fails to init - sometimes after the first read, sometimes after days. Resetting the machine works sometimes, if not, power cycling usually does the trick
The board just "stops" after about 5min - the serial console just says "device disconnected". Power cycling is the only option.

My measurement work by having a timer fire every minute, connect to wifi, read from the sensor, and then send an mqtt message (either the values or an error message) and shutdown wifi again.

My current ideas why it could fail (but I'm not an electronics guy at all):

There is some kind of "rogue current" messing with some IC.
Some component is broken
Maybe the power draw is too low or issuing sleep() messes with the USB-power connection somehow?

For me the problem is, I don't really know where to look for errors. The software works in principle, the soldering seems to be good enough to sometimes work for days, and looking too deep into the whole electronics side is beyond my capabilities.

11 comments

Perhaps slightly adjust your logic a little and see what it does.

Read from the sensors first, then enable and connect to wifi, send the data, then disconnect. That would reduce the maximum power draw as only one function is active at once.

Small edit: I have a MagTag ESP32 board with circuitpython that can't read onewire devices while the wifi is active. Whether that's because of supply instabilities when wifi is transmitting, or interrupt conflicts, or just plain poor programming in the onewire drivers or the wifi drivers, I don't know. But reading the devices first and then connecting to wifi and sending the data afterwards works.
- I tried that. The loop was:
  
  Read sensor
  
  Prepare message
  
  Wifi on
  
  Send message
  
  Wifi off
  
  That should nicely separate everything, but it still ran into similar issues.
  
  Hmm I'm not sure of the pin drive currents on the Pico, but can you power the sensors off a pin? At least then you can programmatically power cycle them if you need to.
  
  The Pico also has a watchdog, you could set it up to give it a reboot if things don't respond in time. It doesn't solve the issues of course but at least it gets it back to a workable state. And if the watchdog fails, or it works but there's still no USB serial, then that would point towards power instabilities or somesuch.
I had something similar happen in one of my ESP8266 projects (also running MicroPython). What I wound up doing was, every five wall clock minutes (maybe a bit sooner than that, for your case) I had my firmware do a local_networks = wifi.scan() just to exercise the wifi functionality. If that failed I have the code do gc.collect() followed by sys.exit(1), which causes the 8266 to reboot automatically.

Give that a try.
- I'll give it try!
  
  Do you have any idea, what's causing the issue? Is it specifically the scanning part that's relevant here? I'm starting/stopping wifi each minute, so the chip shouldn't just idle around all the time.
  
  No, I don't. My best informed guess is that the wifi connection's state machine gets stuck once in a while, it misses a couple of packets, and then sits there doing nothing. So, by kicking it a little it doesn't get a chance to freeze up.
Do you have a pull up on the DHT20? If not that could explain the reliability issues. 4.7k is needed according to the datasheet.

Not too familiar with the RPi Pico but you might need to disable the internal pull ups if you do that but they are likely too weak so I wouldn’t rely on them.
- I looked it up here: https://aqicn.org/air/sensor/spec/asair-dht20.pdf (I guess that's the same datasheet you used)
  
  There it says:
  
  To avoid signal conflicts, the microprocessor (MCU) must only drive SDA and SCL at low level. An external pull-up resistor (for example: 4.7kΩ) is required to pull the signal to a high level. The pull-up resistor has been included in the I/O circuit of the DHT20 microprocessor.
  
  This sounds to me like it's already present in the package? I also haven't seen any tutorial using any resistors (though that may be just an "error" made by all of them to keep it simple).
  
  Yeah on that specific board it looks like it’s included . I was just going from experience. I just wired such a sensor to an Arduino the other day and I was having problems without the pull up. I was seeing garbled data packets on the data line.
  
  edit: you can easily confirm this by measuring the resistance between VCC and Data on the sensor.

You've viewed 11 comments.