pimoroni / enviro

MIT License
104 stars 83 forks source link

Temperature calibation #19

Closed jamesRaybould closed 2 years ago

jamesRaybould commented 2 years ago

I've just provisioned 2 of the enviro indoor sensors and one of them is reading a good 4-5C above what I believe the room to actually be, is there a way of calibating the sensor or, alternatively, a way of always deducting/adding a value to true it up?

ExperiMentor commented 2 years ago

You can edit the code in /enviro/boards/[boardname].py

Look for the lines like: return { "temperature": round(bme280_data[0], 2), "humidity": round(bme280_data[2], 2), "pressure": round(bme280_data[1] / 100.0, 2), "light": round(ltr_data[BreakoutLTR559.LUX], 2),

where you can see that the raw value from the BME280 sensor is reported after rounding to 2 decimal places. Then you can add "-4" or whatever to give:

"temperature": round(bme280_data[0] - 4, 2),

Note that you may require a more sophisticated adjustment than simply adding or subtracting a fixed value - eg might need to multiply by 0.8 then add 1 - but you need to work out what you want.

You can see above that pressure has been adjusted by dividing by 100. You could add adjustment for altitude of your location there!

jamesRaybould commented 2 years ago

I was thinking about something like that but it would require a custom setting on each of the devices, I guess I could abstract it out and have it so that it sits in config.py 🤔

One other thing I did spot is that the reading appears to be affected by being powered by USB

Screenshot 2022-08-18 at 11 03 31

Is there any thing special about being on USB power as opposed to battery? I did spot in the sensor spec's that the VOC sensor (that isn't returned by the existing implementation) has a heater - is that some how getting turned on when we run using USB power?

jamesRaybould commented 2 years ago

When I checked this morning I saw something interesting - I've got a bit of custom code that stops the uploading of measurements overnight (23:00-08:00) to help save the battery a bit more when I don't want/need measurements.

Screenshot 2022-08-19 at 13 47 30

In the above graph you can see when those uploads stop - and the temperature reading drops, could it be that connecting to the WIFI network is impacting the temp sensor?

ExperiMentor commented 2 years ago

The WiFi transceiver is the key suspect! I get a +2C spike with every 4th measurement, when the periodic upload occurs. Need to work out why it doesn't take the measurement before doing the upload

jamesRaybould commented 2 years ago

I ran a little experiment and set reading_frequency=1, then set the upload_frequency=30 so it'd take 30 readings and then upload them, my thinking was that we'd see how quickly it'd cool down. As you can see below more frequent readings (everything in the red box) for some reason means a shorter temperature spike.

Everything in the light blue box was taken with reading_frequency=5 and upload_frequency=6, so the same time period between uploads but produces higher spikes ¯_(ツ)_/¯

The only other thing of note is that this is all on USB power, without another power source attached.

Screenshot 2022-08-19 at 18 39 16
ExperiMentor commented 2 years ago

Looks to me like the duration of spikes is an artefact of how you plotted them? Look at the actual values to check properly. In each case (and certainly when the measurement interval is longer) there is one high value in each spike; the fact that it looks wide is just because of the time since the previous and time to the following value making it look like a triangular spike. At the fast measurement interval, there might be one high value at the upload time followed by a second half-high value just after?

On Fri, 19 Aug 2022, 18:54 James Raybould, @.***> wrote:

I ran a little experiment and set reading_frequency to 1, then set the upload_frequency to 30 so it'd take 30 readings and then upload them, my thinking was that we'd see how quickly it'd cool down. As you can see below more frequent readings (everything in the red box) for some reason means a shorter temperature spike.

Everything in the light blue box was taken with reading_frequency=5 and uploadfrequency=6 and produces higher spikes ¯(ツ)_/¯

The only other thing of note is that this is all on USB power, without another power source attached.

[image: Screenshot 2022-08-19 at 18 39 16] https://user-images.githubusercontent.com/2018774/185678628-6f30a54e-0f2b-4692-aa2c-e066d6179dbb.png

— Reply to this email directly, view it on GitHub https://github.com/pimoroni/enviro/issues/19#issuecomment-1220953421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7TCRNNL5N6MWI4HQKKTATVZ7C5VANCNFSM562NO2DQ . You are receiving this because you commented.Message ID: @.***>

