[time-nuts] Re: GPSDO Time Server

[Hal Murray]

"Pluess, Tobias" said:
> I thought I will add a function that is called once per second and that
> increments the seconds, minutes, days and so on. Since my GPSDO does not
> contain a realtime clock, I need to start with some arbitrary date. As soon
> as the GPS module knows the time and date, I can adjust the "internal" time
> and date. However, how should I deal with leap seconds and leap years, and
> how shall I proceed when the GPS module loses the fix (e.g. antenna
> disconnected or something)? 

The GPRMC sentence has a valid/not-valid flag so you can leave the date/time 
fields empty or garbage until you get the time from your GPS.

If you initialize your internal clock with the date your software was built, 
the time becomes how long your system has been running without getting valid 
time.

Leap years are easy, just ugly.  You can decide if it's a leap year given only 
the year.  You need a table of days of the month.  If it's a leap year, use an 
alternate table.

Leap seconds get more complicated.  What GPS module are you using?  What 
protocol?

Most of the non-NMEA protocols have a way to tell you when a leap second will 
happen.  I don't think there is a way to send a warning in NMEA -- just poof,  
235960 when it happens.

I assume you have 2 serial ports - one to talk to your software and another to 
talk to ntpd. (You actually only need 1.5 ports.  There is no reason for ntpd 
to send you anything.) You can tell it a leap second is coming via your 
control port.  If you have a few bytes of flash, you can remember that over 
power cycles.  [If you only have 1 port, things get more complicated.]

I think you can get started (no holdover) by running your GPS in NMEA mode and 
just passing along the GPRMC sentence.  You have to get it there before the 
PPS.  Extra credit if you can send it at a specified time relative to the PPS 
so ntpd can get timing from the serial port too.

If you are in holdover, I think the data from your receiver will make sense 
but it will be drifting relative to correct time.  So you could just patch the 
invalid flag to valid (and update the checksum) and ntpd would be happy.  
Eventually, the GPRMC pass-along will drift far enough so that ntpd won't like 
it.  That will put an upper limit on how long ntpd can stay in holdover.  
Handwave, if it's off by 1E6, that's 3.6ms per hour or 86 ms per day.  ntpd 
should handle that but you will probably have to tweak some parameters.




-- 
These are my opinions.  I hate spam.