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

[ZodiusInfuser]

@jxmesw1 Thanks for doing that testing. Sounds like the short delay is worth adding, but doesn't solve the problem outright.

Interesting that you mention turn off the wifi chip. I was looking into CircuitPython code today for an unrelated task and came across this line of code from their Pico W support

void cyw43_enter_deep_sleep(void) {
#define WL_REG_ON 23
    gpio_set_dir(WL_REG_ON, GPIO_OUT);
    gpio_put(WL_REG_ON, false);
}

This suggests that the WiFi can be turned off by setting GP23 to low. I don't know if there is any knockon effect with that, but could be worth adding to the enviro sleep function before the while loop?

[jxmesw1]

@ZodiusInfuser I'm so sorry! I've been caught up with work and haven't had a chance to do any further testing. If this is still required, I should have the weekend free. Please let me know if there's anything else I can do to help!

[ZodiusInfuser]

Hi @jxmesw1 . No worries. I haven't had chance to test this myself either. If you do have time to test it with your setup, it would be useful to know if it has an effect.

[jxmesw1]

@ZodiusInfuser Hi, turning off the WiFi makes a small but noticeable difference - I was seeing temperatures of around 0.5 to 1°C lower than before.

However.

This sometimes caused connection issues. Sometimes the board would connect and upload its readings perfectly fine, but most times it would refuse. Upon checking the logs, it simply says it couldn't connect to my wifi network.

As soon as I removed the relevant lines of code, the issue disappeared. I repeated the test, and each time the board would occasionally refuse to connect. The issue was rather frequent: I'd say every 3-5 readings roughly.

So - this does help lower the temperature, but does cause issues.
In combination with the small sleep, I think we could get quite close to the real temperature. We just need to figure out a reliable way to disable the WiFi chip.

[ZodiusInfuser]

@jxmesw1 Where abouts in the code did you insert the line to turn off the WiFi? I would have thought that doing it in sleep after the RTC was set would have been fine, since it never gets used again until the board resets. If that's not the case, then that's confusing to me!

[JamesH1978]

ughh, just received my weather, and thought I know i'll hard wire in some 5v over micro usb. I was wondering why I was getting high temperatures. Can I confirm that if I swapped from the USB connector and move to using the jst battery connector that this issue isn't a problem? Or will putting 5 volts into the battery connectors still cause the same issues?

Also is there some special sauce for building the cloned code into a UF2 for testing merged commits? I used ./dir2uf2 --manifest ~/enviro/uf2-manifest.txt ~/enviro/ but no wifi setup is exposed on flash and reset.

Thanks
James

[ZodiusInfuser]

HI @JamesH1978,

The higher temperatures are due to the Enviro not being able to turn off when power is provided to the USB. Some efforts are ongoing to mitigate this (code was recently merged in that added an offset, for example).

Can I confirm that if I swapped from the USB connector and move to using the jst battery connector that this issue isn't a problem? Or will putting 5 volts into the battery connectors still cause the same issues?

That's an interesting thought! Enviro's battery input does nothing special (like charging) intentionally, so it can support a wide range of battery types. Therefore, providing 5V to this connector will be fine, and would let the board do its shutdown procedure after taking each reading. Worth a try!

Also is there some special sauce for building the cloned code into a UF2 for testing merged commits? I used ./dir2uf2 --manifest ~/enviro/uf2-manifest.txt ~/enviro/ but no wifi setup is exposed on flash and reset.

Building the cloned Enviro firmware code into a .UF2 is generally unnecessary, as the files can be copied over to the board using Thonny or mpremote (there's a script in the repo somewhere). As such I've not tried that command you posted myself, but my understanding is it overrides files in the filesystem, not outright replace its entire content. Therefore if your board has already gone through provisioning and created a config.py file, then that file will still remain and the board won't go through wifi setup after the new files are loaded.

[JamesH1978]

Thanks testing it now. Although I used a jst pigtail and the black and red were backwards, pretty sure I haven't fried it... Pushing in about 4.9 volts.

[JamesH1978]

hmmm, still seems to be about 3 or so degrees off

[guruthree]

When I started powering off the JST at 5 V using 4x AAs my tests showed the readings weren't affected like USB readings. However, I did notice that it takes around half an hour for my Enviro Weather to cool down to ambient temperature after either powering it with USB or just even touching it. The copper in the PCB seems to soak up heat really quickly and hold it.

[JamesH1978]

Thanks Fred, I think that's spot on. Now it's been sitting in the Stevenson screen for about 18 hours, it seems to have calmed down and producing much better results :) need to do some logging and some checking against other thermometers, and always have the value template adjustment in homeassistant from MQTT if I need to tweak it up and down a little bit here and there

[guruthree]

I cross compared my Enviro against a DS18B20, an LM75A, and an infrared thermometer and found they all agreed to within about 0.5 °C, which I figure is about as good as I can expect without something like a multipoint calibration in a climate controlled environment.

[sjefferson99]

I've just got my station running outside for the first time as I've been unable to get my board to run on battery without it hanging after a day or so as per #87 I have since moved to powering it by USB as this removed the crashes and I've put a small battery backed solar install by the weather station as I also want to try and increase the polling frequency significantly over the low power design.

This has introduced the interesting issue of heat as seen here. Could I check if I have the summary correct from reading the above?

It looks like the last few comments suggest if I could run my larger battery through the JST connector and let it settle, this would remove the USB heating issue as far as is practical, at least for normal infrequent polling (RP2040 off most of the time)? If so, that's annoying I have my crashing issue but perhaps #144 might help me out, I have yet to properly check that out and test it.

The other approach is adding a sleep command and wireless disable to reduce the heat created by USB, but the sleep command can't be too high to prevent the rain sensor from tracking high volumes of water and the wifi disable seems to cause instability although we don't know where that line was added so more testing needed there? Again, any kind of sleep in a loop may become more problematic as polling frequency increases.

The final approach would be to add an offset as per #142 but expanded to the weather board, however a vague memory of GCSE thermodynamics suggests that the offset could vary significantly between summer and winter. I might build a PR to at least apply the static offset to the weather board and perhaps attach a remote BME sensor to the QW/ST connector (assuming there aren't I2C addressing issues) and try and track the offset as temperature changes empirically, see if there's some maths that will make it close enough. I would like to try and have polls be nearer the 1-4 Hz mark for wind gust tracking if the code could be persuaded to run like that given it was designed for low power low frequency polling and if so the heat issue will only get worse and need some form of active correction.

Let me know if I have any of the above wrong as far as we know. I'll check back in if I make good on any of the above.