Chris Kuethe wrote: > On Tue, Jun 10, 2008 at 3:40 PM, Tim Cwik <[EMAIL PROTECTED]> wrote: > >> Are there timekeeping preferences between using the thunderbolt as a ref >> clock for ntpd or connecting it to gpsd and using the gpsd to ntpd >> capability? Running gpsd is one more process to manage but does give >> access to the gps infomation on the network. >> > > If you're running OpenBSD, you can use ldattach to get the kernel to > monitor the serial port for PPS, and then relay the positioning and > UTC data to userland via a pty. Then feed gpsd from this pty. Use the > system ntpd sync the clock. > > >> In either case, what is the preferred method of feeding the 1PPS signal >> to the server? The Thunderbolt manual does not show 1PPS on the serial >> port. I have not yet opened the case to look. Do people commonly make >> this connection inside the case or is it better to make a cable with >> serial on one end and serial and a BNC on the other end? >> > > I haven't got a thunderbolt (waiting for my chance to order), but in > past I have built custom cables to get various receivers to present a > standard DB-9 with PPS on DCD or CTS. > Hi Chris,
Thanks for the advice. I am going with a custom cable that will mimic my current Garmin 18lvc. Before building the cable, I connect the Thunderbolt to the server (Centos 5.1 gpsd 2.37) with a plain serial cable. The Thunderbolt seems to operate normally when connected to Tboltmon.exe on a Windows machine but with gpsd, all I see is : ]# gpsd -N -D5 /dev/ttyS1 gpsd: launching (Version 2.37) gpsd: listening on port gpsd gpsd: shmat(0,0,0) succeeded gpsd: shmat(0,0,0) succeeded gpsd: shmat(0,0,0) succeeded gpsd: shmat(0,0,0) succeeded gpsd: running with effective group ID 0 gpsd: running with effective user ID 0 gpsd: opening GPS data source at '/dev/ttyS1' gpsd: speed 9600, 8N1 gpsd: => GPS: $PASHQ,RID*28\x0d gpsd: Navcom: command dump: 0299661c0800040200001203 gpsd: => GPS: 0299661c0800040200001203 gpsd: Navcom: sent command 0x1c (Test Support Block) gpsd: Navcom: command 0x1c mode = 02, length = 0 gpsd: Navcom: command dump: 029966200e000001ae02000071000000f203 gpsd: => GPS: 029966200e000001ae02000071000000f203 gpsd: Navcom: sent command 0x20 (Data Request) - data block id = ae at rate 00 gpsd: Navcom: command dump: 029966200e00000186020a0071000000d003 gpsd: => GPS: 029966200e00000186020a0071000000d003 gpsd: Navcom: sent command 0x20 (Data Request) - data block id = 86 at rate 0a gpsd: garmin_gps not active. gpsd: no probe matched... gpsd: gpsd_activate(0): opened GPS (4) gpsd: packet sniff finds type -1 gpsd: packet sniff finds type -1 gpsd: TSIP pkt_id = 0x8f, packetlen= 0x15 gpsd: packet sniff finds type 4 gpsd: switch_driver(Trimble TSIP) called... gpsd: selecting Trimble TSIP driver... gpsd: ntpd_link_activate: 0 gpsd: speed 9600, 8O1 starting cgps gives:gpsd: client 127.0.0.1 (0) connect on fd 5 gpsd: checking client(0) gpsd: <= client(0): i gpsd: client(0): assigning channel... gpsd: User requires 2, channel type is -1 gpsd: client(0): channel 4 already active. gpsd: => client(0): GPSD,I=Trimble TSIP gpsd: checking client(0) gpsd: <= client(0): w+x gpsd: client(0): channel 4 already active. gpsd: client(0): channel 4 already active. gpsd: => client(0): GPSD,W=1,X=1213284002.648406 gpsd: transfer mask on : 01 gpsd: transfer mask on : 01 gpsd: transfer mask on : 01 gpsd: transfer mask on : 01 .... cgps reports no time, no position, and no fix. I am using the THunderbolt as it was configured when I bought it. I was expecting that gpsd would understand TSIP and the THunderbolt/gpsd combination would act like the Garmin/gpsd combination. Any thoughts on what I might be doing wrong? Thanks, TIm _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.