jamesRaybould commented 2 years ago

To the best of my knowledge those numbers in that graph are accurate, when they get plotted they get stuck in the graph with whatever was logged from the enviro indoor device. What's interesting is that I'm not seeing the same issue on a device that is powered by a battery.

ExperiMentor commented 2 years ago

You misunderstand me. I'm saying that the graphs are misleading, not that they are wrong If you only have a reading every 5 mins, that one reading is at a peak, but the base of the peak will stretch from previous reading (5 mins earlier) to next reading (5 mins later), so the width of the triangular peak is 10 mins. If you have a reading every minute, the width of a single value peak will be only 2 minutes, so it appears shorter. None of this explains the difference in height of the peak though.

ExperiMentor commented 2 years ago

Just as a follow-up, my temperature spiking issues disappeared (even while attached to USB) after I did a firmware update for a completely different problem. They must have fixed something else 'under the hood'! See https://forums.pimoroni.com/t/envirogrow-error-when-attempting-to-truncate-the-log-file/20044

jamesRaybould commented 2 years ago

I tried the same, updating the firmware using 1.19.7 and then making sure I have the latest from here (with my custom changes) and I'm still seeing the general increase in temp on USB, as well as the upload spike

lowfatcode commented 2 years ago

The PicoW takes about 20mA during normal operation and more like 200mA when connected to WiFi - that's about 1W! This will definitely skew your temperature readings up if you leave it plugged into USB permanently.

Our original concept for Enviro was for it to sleep for the vast majority of the time to conserve battery - this also allows it to return back to ambient temperature between readings.

That said we can see a case for allowing "always on" as a mode, but this will require some sort of calibration/adjustment function to be added - we're looking into that as a possible enhancement in the future.

ExperiMentor commented 2 years ago

@lowfatcode That does not make complete sense. Even when powered by USB, the WiFi is (or should be) powered off except during uploads, just as when JST-powered. I saw spiking during USB power, though the other user found consistently higher values as well as spikes when USB-powered. My (replacement) board shows a 2C temperature spike at the time of WiFi uploads, even when powered by JST and asleep most of the time. Look at https://io.adafruit.com/CortmalawHerbs/dashboards/soil-moisture where there is a WiFi upload at 30 minutes past each hour (was 15 minutes past until a reboot at 1030). I don't see a reason for this when I look at the code, as the temperature reading (correctly) seems to be taken before the WiFi is turned on. I hope it's not doing something silly like turning on WiFi to check the clock before taking the temperature reading?

dkrape commented 1 year ago

I had a very similar problem when running off USB power. Interestingly, the issue also seems to impact the humidity readings, though not pressure. You can see quite clearly when I switched from USB to battery. (Top is temperature)

Screen Shot 2022-09-11 at 12 46 10 PM
ExperiMentor commented 1 year ago

The formula for calculating humidity from the raw sensor reading depends on temperature, so it is expected that the 'error' in temperature also inversely affects the displayed humidity. Simply, when the temperature rises, the air becomes capable of holding more water vapour. So even though the water content stays the same, the percentage saturation decreases. You also seem to have a different problem where the temperature reported on USB power is lower as well as varying.

On Sun, 11 Sept 2022, 11:48 Darren Krape, @.***> wrote:

I had a very similar problem when running off USB power. Interestingly, the issue also seems to impact the humidity readings, though not pressure. You can see quite clearly when I switched from USB to battery.

[image: Screen Shot 2022-09-11 at 12 46 10 PM] https://user-images.githubusercontent.com/1051258/189523409-92bb9d21-160f-4d5c-a123-4fad499c80dc.png

— Reply to this email directly, view it on GitHub https://github.com/pimoroni/enviro/issues/19#issuecomment-1242937461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7TCRP3G2LMGEHAAG7OXADV5W2G7ANCNFSM562NO2DQ . You are receiving this because you commented.Message ID: @.***>

MrDrem commented 1 year ago

The Pico Enviro + Pack has a -3 degree temperature offset set in it's code, I suspect for using it powered by USB, which suggests that it might be expected to be 3 degrees cooler than the actual unit reports when powered in this manner. See https://github.com/pimoroni/pimoroni-pico/blob/main/micropython/examples/pico_enviro/enviro_all.py