From a7521aaa08cfe822e178ada1c5563e1ff2e2efb7 Mon Sep 17 00:00:00 2001 From: jlpoole Date: Fri, 20 Feb 2026 12:06:54 -0800 Subject: [PATCH] Update TimeDiscipline --- TimeDiscipline.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/TimeDiscipline.md b/TimeDiscipline.md index 2255207..6a3fa7f 100644 --- a/TimeDiscipline.md +++ b/TimeDiscipline.md @@ -1,5 +1,7 @@ +This page documents issue to be resolved. +# SD File Date Time 2/20/26 -- files on the SD cards are all time-stamped 1980! Despite having an exercise to discipline time, it looks like I missed making sure the file system also observed time. -![Ed SD Card](img/20260220_114014_Fri.png) +![test](img/20260220_114014_Fri.png) ### My prompt: If the battery is removed, then the RTC faults. The T-Beams need to be programmed so that they immediately ascertain a correct time. We could use January 1, 2026, as a milestone and if the system's clock does not have something later, then it must alert the user that the RTC is off [probably because of power disconnect and battery removal] and to place the unit so it can ascertain time from GPS. The unit could have a holding pattern of 5 minutes to allow for moving the unit within satellite view and ascertaining GPS time, or then default to its zero-based time. We could have a user prompt action to bypass this waiting period, e.g. pressing the BOOT or POWER button. I'm treating these units as single board computers, which they are, and establishing time is critical. This has been very helpful and will help solidify what I am assembling for a code base for the T-Beam.