Deep sleep wake interval drifts ~9-11s per hour (consistently early) on reTerminal E1001

[Bortinio]

Hardware: reTerminal E1001
Firmware: OpenDisplay 0D7CB085, FW 0 1.71
Sleep configuration: Deep sleep, wake interval set to 60 minutes

Description

The device wakes up consistently earlier than the configured 60 minute interval. Posting the log data in case it's useful for tracking this down.

Observed data

I run a daemon on a Raspberry Pi that listens for the device's BLE advertisement and logs the timestamp on each wake. Over a 29 hour window (29 consecutive wake cycles), I measured the interval between wakes:

Expected interval: 3600 s (60 min)
Actual interval: consistently between 3585 s and 3595 s
Average interval: ~3590 s
Average drift: -9.7 s per cycle (i.e. about 0.27% fast)
Drift is consistent cycle to cycle, not randomly scattered between -5s and -15s.

Sample log (timestamps from BLE advertisement reception on the Pi side):

2026-06-19 03:05:10
2026-06-19 04:04:57   (Δ 3587s, drift -13s)
2026-06-19 05:04:52   (Δ 3595s, drift -5s)
2026-06-19 06:04:44   (Δ 3592s, drift -8s)
2026-06-19 07:04:35   (Δ 3591s, drift -9s)
...
2026-06-20 07:00:39   (Δ 3591s, drift -9s)
2026-06-20 08:00:28   (Δ 3589s, drift -11s)

Over the full 29 cycle window, total drift was -282 s, i.e. roughly 9.7 s lost per hour on average.

Additional notes

The drift seems pretty consistent cycle to cycle (always somewhere between -5 s and -15 s), rather than jumping around randomly. Not sure if that's expected behavior or something worth looking into.

Happy to provide more log data, battery voltage readings, or test a patched build if that would help.

[jonasniesner]

Thank you for reporting it. Is that a problem for your application/do you need the wakeup to be synchronised with something specific? You are actually one of the first using deep sleep so there might still be some things to iron out.

[Bortinio]

@jonasniesner Thanks for the quick reply!

Yes, it does matter for my use case. My setup generates a fresh dashboard about 5 minutes before the full hour. The idea was to have the display wake up right at the full hour, so it picks up the freshly generated dashboard within the ~2 minute BLE advertising window via my daemon.

With a drift of about 9-10s per hour (so roughly 230s/day), that 5 minute buffer gets eaten up after about 1-2 days. After that, the device would wake up before the new dashboard is even generated, and would just get served the previous (now outdated) one.

So for my application it's not just cosmetic, it actually breaks the sync within a couple of days and I'd need to manually realign the wake time again.

Highly appreciating your efforts here and happy to help test anything if that's useful.

[jonasniesner]

I will have to think about a solution for your usecase in this case. Do you use py-opendisplay or your own integration? For your usecase a "next update at" would probably better then a static sleep time.

[Bortinio]

Yes, I'm using py-opendisplay as the base for my integration.

A "next update at" approach instead of a static sleep duration sounds like it would solve this nicely, that way the device could align itself to the actual data refresh instead of relying on a fixed interval staying accurate over time.

As far as I can tell, py-opendisplay currently only exposes the static sleep interval via the device config (write_config), there's no concept of a target wake timestamp in the library yet, right? So that part would likely need to be added on both the firmware and library side?

[jonasniesner]

Yes, this would need to be added to both, firmware and py-opendisplay. And I will do that now that I know that there is a a usecase for it. I just focused more on the NRF side of the firmware for now because it does not need any workarounds like the ESP side does. But since this is mostly feature complete, I have more time to improve the ESP side

[Bortinio]

That’s great to hear, thanks for taking this on! Let me know whenever there’s something to test, happy to try it on my E1001 setup.