Time and date from GPS

aarg:
Would a "skew" of 1-2s in a shorter period of time be a problem for you? In other words, is it only long term accuracy that is important for your as of yet unexplained application?

Yes, it is the long term drift that I am trying to address. Your proposal is indeed better but I don't need that accuracy.
There is not one single application I have in mind for this as I have many things going on in parallel. It actually started out as an idea to build an Arduino clock. As I am a fan of radio controlled clock and their accuracy I thought that would be fun. But then I changed my mind due to the difficulties with the 60 KHz antenna/receiver. In another project I am working on I have outdoor remote sensors that send very in-frequent temperature data over 433 MHz. They are Nano's that are powered by a 9V battery and according to my estimates, the 9V battery will last a year or so as I am powering them down for long periods of time using a 555 timer. In that project I have a receiver that logs the temperature data to a micro SD card. It is using a RTC module for time keeping. Again, it works good. But then I thought, it I can obtain time accurately via GPS I could create my own time reference signal that I could send to my RTC based modules (and a home-made atomic clock) for them to update their time. I have not done this yet but I think I would only need to send this signal once a week or every two weeks. That way my RTC's have the correct time all the time. :slight_smile:

Yes, what I have done is make a hierarchy of time sources, each one has a synchronization schedule to the "top" provider - in some cases GPS. So the sync chain goes GPS->RTC->CPU_clock or NTP->RTC->CPU. That way if there is a time service outage, things keep "ticking" as best as possible until it's restored.

If avoiding long term drift is the main issue, then a GPS is an OK reference.

Just be sure that the RTC changing by one or two seconds, depending on the state of the time from the GPS is not an issue.

I have one GPS that differers at startup from UTC by 2 seconds, until it recieves the leap seconds update and the reported time then matches UTC. I dont know of an Arduino library that has functions that tells you if the GPS reported time is in sync with UTC.

All great points. From working with my GPS one thing is for sure, it is not like any other module I have worked with. It is very picky as it has its limitations (memory, baud rate setting etc) so it is very easy to go crazy debugging it... As others have said here, once I got it running I noticed that there is about a 0.5s lag. Since I can only adjust time in seconds, I corrected a full second (forward) and added a short delay (value was trial and error...). just before I set the time. So far so good. The time is now in sync with the blinking LED and UTC (checked online). OCD aside, it is nice having things in sync. :slight_smile:

I mentioned, if you want subsecond accuracy, you need to sample the PPS and associate it with the subsequent NMEA sentences. Those apply to the latest PPS pulse. In this way, the 0.5 second "lag" doesn't exist.

aarg:
I mentioned, if you want subsecond accuracy, you need to sample the PPS and associate it with the subsequent NMEA sentences. Those apply to the latest PPS pulse. In this way, the 0.5 second "lag" doesn't exist.

True, but not all GPS modules have a PPS pin. Mine doesn't. Besides, I don't see a problem with adjusting this short lag that is due to processing, with a short delay combined with adjusting the time forward a full second. The time is now in sync (from what you see) with the blinking LED and UTC. Just with one line of code. For me that is enough. :slight_smile: