[time-nuts] thunderbolt for ntpd or gpsd

Tim Cwik timenuts at stnhbr.com
Thu Jun 12 19:32:48 EDT 2008


Chris Kuethe wrote:
> On Tue, Jun 10, 2008 at 3:40 PM, Tim Cwik <timenuts at stnhbr.com> 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





More information about the time-nuts mailing list