Reference ID: GPS
Driver ID: GPS-HP
/dev/hpgpsu; 9600 baud, 8-bits,
This driver supports the HP 58503A Time and Frequency Reference Receiver. It uses HP SmartClock (TM) to implement an Enhanced GPS receiver. The receiver accuracy when locked to GPS in normal operation is better than 1 usec. The accuracy when operating in holdover is typically better than 10 us per day. It receiver should be operated with factory default settings. Initial driver operation: expects the receiver to be already locked to GPS, configured and able to output timecode format 2 messages.
The driver uses the poll sequence
:PTIME:TCODE? to get a
response from the receiver. The receiver responds with a timecode string
of ASCII printing characters, followed by a <cr><lf>,
followed by a prompt string issued by the receiver, in the following
The driver processes the response at the <cr> and <lf><cr> and <lf>, so what the driver sees is the prompt from the previous poll, followed by this timecode. The prompt from the current poll is (usually) left unread until the next poll. So (except on the very first poll) the driver sees this:
The T is the on-time character, at 980 msec. before the next 1PPS edge. The # is the timecode format type. We look for format 2. Without any of the CLK or PPS stuff, then, the receiver buffer timestamp at the <cr>y is 24 characters later, which is about 25 msec. at 9600 bps, so the first approximation for fudge time1 is nominally -0.955 seconds. This number probably needs adjusting for each machine / OS type, so far: -0.955000 on an HP 9000 Model 712/80 HP-UX 9.05 -0.953175 on an HP 9000 Model 370 HP-UX 9.10
This receiver also provides a 1-PPS signal, but I haven't figured out how to deal with any of the CLK or PPS stuff yet. Stay tuned.
When enabled by the
flag4 fudge flag, every received
timecode is written as-is to the
flag1 0 | 1
flag2 0 | 1
flag3 0 | 1
ppsclockline discipline/streams module if set.
flag4 0 | 1
clockstatsrecording if set.