A sensor logger can work perfectly beside your laptop and still produce confusing records when someone takes it away. After a power interruption, its readings may carry an old date, or every new session may appear to start at the same time. Before handing over the prototype, check what supplies its clock, and what the startup program does to that clock.
On our bench we connected a battery-backed GraftSense DS1307 clock module to a Raspberry Pi Pico on a GraftPort carrier, set and read its time, then copied that time into the Pico's internal clock. This note separates that demonstration from the startup behavior an offline logger actually needs.
The problem is longstanding. In an August 2011 SparkFun community post, a builder reported that a logger's RTC worked while plugged in but did not advance as expected after unplugging. The author later attributed it to initialization. That report does not diagnose every clock failure, but it shows why a fitted battery alone does not settle the question.
Give the backup battery a specific job
In this setup, a CR1220 coin cell backs up the external DS1307 clock. It does not keep the Pico, its sensors or an SD-card logger running. If the main supply disappears, a correctly operating clock keeps counting while the rest of the prototype is off. On the next startup, the program can ask it for the time.
That lets you date the next reading after a restart. It does not recover measurements that were never taken during the outage. A useful log makes that gap visible rather than implying uninterrupted operation.
The module carries a crystal, the clock's timing reference, and the battery holder. The DS1307 has its oscillator circuit inside the chip but uses an external 32.768 kHz crystal. Continuing to count and keeping sufficiently accurate time are separate requirements: drift still has to be checked against what your application can tolerate.
Follow the actual power and data connections
The module connected to the carrier's I2C0 port with a four-position cable. The program assigned GP4 to SDA and GP5 to SCL at 100 kHz. Those are GPIO numbers, not physical header pins.
The module schematic separates the DS1307's +5 V supply from the lower-voltage pull-ups on the data lines, labeled +3.3 V. The regulator part number printed beside that rail needs confirming before anyone copies the design, and the drawing is not a voltage measurement. On another board, confirm the actual supply and pull-up voltages before connecting its I2C pins.
For this chip, use the documented 7-bit I2C address 0x68. Finding that address is a communication check, not proof that a valid date has been set.
Reproduce the bench experiment before changing the startup routine
We used MicroPython 1.23.0 and our team's DS1307 driver. Keep the exact driver version with your test notes: similarly named RTC libraries arrange date and time values differently.
The test program waited three seconds, started I2C, scanned the bus and created the driver object. It deliberately disabled and re-enabled the oscillator, read the existing date, wrote a fixed date and time, waited 3.9 seconds and read again. Finally it transferred the external time into machine.RTC().
The console found one device at 0x68, set the external clock to 17:47:17, then read 17:47:20 after the wait. The Pico's own clock went from 17:47:30 to about 17:47:21 after synchronization. That shows readback and a transfer between two clocks in one powered run. It is not a power-loss test or an accuracy test.
Watch the weekday fields if you plan scheduled actions. Our program wrote a weekday value of 6 for September 17, 2025, while the Pico output showed 2. Do not copy a hard-coded weekday into a weekly schedule; check the library's numbering convention and supply a weekday that matches the date.
Separate "set the clock" from "start the device"
The fixed date makes a write operation visible in a demonstration. Leave that write in the startup path, though, and every reboot moves the external clock back to the example date, even if the battery and clock are fine.
An offline prototype needs two explicit paths. During setup, set the clock from a trusted time source and record the chosen time convention. During normal startup, read the existing clock without the oscillator toggle or the fixed-date write. If the clock is stopped, unreadable or never commissioned, report that and ask for time setup instead of stamping data with plausible-looking times.
The chip's CH bit in the seconds register controls whether the oscillator runs. Clearing it allows counting; it does not prove the stored date is current, and a date in a plausible range can still be stale. The DS1307 data sheet describes the clock and calendar controls on page 8.
Normal startup starts with a plain presence check:
from machine import Pin, I2C
i2c = I2C(0, scl=Pin(5), sda=Pin(4), freq=100000)
if 0x68 not in i2c.scan():
raise RuntimeError("RTC not found; timestamp unavailable")
After that, read the CH bit and the stored time, and refuse to treat the time as valid if the oscillator is stopped or the value disagrees with your setup record. If you then synchronize the Pico, check the tuple layout instead of copying fields by position. Our driver's ordinary date tuple and MicroPython's RTC tuple put the weekday in different places, and its helper for the Pico format inserts placeholder fields. That path worked on our setup; do not assume it ports to every MicroPython board. See the MicroPython 1.23 RTC interface.
Test the behavior your user will rely on
Set a known time once and keep a separate reference clock. Read the RTC, remove the main supply while leaving the backup cell in place, wait a recorded interval, then restore power. The first startup read must happen before any time-setting code runs. Compare the returned time with the reference, and repeat the sequence with an ordinary processor reset as well.
That test separates a clock that kept running from a program that simply wrote a new date on boot. Also decide what the device does after a battery replacement, an unreadable clock or a disconnected module. For a first user trial, an explicit "time needs setting" message is easier to interpret than a believable date nobody trusts. We have not yet run this restart test.
Do not turn a battery-life figure into a product promise. The data sheet gives backup current with the oscillator running and the square-wave output off as 300 nA typical and 500 nA maximum under its stated conditions, and distinguishes that from main-supply standby current. Neither our bench photo of a fitted cell nor a short console run measures the lifetime of this assembled module. Confirm the cell, operating conditions and measured backup consumption before estimating a service interval.
For a longer trial, check drift over an interval that matters to the user. A display clock, a log comparing events across several devices, and a weekly reminder tolerate different errors. Agree on that requirement before choosing a more elaborate clock or synchronization scheme.