this means it can tell the microcontroller when it was. unfortunately, the microcontroller doesn't know when it isn't, so it cannot subtract the time that it was from the time that it isn't. i can manually inspect the difference, or deviation, in the Arduino serial monitor, but it changes over time, often by Β±0.2 seconds.

at least time isn't going backwards anymore.


i have run out of plan. a reasonable plan would be to give up and be out of sync with reality by a couple centibeats, and i may do that eventually, but a backup plan would be to allow manual calibration in exactly the way that i wanted to not need by having the gps. but i did have to make a new .beat clock to do this, because the one i found updates once a second, and that's not enough to get centibeat accuracy.


You must log in to comment.

in reply to @cactus's post:

i also have a real time clock module, which in theory i should be able to set based on the time reported by the gps. however, since the time reported by the gps is late by an inconsistent amount of time once i actually receive and decode it, i get my current set of problems

my reasoning here was: sometimes inexpensive microcontroller ICs can internally generate a clock using an LC circuit for easy/cheap applications, but have a provision for attaching an external quartz crystal if you need better clock stability. but there is already a crystal on the board