Closed jamesRaybould closed 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!
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
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?
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.
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?
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
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.
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: @.***>
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.
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.
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
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
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.
@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?
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)
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: @.***>
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
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?