Unattended, prolonged operation is the central idea behind Tinta. For that, reliability is key.
The technical implementation for this employs something like "electronic suicide": after the circuit has done its job, the Pico is first setting an alarm for the DS3231 realtime clock (RTC) when to wake up next, and is then cutting its own power supply completely off to save power. Well, it is not really suicide, however, it is more disruptive (and saves more power) than going to sleep mode. This better works, otherwise the device never wakes up again, and user interaction is needed (or worse). However, this also comes with conceptual advantages. Tinta always wakes up in the same state, the only things that change are the time (RTC) and the information on the server — making the concept very robust, no memory leakage, locked-in state or so. Only a few seconds of lifetime, always the same day, Groundhog Day for a microcontroller — poor Pico ;)
The first prototypes are now running since more than a year in the field, so I checked how well this works in real life.

Missed scheduled wake-ups over a time of about one year, counted inside each unit's own active window.
The figure shows statistics for five devices. Missed wakes: 48 of 34146 = 0.141 % -> 99.859 % delivered. Probably most of those misses are due to an unsuccessful Wi-Fi connection — devices will timeout after a few attempts. More importantly, also after missed wakes, all devices kept operating on schedule afterwards.
I think this is a very good result and the circuit is working as it should. What else can we learn from this data?
Every time data is queried, Tinta is writing a short log message to the server. The RTC alarm is firing at a known time. So, we can compare the log message time and thus the RTC time with the server's time, and learn if the RTC is accumulating a time error. This is plotted in the figure below as time error. Of course, time needed to connect via Wi-Fi can fluctuate on a scale of several seconds or more. If we average over many Wi-Fi connections, that noise averages down and the slow accumulated error becomes visible over long times. However, this is a "hack of a measurement" and everything below has to be taken with caution.
Accumulated time error of each device against the server clock. Dashed: max. crystal aging in the first year according to data sheet. Note: I did modify and reprogramme some of the devices, visible as jumps in the traces where the firmware and thus the timing was reset.A clear evolution of the time error is visible, and every device stays inside what the datasheet grants to aging alone — even though our number contains all the effects of the table below at once. The average over the fleet is close to zero, as expected if the server is not drifting at that level, i.e. locked via NTP. Stated the other way round: with eight independent clocks, the fleet average is a better reference than any single one of them.
The DS3231 datasheet specifies several separate contributions, and what we measure is their sum:
| Contribution | Datasheet | Over a year |
|---|---|---|
| Accuracy, 0 °C to +40 °C | ±2 ppm | ±63 s |
| Crystal aging, first year | ±1 ppm | ±32 s |
| Supply voltage | 1 ppm/V | 1.4 V over a battery life → up to 44 s |
| Temperature sensor | ±3 °C | shifts the compensation point |
| Aging trim register | 0.1 ppm per LSB at +25 °C | quantisation of the correction |
| What we measure | −0.61 … +0.52 ppm | −19 … +16 s |
Aging and supply voltage are contributions on the level of the observed time error. The devices all sit in the same building at a temperature around 20 °C. The DS3231 features a temperature compensated oscillator, strongly improving accuracy vs temperature.

The rate — the derivative of the curve above — against outside air temperature, both smoothed over eight weeks. Same time axis as the figure above, so the two can be read against each other. The rate axis is inverted, so that an anticorrelation reads as two parallel curves. Temperature data: Deutscher Wetterdienst (DWD), CC BY 4.0, own averaging.
We can estimate the effect of temperature by correlating with the outside temperature as an approximation, even though, the indoor swing is smaller than outdoors. A weak residual dependence remains — about 0.04 ppm/°C, all eight devices running slower when it is warmer (r = −0.76). That is what an offset of about 0.6 °C in the on-chip temperature sensor would produce, the datasheet allows ±3 °C.
So what have we learned? Yes, the DS3231 is definitely too good for this application :) The firmware will automatically readjust the RTC whenever it deviates more than 60 seconds — which, at the rates measured here, takes at least three years. Not a single one of those corrections has happened in this device set. The next generation of Tinta will get a low-budget clock!
The main result, however, is that the reliability is very good and we now have real live data for more than a year of unattended operation.
The log message also contains the remaining battery voltage, which gives data about battery lifetime. That will be one of the following logs.
Coming soon on Crowd Supply. Subscribe on the pre-launch page at Crowd Supply to get email updates about the project, including the day the campaign goes live.
caspar
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.