Using a Garmin GPS 18 LVC as NTP stratum-0 on Linux 2.6
As a member of the NTP pool and consequently of the Timekeepers mailing list, I became interested in running my own time source. This would allow me to have very precise time—synchronized within mere microseconds to GPS satellites—and would allow me to share this time with the Internet through the NTP pool project.
Many experts scattered across the Internet have set up their own timeservers, and helped me to set up my own. To show gratitude, I wrote this document hoping to make this enjoyable and beneficial activity more accessible to other interested individuals.
Thus, this document describes how to configure a Linux 2.6 PC with the NTP Reference Implementation from the NTP (R&D) Project at the University Of Delaware, version 4, to synchronize to the perfect
time provided by a Garmin GPS 18 LVC unit.
Prologue
I've recently exchanged a few emails with a guy, who was keeping his name a mystery, who believes that the design of my circuit board encourages jitter due to the fact that the green LED is on the same circuit as the PPS signal. It is true, but I have not had time to load up gschem and make a new diagram, much less rewire my own circuit board.
Instead, I'll describe the gist of the constructive criticism so you can avoid making my mistake. Use "a cheap boring NPN transistor (or an N-gate MOSFET) to buffer the high-going PPS pulse and drive your LED without loading the line." He continues, "When the PPS goes high, the transistor will turn on, and pull current through the LED and 300 ohm resistor."
On the other hand, I received an email from Bruce Allen, saying that he verified with an oscilloscope that the LED increases jitter by "much less than 0.1 usec". Since the GPS signal is accurate to at most 1 usec, the LED has absolutely no impact on the functionality and accuracy of the setup.
Nevertheless, I plan to find the time soon to incorporate the NPN transistor suggestion into the diagram.
According to popular opinion, the best solution is connecting a Garmin GPS 18 OEM sensor in a barewire (LVC) cable configuration. Although Garmin additionally makes serial and USB cable configurations for this sensor, only the barewire configuration provides a PPS signal output! If your goal is accurate timing, you must buy the LVC configuration and wire it up yourself (or have it wired by someone else who's not Garmin).
After much looking around, I bought my Garmin GPS 18 LVC from Provantage. They offer it for the least amount of money.
The GPS requires 4.0 to 5.5 V to operate, so I elected to use a USB connector to supply 5.0 V. You can also provide power from the serial port, but you will have to alter the voltage.
Although some people simply soldered the appropriate wires of the GPS to the appropriate pins of serial and USB connectors, I think it is better to modularize the connections to allow easier replacement. Thus, I use three male-female connectors:
- a single-row six-pin connector pair from the GPS to the circuit board;
- a serial connector pair from the circuit board to a PC;
- an A-B USB connector pair from the circuit board to a PC
I also added two LEDs, for fun and profit: a red one demonstrates that power is provided and the fuse is not blown, and a green one demonstrates a PPS signal.
If you are in the Dallas area, I strongly recommend Tanner Electronics as the source of your components.
- a 3.75"x2.75" or smaller prototype board (mine is labeled "Tanner 1")
- a single-row six-pin connector pair
- a female right-angle DE-9 serial connector
- a female right-angle USB type-B connector
- a 1-amp fuse
- 2 differently-colored LEDs (mine are red for power and green for PPS)
- 2 resistors for LEDs (what resistance?)
- wire
- epoxy
- a soldering iron, solder, flux
This schematic was made in gEDA's gschem.
The LVC configuration of the GPS is advertised to draw 60 mA @ 5.0 V. The LEDs add a combined 20 mA to the current draw from USB. Therefore, the USB port experiences a draw of about 80 mA; given that the standard allows for up to 500 mA, there is no concern of overdrawing current.
I suggest applying epoxy on the connectors. This is critical for the USB type-B connector: because of the discrepancy of the spacing between PCB holes and the four USB connector pins, I had to cut off two of the four pins, and had to likewise cut off the side "jaws" that are supposed to provide stability. Thus, solder is entirely insufficient for keeping the connector stable.
I put the photos on a separate page, as there are 10 of them. Here's a teaser, though:
Look at the photos of the printed circuit board.
Garmin supplies Windows-based software called SNSRCFG for connecting, monitoring, and configuring the GPS. Although not strictly necessary since the defaults are fine, you may want to connect and verify that "PPS Mode" is on, "PPS Auto Off" is on (although this is debatable), and "PPS Length" is acceptable. The latter is how long the PPS signal will be asserted and how long LED will remain on per second. Mine is set to 200 ms. I received a report from Michael L. Semon that a PPS length of 100 ms is too short for gpsd. 200 ms seems to be all-around the best length.
You may want to also increase the baud rate to ensure that all GPS lines can be output within a second.
To view NMEA traffic—to verify that the GPS is operational and to see how many satellites it can see—use these settings in a terminal emulator: 4800 8N1. (4800 baud, no parity, 8 data bits, 1 stop bit.) I use minicom on Linux.
Once properly configured, you will see output similar to this:
$GPRMC,022708,A,3303.6672,N,09640.3395,W,000.0,266.2,090406,004.8,E*6D
$GPGGA,022708,3303.6672,N,09640.3395,W,1,04,2.1,214.0,M,-24.9,M,,*72
$GPGSA,A,3,01,,,,,16,20,23,,,,,5.1,2.1,2.0*32
$GPGSV,3,1,11,01,54,060,40,06,02,065,00,07,07,114,00,11,11,241,00*7D
$GPGSV,3,2,11,14,20,094,00,16,51,155,36,20,51,303,43,23,25,306,39*7D
$GPGSV,3,3,11,24,08,310,00,25,58,027,00,37,00,000,00*4E
$PGRME,6.7,M,17.3,M,19.5,M*27
$GPGLL,3303.6672,N,09640.3395,W,022708,A*36
$GPVTG,266,T,261,M,000.0,N,0000.0,K*79
$PGRMV,0.0,0.0,0.0*5C
$PGRMF,346,8842,090406,022708,14,3300.6672,N,09643.3395,W,A,2,0,266,5,3*0B
$PGRMB,,,,,,K,,,*2D
$PGRMM,WGS 84*06
You may not see all the variables listed here, as not all of them are important and some of them can be turned off with the SNSRCFG utility without any adverse impact. The only ones you definitely need, I think, are GPRMC and GPGGA.
You should see a new screenful of these variables approximately every second; it should scroll pretty much continuously.
If the GPS does not seem to output this data, look at David Taylor's web page (in the sources section) and search for the heading named "An oddity"—your device might be misconfigured from the factory, but easily fixable.
For debugging purposes, the important data is on the line starting with "$GPGGA". Here it is again:
$GPGGA,022708,3303.6672,N,09640.3395,W,1,04,2.1,214.0,M,-24.9,M,,*72
- 022708: this is the UTC time: 02:27:08 +0000. Keep in mind that this time alone is not precise enough for our needs; we will combine it with the PPS signal.
- 1: any value greater than zero means that a position fix was attained. If this value is zero, the GPS will still output position coordinates, but don't trust them.
- 04: the number of satellites that the GPS has locked onto. This is always a two-digit number, even when 00.
Note, though, that LinuxPPS uses the $GPRMC line to extract the UTC time.
Before beginning to set up and configure NTP software, your hardware must be operational.
- Is the power LED on? Measure the voltage between V_in and GND_1 or GND_2 on your six-pin (GPS<->PCB) connector and verify that it is 5.0 V, or at least between 4.0 V and 5.5 V (according to the Technical Specification).
- Can a properly-configured terminal emulator see flowing NMEA traffic?
- Can the GPS see satellites? Mine, sitting on a first-story window ledge about three inches from the wall and under a two-foot brim of the roof, can see three to five. Inside, behind the glass, though, it cannot see any. Be inventive until the GPS can see at least three (in my opinion; anyone to refute this?) satellites.
- Is the PPS LED flashing every second? If you did not wire up the PPS LED, you can check cat /proc/pps/00/* for assert and clear info.
If any of these conditions are not fulfilled, find the problem; as-is, it will probably not work.
For the ultimate precision, *BSD is preferred—it supports nanosecond precision. However, the microsecond precision that Linux provides is sufficient: nanosecond precision is not really necessary, in my opinion, when network conditions add a significant fraction of a millisecond of latency event on a LAN.
Three factors caused me to choose Linux 2.6 as my timekeeping operating system:
- preference of a modern, well-maintained kernel: I'd rather not downgrade to Linux 2.4 or below
- familiarity with Linux 2.6, since that's what I use; I'd rather not learn *BSD just for the sake of nanosecond precision
- diminishing returns: I don't need nanosecond precision to serve "accurate" time over a network.
This document covers only Linux 2.6.
The gold standard is the NTP Reference Implementation from the NTP (R&D) Project at the University Of Delaware, commonly known as just ntpd. There are others, including the young OpenNTPD, but I am not familiar with these others.
This document covers only the NTP Reference Implementation version 4, and I'll refer to it as just "ntpd" from now on.
You must decide what method to use to read the PPS signal (and possibly the GPS time in addition) from the device; this method will be used to configure ntpd.
There are at least three popular methods:
| Method | Supports PPS? | Supports GPS time? | Requires a daemon? | Requires patching? | Serial connectivity supported |
|---|
| LinuxPPS | Yes | Yes | No | Yes | for now, 8250 only |
| shmpps | Yes | No | Yes | No | any |
| gpsd | Yes | Yes | Yes | No | any |
What is the difference between PPS
and GPS time
? PPS is simply an electrical signal pulsed by the GPS unit once a second. It very precisely indicates the start of a second. GPS time
is the actual time of day, such as 12:34:56 UTC, that is provided in NMEA data as described in an earlier section. The downside of the GPS time is that it is much less precise than PPS, and so a PC that's attempting to synchronize with just NMEA data may be off by hundreds of milliseconds without knowing it. This is why it is important to combine the GPS time with the PPS signal, or use just the PPS signal from the GPS and acquire time-of-day from other sources such as Internet hosts.
On my system, LinuxPPS and shmpps are interchangeable when it comes to accuracy, sensitivity to system activity, etc.—both offer about a 0.004 ms mean jitter, and 0.000 ms constant delay. So, decide on your serial connectivity and the desire to run a daemon, patch software, and read GPS time.
This document covers LinuxPPS and shmpps. I could not get gpsd to read PPS for me, so cannot personally vouch for it.
Select which method most suits your situation, then proceed to the respective section.
To take advantage of this method of getting time from your GPS, the operating system must support the Pulse Per Second API (RFCs 1589 and 2783). *BSD has native support for this, I think, and Linux can get support for it through patching: Linux 2.4 has the popular PPSkit patch, and Linux 2.6 has a Rodolfo Giometti's LinuxPPS patches (git repo). These patches affect the Linux kernel.
The LinuxPPS architecture allows multiple clients
to feed PPS data into the kernel. For now there is only one client (not including the dummy testing client): for 8250-compliant serial ports. Anyone is welcome to write clients to receive PPS from other devices. For more information, see the LinuxPPS webpage. Meanwhile, however, if you don't have an 8250-compliant serial port and don't want to write a new client, you cannot use this driver.
You must patch the kernel, and compile it with 8250 serial driver support, PPS core, and PPS 8250 enhancement support; your choice of compiled-in or as modules. Specifically, you must have the following enabled in your kernel configuration: CONFIG_SERIAL_8250, CONFIG_PPS, and CONFIG_PPS_CLIENT_8250. Debug support is optional.
Once you reboot with a PPS-enabled kernel and load the pps-core and 8250 modules, you must be able to see similar-looking results in kernel logs (dmesg):
drivers/pps/procfs.c: procfs enabled
drivers/pps/pps.c: LinuxPPS API ver. 2 registered
drivers/pps/pps.c: Software ver. 2.1.0 - Copyright 2005-2006 Rodolfo Giometti
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
And you must see similar-looking results:
$ cat /proc/pps/sources
id mode echo name path
---- ------ ---- ---------------- ----------------
00 1133 no pps_8250_0 /dev/ttyS0
01 1133 no pps_8250_1 /dev/ttyS1
02 1133 no pps_8250_2 /dev/ttyS2
03 1133 no pps_8250_3 /dev/ttyS3
The number of lines depends on the number of serial lines you specified in the kernel configuration. If you see these names instead of an empty list, it means your kernel is ready to receive the PPS signal over your 8250 serial lines.
If you had enabled debug support for PPS in the kernel, you will see multiple messages in kernel logs every second; it should look similar to this:
"pps_core":"pps"[82]: New message from PID 13131 (flags 0)
"pps_core":"pps"[189]: PPS_FETCH: source 0
"pps_core":"kapi"[158]: capture clear seq #23664 for source 0
"8250":"8250"[1273]: serial8250: PPS clear event at 25520476
"pps_core":"kapi"[147]: capture assert seq #23665 for source 0
"8250":"8250"[1269]: serial8250: PPS assert event at 25521276
"pps_core":"kapi"[158]: capture clear seq #23665 for source 0
"8250":"8250"[1273]: serial8250: PPS clear event at 25521476
"pps_core":"kapi"[147]: capture assert seq #23666 for source 0
"8250":"8250"[1269]: serial8250: PPS assert event at 25522276
"pps_core":"pps"[82]: New message from PID 13131 (flags 0)
"pps_core":"pps"[189]: PPS_FETCH: source 0
"pps_core":"kapi"[158]: capture clear seq #23666 for source 0
"8250":"8250"[1273]: serial8250: PPS clear event at 25522476
"pps_core":"kapi"[147]: capture assert seq #23667 for source 0
"8250":"8250"[1269]: serial8250: PPS assert event at 25523277
"pps_core":"kapi"[158]: capture clear seq #23667 for source 0
"8250":"8250"[1273]: serial8250: PPS clear event at 25523477
"pps_core":"kapi"[147]: capture assert seq #23668 for source 0
"8250":"8250"[1269]: serial8250: PPS assert event at 25524277
I do not have compilation instructions for the latest versions of software, as I do not currently have the hardware to test it. Please refer to the LinuxPPS wiki for the latest instructions.
Once you start ntpd, you will see the following in your system logs:
refclock: found PPS source #0 "/dev/ttyS0" on "pps_8250_0"
refclock_nmea: time_pps_kcbind failed: Operation not supported
Do not be alarmed; this is normal and just means that LinuxPPS does not support this function. It is defined to be optional in the PPS API RFC.
Add the following three lines to your ntp.conf:
# LinuxPPS: GPS + PPS
server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 flag3 1 flag2 0
Unlike with the shmpps driver, you do not have to specify other servers in your configuration file: the NMEA driver which you patched earlier collects both the GPS time from the raw NMEA data, and the PPS signal from LinuxPPS. Here's ASCII art from Rodolfo:
-------+ +------------+
+-- TX/RX --+ /dev/ttyS0 +-----+
| +------------+ | +-------------+
RSR232 | +--+ NMEA driver |
| +------------+ | +-------------+
+--- DCD ---+ LinuxPPS +-----+
-------+ +------------+
Of course, additional servers are always recommended.
If ntpd stops synchronizing with your GPS (when
> poll
) and you see the following in the logs:
clock GPS_NMEA(0) event 'clk_fault' (0x03)
...then your reception is too poor to see enough satellites, so LinuxPPS stopped relaying the PPS signal, and ntpd is going to temporarily select another system peer. You can confirm the poor reception by running ntpd with the -d (debug) switch and analyzing the NMEA data that will be displayed on the screen. My GPS always either sees 3-6 satellites or 0 satellites, so I don't know the exact cutoff for clk_faults.
Once the GPS reacquires enough satellites for proper functionality, ntpd will switch back to the GPS as its system peer.
Note: this is distinct from the SHM driver which comes with ntpd.
Richard Leach provided me with a version of David J. Schwartz's SHM PPS driver; the former got it from Steven Bjork's site.
This driver worked for me without any changes. I made some minor cosmetic changes, such as better feedback in the initialization script, but none of that is necessary for functionality.
Get the driver (last update: 2006-04-29), compile it by typing make, verify that ntpd is running, and—if you're using a serial port known as ttyS0—just run ./start.sh, or if your setup is different, pass the appropriate parameters to the shmpps starter shell script.
This driver package has two parts: the shell script that reiterates every 64 seconds until the ntpd conditions are favorable and then starts the driver, and the actual driver which is started by the shell script. start.sh is a one-liner I've written to merely call the first shell script with the necessary parameters.
Sample good output after just starting ntpd:
# ./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c -D
This script will verify that NTP peer conditions are favorable to starting the shmpps driver.
There will be a 64-second delay between each sample, so this may take over five minutes.
Sun Apr 9 10:33:27 CDT 2006: ntpd has not yet established a system peer. Sleeping.
Sun Apr 9 10:34:31 CDT 2006: ntpd has not yet established a system peer. Sleeping.
Sun Apr 9 10:35:35 CDT 2006: ntpd has not yet established a system peer. Sleeping.
Sun Apr 9 10:36:39 CDT 2006: Good, system peer's offset is 9.002 ms. We will sample 3 more times.
Sun Apr 9 10:37:43 CDT 2006: Good, system peer's offset is 7.154 ms. We will sample 2 more times.
Sun Apr 9 10:38:47 CDT 2006: Good, system peer's offset is 7.154 ms. We will sample 1 more times.
Sun Apr 9 10:39:51 CDT 2006: Good, system peer's offset is 7.154 ms. We will sample 0 more times.
Starting SHM PPC (-d /dev/ttyS0 -s -l DCD -u 0 -c -D) now that time sync has been achieved!
./shm_splc2 device /dev/ttyS0 nodive 1 flap 0 serial 1 parallel 0 hitolow 1 unit 0 signal DCD
shmat ok
range:4-11 sys:1144597205/3044 ref:1144597205/0 prec: -11
range:5-12 sys:1144597219/3310 ref:1144597219/0 prec: -11
range:5-12 sys:1144597233/3546 ref:1144597233/0 prec: -12
range:3-10 sys:1144597247/3739 ref:1144597247/0 prec: -12
range:3-10 sys:1144597261/3954 ref:1144597261/0 prec: -13
range:5-12 sys:1144597275/4158 ref:1144597275/0 prec: -13
range:4-11 sys:1144597289/4042 ref:1144597289/0 prec: -14
range:2-9 sys:1144597303/3801 ref:1144597303/0 prec: -14
range:4-11 sys:1144597317/3619 ref:1144597317/0 prec: -14
Parameters explained: "-d" is the device, in our case the first recognized serial port; "-s" to indicate that it is a serial rather than a parallel port; "-l" is the pin on which the PPS signal comes in; in our case data carrier detect; "-u" is to give a unique number to this device in case our server samples multiple PPS signals; "-c" to specify high-to-low rather than low-to-high; "-D" to enable debug information. With these settings the driver will run in the foreground and output diagnostic data. Once you are satisfied with its operation, removing "-D" will silence and background the driver.
The "high-to-low" setting deserves special mention: it means that the start of a second is defined by the PPS line going from high to low; i.e. the LED turning off rather than turning on. This is apparently the standard behavior for GPS devices. If you do not enable this option when your device requires it, your GPS clock will appear to be over 100 or 200 ms (depending on PPS length) off, as opposed to the regular 10-50 μs offset of a properly-configured device. So, if you find your device steadily remaining in the 100-300 ms offset range, check this option. Do not simply adjust for this offset in ntpd.conf! Reading a voltage drop instead of a voltage rise introduces extra uncertainty because the drop occurs much more gradually than a rise.
The starter shell script will continue sleeping until conditions are favorable and sustained. By default it is for four samples spaced 64 seconds apart. "Favorable" is defined in the shell script as being within 250 ms of the system peer.
Once conditions are favorable and stable, the driver is launched. This listens for the PPS signal on the serial line and provides ntpd the necessary info to adjust the clock based on this signal. 3044, 3310, 3546, and 3739 in the top four sample lines above indicate the offset, in microseconds, of the PC clock from the perfect time. There are two extremes: low numbers like this (one to five digits), and high numbers in the nine-hundred-thousands, such as 997076. When it's a high number, the driver subtracts 1 whole second from it to get a negative low number. For example, 997076 – 1000000 = –2924, or –2.924 milliseconds off.
"out of range" messages coming from the shmpps driver mean that your clock's offset from the PPS signal is significant. "Significant" is determined by "TOLERANCE", a constant defined in the shmpps driver's source code (50 ms by default).
(You might be wondering why in the example above the offset is increasing at first after starting the shmpps driver. It is because the system peer that was established before the shmpps driver started was directing the clock to be adjusted in the opposite direction of PPS, so ntpd was gradually pushing the clock away from the true second boundary. Once shmpps became available to ntpd, it became the new system peer and ntpd changed its mind about which way the clock should go.)
ntpd must be patched and compiled with at least: --disable-all-clocks --disable-parse-clocks --enable-SHM --enable-linuxcaps.
Add the following three lines to your ntp.conf:
# SHM: PPS filtered mean
server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag3 1
You must retain "server" lines to pull time from other Internet servers—the shmpps driver provides only the PPS signal without the GPS time, so in absence of Internet servers or other time sources, ntpd will have no idea what time it is.
The following ntp.conf should not be used verbatim, but shows the way to incorporate the drivers into the configuration.
restrict default nomodify
restrict 127.0.0.1
# Required for shmpps, optional for LinuxPPS
server server1
server server2
server server3
# LinuxPPS: GPS + PPS (comment out either this whole section or the next one)
server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 flag3 1 flag2 0
# SHM: PPS filtered mean (comment out either this whole section or the previous one)
server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag3 1
driftfile /var/lib/ntp/ntp.drift
After configuring my stratum-1 machine with other randomly-selected NTP pool servers ([0-2].us.pool.ntp.org) for reference, here are some outputs:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*SHM(0) .PPS. 0 l 13 16 377 0.000 -0.015 0.004
-kargad.cerias.p 128.10.252.6 2 u 11 64 277 47.858 5.817 1.008
+ns1.dns.pciwest 204.123.2.5 2 u 2 64 377 75.433 4.929 1.811
+c-24-130-207-18 .GPS. 1 u - 64 377 44.461 1.580 5.223
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 0 l 13 16 377 0.000 -0.015 0.004
-router 209.223.236.234 3 u 2 16 377 0.914 1.746 0.023
+qnan.org 192.5.41.41 2 u 39 64 377 9.491 1.731 1.225
+ns3.dns.pciwest 132.163.4.103 2 u 60 64 377 70.166 2.060 3.044
-snugharbor.com 66.102.105.230 4 u 18 64 377 59.890 7.674 127.291
-titanium.netize 171.35.183.255 2 u 20 64 377 87.573 -47.432 17.616
A negative offset means that the PC is faster than perfect; a positive offset means that the PC is lagging behind. The negative of this value would be reflected in ntpq -p after the ntpd samples the driver: ntpq's "offset" is described as "the difference between the server system time (which is the time distributed) and the NTP-time (the time steered to the external UTC-traceable clocks)."
Reach for the GPS should always be 377: it is eight ones in binary, meaning the latest eight consecutive samples were successful.
After some minutes or hours of sampling your GPS, the system time will be adjusted to match the PPS output, and you should expect the absolute value of your offsets to be below 20 microseconds (0.020 ms).
# ntpdc -c kern
ntpdc -c kern
pll offset: -2.1e-05 s
pll frequency: -162.954 ppm
maximum error: 0.00231 s
estimated error: 8e-06 s
status: 0001 pll
pll time constant: 6
precision: 1e-06 s
frequency tolerance: 512 ppm
pps frequency: 0.000 ppm
pps stability: 512.000 ppm
pps jitter: 0.0002 s
calibration interval: 4 s
calibration cycles: 0
jitter exceeded: 0
stability exceeded: 0
calibration errors: 0
I do not really know what any of this means, other than the fact that we do not support nanosecond precision and we do not have errors. Excellent.
The choice of driver (LinuxPPS versus shmpps) does not introduce any significant change in either display.
The following resources provided very welcome help in designing and implementing this project:
Thanks to David Taylor, Udo van den Heuvel, Richard Leach, Mike Crist, Philip Balister, and Dustin Bray for personally helping to make this project a success.
Ironically, this server—although an upstanding member of the NTP pool—does not utilize the GPS for its synchronization. It is in a colocation facility with no view of the sky. The only place where I can take advantage of this setup is at home, where I have a dynamic IP address. So, I shall live vicariously through others' successes with GPS!
If you have any questions, corrections, or other feedback, please contact me. The Timekeepers list is also incredibly helpful.
This work is licensed under a Creative Commons Attribution 2.5 License.