@Amber Bowman yeah this is a real problem for long deployments — the STM32WB's internal RC oscillator can drift noticeably over 6-8 hours without some kind of correction anchor, so your instinct to worry about it is right.
The cleanest solution I've seen for this kind of setup is to use the GNSS module as your time reference — it's already outputting a PPS signal and UTC timestamps, so if you're logging outdoors anyway you can sync your MCU clock against that periodically and correct for drift rather than just trusting the free-running clock. Even a sync every few minutes keeps you tight enough for most sensor fusion work.
If GNSS isn't in the picture, the other option is to do periodic timestamp corrections from the base station side over BLE — basically have the base station broadcast a reference time every N seconds and have the device apply a small correction offset, which works reasonably well as long as your BLE connection is stable and you account for the transmission latency in your correction math.
Either way I'd also recommend logging a monotonic counter alongside your wall-clock timestamps so you can reconstruct timing post-hoc if something does drift — gives you a fallback for data recovery on long sessions.
