For best accuracy, this radio requires the tty_clk line discipline, which captures a timestamp at the * on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the \r ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines.
Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning.
In operation, this driver sends a RQTS\r request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second:
*RQTS U,ddd:hh:mm:ss.0,q<cr><lf> on-time = '*' ddd = day of year hh:mm:ss = hours, minutes, seconds q = quality indicator (phase error), 0-6: 0 > 20 us 6 > 10 us 5 > 1 us 4 > 100 ns 3 > 10 ns 2 < 10 nsThe alarm condition is indicated by 0 at Q, which means the radio has a phase error greater than 20 us relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarmed.
The continuous time mode is disabled using the RQTX\r request, following which the radio sends a RQTX DONE<cr><lf> response. In the normal mode, other control and status requests are effective, including the leap-second status request RQLS<cr>. The radio responds with RQLS yy,mm,dd<cr><lf>, where yy,mm,dd are the year, month and day. Presumably, this gives the epoch of the next leap second, RQLS 00,00,00 if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver.
Additional Information