this post was submitted on 29 Sep 2023
5 points (85.7% liked)

Ask Electronics

3325 readers
1 users here now

For questions about component-level electronic circuits, tools and equipment.

Rules

1: Be nice.

2: Be on-topic (eg: Electronic, not electrical).

3: No commercial stuff, buying, selling or valuations.

4: Be safe.

founded 1 year ago
MODERATORS
DavideAndrea@discuss.tchncs.de
linker3000@discuss.tchncs.de
5
RPi Pico "disconnects" after a few minutes to days (feddit.de)
submitted 1 year ago by agressivelyPassive@feddit.de to c/askelectronics@discuss.tchncs.de
4 comments fedilink hide all child comments
 

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:

  1. 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

  2. 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.

top 4 comments
sorted by: hot top controversial new old
[–] dgriffith@aussie.zone 4 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] agressivelyPassive@feddit.de 2 points 1 year ago (1 children)

I tried that. The loop was:

  1. Read sensor
  2. Prepare message
  3. Wifi on
  4. Send message
  5. Wifi off

That should nicely separate everything, but it still ran into similar issues.

[–] dgriffith@aussie.zone 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] agressivelyPassive@feddit.de 1 points 1 year ago

can you power the sensors off a pin? At least then you can programmatically power cycle them if you need to.

Not really, at least I wouldn't really know how. The sensor needs +3V, GND and two data pins, and the pico only has one 3V out, that seems to connect directly to the voltage regulator. I guess, I could try to use a GPIO pin as a switchable 3V out, but that seems rather hacky.

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

Unfortunately, a simple machine.reset() seems not to be enough. I didn't use "real" watchdogs, but what a Java dev knows: try/catch. I wrapped the entire loop in a try/except block and simply call machine.reset() if something goes wrong. That does work sometimes, but not always. Of course the possibilities are a) some exception isn't getting caught b) there is some electronic issue, maybe the SPI interface to the DHT is "stuck" or not properly reset. I can resolve the problems by completely disconnecting the device for a while from power.