Enviro Urban RTC errors

Support
1

My Enviro Urban was running ok using Micro USB power (direct into the Pi Pico W board). I then switched to LIPO AMIGO PRO power with a 6700mAh Lithium Ion Battery Pack (BAT0013). Very soon, I got the red flashing LED, and a warning from Adafruit.io about data in the future.

This is what I found in the logs …

2022-12-02 14:44:56 [debug    /  94kB] > 99 blocks free out of 212
2022-12-02 14:44:56 [debug    /  92kB] > taking new reading
2022-12-02 14:44:56 [info     / 123kB]   - seconds since last reading: -1801331985
2022-12-02 14:44:56 [debug    / 120kB]   - starting sensor
2022-12-02 14:44:56 [debug    / 118kB]   - wait 5 seconds for airflow
2022-12-02 14:45:01 [debug    /  99kB]   - taking pms5003i reading
2022-12-02 14:45:01 [debug    /  96kB]   - taking microphone reading
2022-12-02 14:45:02 [debug    /  94kB] > caching reading for upload
2022-12-02 14:45:02 [info     /  88kB] > 11 cache file(s) need uploading
2022-12-02 14:45:02 [info     /  86kB] > connecting to wifi network 'harpeople2'
2022-12-02 14:45:02 [info     /  82kB]   - ip address:  192.168.1.149
2022-12-02 14:45:02 [info     / 120kB] > uploading cached readings to Adafruit.io: pgdh
2022-12-02 14:45:03 [info     / 105kB]   - uploaded 2022-12-02T14_45_02Z.json
2022-12-02 14:45:04 [debug    /  90kB]   - upload issue (422 b'Unprocessable Entity')
2022-12-02 14:45:04 [error    /  88kB]   ! failed to upload '2080-01-01T08_40_20Z.json' to adafruit_io
2022-12-02 14:45:04 [error    /  86kB] ! reading upload failed
2022-12-02 14:45:04 [info     /  84kB] > going to sleep

Upon further investigation …

pgdh$ mpremote connect /dev/cu.usbmodem314401 ls :uploads
ls :uploads
         254 2022-12-02T15_00_03Z.json
         255 2080-01-01T08_40_20Z.json
         254 2080-01-01T08_41_42Z.json
         255 2080-01-01T08_42_19Z.json
         254 2080-01-01T08_42_35Z.json
         255 2080-01-01T08_42_50Z.json
         255 2080-01-01T08_43_10Z.json
         256 2080-01-01T08_43_29Z.json
         254 2080-01-01T08_43_53Z.json
         257 2080-01-01T08_44_22Z.json
         255 2080-01-01T08_44_47Z.json
pgdh$

i.e. the RTC is jumping to a crazy value - probably because it lost power for a brief period as I switched power sources.

Of course, once the upload code hits one of these files, it will retain it for next time, such that nothing will ever update again until the files are removed.

Note: I was pushing the wakeup button pretty regularly, but just getting the flashing red LED every time. The exact sequence of events is a bit hazy, as plugging in Thonny or using mpremote can mess with the the Pico’s brain and mine.

Has anyone else seen this?

I think I’ve may seen it before, as for a while I forced the NTP update on every connection. I think we should check that the RTC’s current time is later, but relatively close to last time, and then re-sync via NTP as necessary.

I’m running 0.0.9

2

I don’t think it makes sense to update the RTC more than once a day.

When I use a RTC, I typically check during startup if the RTC gives sensible values. Some RTC have a lost-power indicator (I think this one doesn’t).

1 Like
3

I’ve been adding an RV3028 RTC to some of my PICO builds, to avoid RTC errors etc.

1 Like
4

I don’t think it makes sense to update the RTC more than once a day.

When I use a RTC, I typically check during startup if the RTC gives sensible values. Some RTC have a lost-power indicator (I think this one doesn’t).

Indeed, but we could check to see if it has changed wildly since we last woke up, and then check and reset it with NTP if it looks iffy (e.g. it has jumped more than a day either way). What we don’t want is services like Adafruit.io rejecting data because it is nonsensical (and if data is rejected, we shouldn’t try to send it again).

5

To check if the RTC changed wildly, you must store the old RTC value somewhere. Like in NVRAM. But write-cycles to NVRAM are limited.

The important question is: is your observation something that happens during normal operation? Switching power sources does happen sometimes, but not on a regular basis. So it is important to know that in this case (short power loss) no data should be sent before the RTC is in sync again. Detecting invalid RTC-values due to short power loss should be possible without using NVRAM (at least on the RTCs I use this is the case).

Best solution on the hardware side would have been a 1F capacitor. This should buffer the RTC for a short time, so it survives swapping the power source. But this would increase costs and it is questionable if this makes sense for a specific use case like this.

6

To check if the RTC changed wildly, you must store the old RTC value somewhere. Like in NVRAM. But write-cycles to NVRAM are limited.

Ah yes, though it is FLASH, which is typically good for 20K cycles, and there’s 2MB of it (though that does make me wonder how good the wear levelling of the filesystem is).

Typically when an Enviro Indoor / Urban / etc wakes up, it will take a recording and store it, so there is some writing to flash anyway. Once records have been uploaded to a service we don’t have to delete everything immediately, so we would be able to deduce the time of the last wakeup.

Perhaps we could also get smart about allocating a FLASH page (typically 4KB) to each wakeup, such that we only generate a single FLASH page write (with sensor values, timestamps, queue pointers etc) just before going back to sleep.

I must say, this is all very refreshing after working the day job on systems with multiple terabytes of RAM and FLASH :)