Enviro Weather heats up under USB power

[guruthree]

It looks like some element of the power regulation for the Enviro Weather when connected to USB power dissipates significant heat into the PCB. I measure a resulting increase in temperature, both via the BME280 and via infrared thermometer readings of surface temperatures at between 3 to 4 °C above ambient room temperature. I do not observe a similar increase in temperature when using battery power, suggesting this might be from the Pico W's circuit.

I'm not sure there's much can be done about this. I was wondering if reducing the size of any ground planes around the BME280 might act to insulate it and help minimise the effect. Otherwise, one approach could be to introduce a calibration correction to temperature (as suggested in #101).

I know Relative Humidity is temperature dependent (i.e., a function of how much moisture can be stored in the air), and the BME280 datasheet §4.2.3 suggests both humidity and pressure corrections based on the measured temperature. It looks like these are implemented in the BME280 library and so I think it likely that the humidity and pressure readings would be distorted by any artificial change in temperature. Maybe any temperature calibration added to the code could be passed through to the BME280 library.

At the very least, could someone else check if they notice a similar behaviour? If I've not made a mistake in my readings, a warning should be added to the documentation to alert users that if they are using USB power, their readings are likely to be less accurate.

[herbsoft]

I just reported issue #137 against the pico enviro indoor where I am seeing a similar increase in reported temperature of 3 to 4 C when running on USB power.

[jxmesw1]

I'm also experiencing this issue on USB power. I was thinking of just subtracting a fixed value from the temperature (either 2 or 3) but this of course is assuming the increase will always be the same.

I have another BME280 on a breakout board so I'll see if there's any way to calibrate the Enviro.

[jxmesw1]

@herbsoft - I notice you didn't experience this issue in earlier versions. I'll downgrade my Weather board and see if that makes any difference.

[herbsoft]

In earlier versions I wasn't able to get it running whilst powered by USB. So it would have been on battery power then.

[jxmesw1]

Ahh ok got you. I have a variable power supply, so I'll try a range of voltages from 3 to 5v and see how the temperature changes.

[guruthree]

@jxmesw1 Oh I wonder if version could be playing a role, I'm running 0.0.9 as well. Unfortunately my weather's now deployed, but a check of temperatures under USB power with different versions of software sounds like a good idea.

[ZodiusInfuser]

Thanks for raising this @guruthree. There are 4 possible sources of heat that I can think of: the RP2040, the WiFi chipset, the Pico W's regulator (which would be correlated to the first two), and the Enviro's own regulator. When running on battery, only the Enviro's regulator is constantly powered, with the other's only coming on at the scheduled time. On USB power though, all four are powered, and there is no way to turn them off at a hardware level.

We don't currently do anything special to handle USB power, so it could well be that there are things that could be software-disabled to minimise current draw, and hopefully the temperature rise. This seems like the more prudent investigation path first, before adding calibration correction (though that could have more general use).

The relevant point in the code where such things would be inserted is here:

enviro/enviro/__init__.py

Lines 476 to 500 in a9e2eb9

	# if we're still awake it means power is coming from the USB port in which
	# case we can't (and don't need to) sleep.
	stop_activity_led()
	# if running via mpremote/pyboard.py with a remote mount then we can't
	# reset the board so just exist
	if phew.remote_mount:
	sys.exit()
	# we'll wait here until the rtc timer triggers and then reset the board
	logging.debug(" - on usb power (so can't shutdown). Halt and wait for alarm or user reset instead")
	board = get_board()
	while not rtc.read_alarm_flag():
	if hasattr(board, "check_trigger"):
	board.check_trigger()
	#time.sleep(0.25)
	if button_pin.value(): # allow button to force reset
	break
	logging.debug(" - reset")
	# reset the board
	machine.reset()

Interestingly, the loop above used to have a sleep within it prior to v0.0.9, but I think it got commented out to have the trigger check and button read be responsive. Maybe adding it back with a lower value like 0.01 would help?, assuming the RP2040 is the source of the heat?

Otherwise, currently nothing is done to turn off the WiFi module (if indeed it can be turned off). The code doesn't seem to call disconnect() either, though I believe that is because we've encountered issues with it causing hardlocks as the pico-sdk's WiFi support is still in beta.

If anyone is in a position to try the sleep thing out, that would be appreciated.

[jxmesw1]

@guruthree I've downgraded my weather to the shipping firmware (v.0.0.2). I'll let it run for the rest of today and see how the data compares to yesterday. It's in the same location, has the same power supply, etc - the only thing that has changed is the version. We'll see if there's any significant changes in temperature.

@ZodiusInfuser I was just about to hit send when you commented! I'll experiment later this evening and tomorrow following my current experiment (as above) and will let you know how I get on.

[jxmesw1]

Results so far are below. There's a notable difference of around 1° since downgrading to V.0.0.2.

[ZodiusInfuser]

Thanks @jxmesw1. There are many changes between v0.0.2 and v0.0.9, but if we assume it's just the bit after a battery powered board would normally go to sleep, then here's the difference between the two.

[jxmesw1]

No worries! I'll install v0.0.9 again with the addition of the sleep line and see what difference that makes.

[jxmesw1]

@ZodiusInfuser I've installed v0.0.9 and added time.sleep(0.25) where it was originally commented out. I'm still seeing a difference of around 1°C - maybe a bit less, but still definitely closer to the real temperature.

[ZodiusInfuser]

Thanks @jxmesw1. That suggests that some of the heat (but not all) is coming from the RP2040. Any chance you can try a sleep of 0.05 and/or 0.01? check_trigger needs to be called quite regularly to pick up rain events during heavy downpours, so 0.25 will impact on that.

[jxmesw1]

Hi @ZodiusInfuser, this weekend I've tried sleeps of both 0.05 and 0.01. I haven't had a chance to plot the graphs yet, but the difference in temperature is marginal. They both are very close to the +3° mark - e.g reporting 15° when it is actually 12°C.

I'm not sure if there's any way to turn off the wifi chip without causing problems? It would be interesting/useful to see if that makes a difference. 🤔