I decided to look into this interesting unit, both due the the low price, and the fact that nearly all my other refclocks are Motorola Oncores.
The gps18lvc is an OEM model of the Garmin 12-channel/WAAS receiver, packed together with an antenna into a small puck device. The PPS signal is specified as "< 1 us", which means that the stability of the server system clock will determine the actual performance.
At the other end of the (default) 3 m cable there's just a set of colour-coded wires, carrying rs232-level send/receive/ground & pps signals, as well as a pair of (slightly thicker) red/black power supply wires.
I got the gps in a couple of days from a local distributor here in Oslo, and picked up a 9-pin female rs232 connector with housing and a 1 m small-size USB cable: Total cost was less than 1000 NOK, in the US I'm guessing you could get the same for approx $100.
(Google... Yes, it seems like the gps itself is available for about $80!)
I then cut the USB cable and identified the +5V power wires (also red/black coded!), I cut off the USB signaling wires with a small offset between them to avoid any risk of a short circuit.
The only remaining task was to solder the signaling wires onto the rs232 connector:
pin signal colour ---------------------- 1 PPS yellow 2 TX white 3 RX green 5 GND black
and join the remaining red/black wires to the corresponding pair from the USB cable.
After wrapping some electician's tape for insulation around the power lead joins, I carefully fit everthing inside the 9-pin rs232 cap and closed it up.
Total time was less than 2 hours, including the trip to pick up the parts, and it worked immediately:
>>ntpq -c rv -p ntp1
assID=0 status=0464 leap_none, sync_uhf_clock, 6 events, event_peer/strat_chg, version="ntpd 4.2...@1.1431-o Fri Nov 11 11:38:18 UTC 2005 (2)"?, processor="i386", system="FreeBSD/6.0-RELEASE", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdispersion=0.298, peer=9366, refid=GPS, reftime=c7302007.2b87bce7 Thu, Nov 24 2005 12:18:31.170, poll=4, clock=0xc730200a.a6e567d2, state=4, offset=0.010, frequency=29.775, jitter=0.002, noise=0.002, stability=0.000, tai=0 remote refid st t when poll reach delay offset jitter ================================================================ +ntp9.hda.hydro. .GPS. 1 u 2 16 377 0.625 0.023 0.006 -nontp1.hydroisp 136.15 2 u 34 64 377 1.523 0.560 0.287 +nontp2.hydroisp .GPS. 1 u 33 64 377 1.608 0.401 0.092 -nontp4.hydroisp 136.15 2 u 25 64 377 4.424 -0.212 0.975 -nontp5.hydroisp 163.34 2 u 20 64 377 4.446 0.292 1.751 -nontp8.hydroisp .GPS. 1 u 4 64 377 8.628 0.511 8.086 *GPS_NMEA(0) .GPS. 0 l 3 16 377 0.000 0.010 0.002
I'm currently gathering clockstats info on the unit, my current guesstimate would be something like ~5 us RMS time offset.
I used Garmin's SNSRCFG_280.exe program to setup the gps to work in NMEA mode, sending out the most common time/position reports (including GPRMC, which is preferred by the ntpd NMEA driver) once per second.
Using a spare USB plug as the power supply is a particularly nice option, since any PC used as an ntpd server these days will have at least one usch port available!
Terje Mathisen wrote: > I decided to look into this interesting unit, both due the the low > price, and the fact that nearly all my other refclocks are Motorola > Oncores.
> The gps18lvc is an OEM model of the Garmin 12-channel/WAAS receiver, > packed together with an antenna into a small puck device. The PPS > signal > is specified as "< 1 us", which means that the stability of the server > system clock will determine the actual performance. [] > I'm currently gathering clockstats info on the unit, my current > guesstimate would be something like ~5 us RMS time offset. [] > Terje
This looks excellent, Terje. Now, if only there was a Windows driver!
Terje Mathisen wrote: > I decided to look into this interesting unit, both due the the low > price, and the fact that nearly all my other refclocks are Motorola > Oncores.
> The gps18lvc is an OEM model of the Garmin 12-channel/WAAS receiver, > packed together with an antenna into a small puck device. The PPS signal > is specified as "< 1 us", which means that the stability of the server > system clock will determine the actual performance.
> At the other end of the (default) 3 m cable there's just a set of > colour-coded wires, carrying rs232-level send/receive/ground & pps > signals, as well as a pair of (slightly thicker) red/black power supply > wires.
> I got the gps in a couple of days from a local distributor here in Oslo, > and picked up a 9-pin female rs232 connector with housing and a 1 m > small-size USB cable: Total cost was less than 1000 NOK, in the US I'm > guessing you could get the same for approx $100.
> ... > I then cut the USB cable and identified the +5V power wires (also > red/black coded!), I cut off the USB signaling wires with a small offset > between them to avoid any risk of a short circuit.
> The only remaining task was to solder the signaling wires onto the rs232 > connector:
it never occurred to me to use USB power, good idea. I used an old mobile phone charger that happened to output the correct voltage. My unit is over 10m away from the computer room, so I made the connection with CAT5 network cable that terminates in a RJ-45 wall socket, from where a patch cable leads to an RJ45-DB25 adaptor. These adaptors come with 8 pins connected to the RJ-45 socket that can be inserted into any position in the DB25 plug, so it is easy to make nonstandard connections. I drilled a hole for the power leads and soldered them to the phone charger. Works fine for me.
With temperatures stable, jitter can be as low as 0.001ms.
Eugen COCA wrote: > I was interested about how did you connect the PPS signal to the RS232 > interface, say the wardware configuration.
I simply connected the PPS wire (yellow) to the DCD (carrier detect) of the same serial port that receives the data from the Garmin. You have to create a link /dev/pps0 -> /dev/term/b, because the PPS refclock (#22) looks there for the PPS signal.
the connections go like this:
Garmin RJ45 DB25f-Adaptor Sun DB 25
Vin Red 7,5 ws/br,ws/bl gn,br (+5V) Gnd Black 8,1 br,ws/or bl,ws (Gnd)
PPS yellow 2 or or 8 DCD (PPS) Gnd black 4 bl rt 7 Gnd Tx white 3 ws/gn sw 3 Rx (in) Rx green 6 gn ge 2 Tx (out)
the power lines are not connected to the DB25, but to an external power supply. The RJ45-DB25 adaptor is item 12.03.8030 from rotronic, <http://shop.rotronic.ch/>
For setting up the Garmin, the DB25 is conntected via an adaptor to the DB9 port of a laptop running Garmin's SNSRCFG tool. This is also how I updated the firmware.
>>Any indication about connecting the PPS signal and setting up the ntpd >>service to work with ?
>>Thank you !
>>P.S. I think the 1 us jitter is true only if using the PPS signal.
> I did configure the PPS device in addition to the NMEA refclock, > but it does not give me any additional accuracy. > this "ntpq -p" output is typical:
> remote refid st t when poll reach delay offset jitter > =========================================================================== === > +GPS_NMEA(0) .GPS. 0 l 25 64 377 0.000 -0.036 0.020 > oPPS(0) .PPS. 0 l 43 64 377 0.000 -0.046 0.030 > ....
> configured as:
> server 127.127.20.0 mode 2 prefer > server 127.127.22.0 > fudge 127.127.22.1 flag3 1
The NMEA driver (20) has PPS code built in so you don't need the stand alone PPS driver (22) - that's why you don't see any difference. If you remove the link to pps0 from /dev and restart ntpd you'll see the non PPS results (not even close to the PPS numbers).
John (also using a GPS18LVC) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32)
> The NMEA driver (20) has PPS code built in so you don't need the stand > alone PPS driver (22) - that's why you don't see any difference. If > you remove the link to pps0 from /dev and restart ntpd you'll see the > non PPS results (not even close to the PPS numbers).
I don't think you need even the /dev/pps0 link/device:
The NMEA driver assumes that a PPS signal will be on the DCD pin (if available), and uses it automatically:
ntp1# ls -la /dev/pps* ls: No match. ntp1# ls -la /dev/gps* lrwxr-xr-x 1 root wheel 10 Nov 23 14:07 /dev/gps0 -> /dev/cuad0 ntp1# ntpq -p remote refid st t when poll reach delay offset jitter =========================================================================== === +ntp9.hda.hydro. .GPS. 1 u 7 16 377 0.673 0.018 0.013 -nontp1.hydroisp 136.15 2 u 22 64 377 1.398 0.537 0.202 -nontp2.hydroisp .GPS. 1 u 53 64 377 1.513 0.353 0.053 +nontp8.hydroisp .GPS. 1 u 46 64 377 8.108 0.230 5.128 *GPS_NMEA(0) .GPS. 0 l 3 16 377 0.000 -0.004 0.002
ntp9 is located on the same LAN segment, while the other servers are behind firewalls, and (as seen from the delay values) even on the other side of the country.
Terje
-- - <Terje.Mathi...@hda.hydro.com> "almost all programming can be viewed as an exercise in caching"