[time-nuts] thunderbolt for ntpd or gpsd

[Tim Cwik]

Chris Kuethe wrote:
> On Sun, Jun 15, 2008 at 2:57 PM, Tim Cwik <timenuts at stnhbr.com> wrote:
>   
>> I have discovered the even though cgps does not report position or time
>> using the Thunderbolt, the stock gpsd is getting enough timing data to
>> update ntp. Gpsd is selected as the sys.peer with a jitter of about .8.
>> It looks like the PPS pulse is too narrow to be detected on DCD
>>     
>
> as i've now got my thunderbolt i can start adding support for it in
> gpsd. wayne knowles did a nice patch which i'm using as the foundation
> of my development.
>
> the main issue is auto-detecting parity of the serial line since
> trimble couldn't make up their minds about 8N1 or 8O1.
>
> i've noticed two primary complaints (with which i agree) - the PPS
> output is too short and positions don't seem to be output by default.
> i'm probably going to add an initializer to make the thunderbolt emit
> position data and crank up the 1PPS pulse length to something
> reasonable - at least 1ms. the change will be purely runtime - i won't
> write it to EEPROM. does that seem reasonable?
>
>   
It seems reasonable to me. I think the PPS from the stock unit is also 
the wrong polarity. I have been using Wayne's patch and the FATPPS 
circuit from TAPR to stretch and invert the PPS signal and seem to be 
getting good results. The patch decodes the TB super packet and does 
output positions. For some reason, the clock SHM(0) is not used by NTP 
although the PPS output SHM(1) is.

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 33509  9314   yes   yes  none   outlyer   reachable  1
  2 33510  9334   yes   yes  none   outlyer   reachable  3
  3 33511  9114   yes   yes  none falsetick   reachable  1
  4 33512  9414   yes   yes  none  candidat   reachable  1
  5 33513  9414   yes   yes  none  candidat   reachable  1
  6 33514  8015   yes   yes  none    reject  clock expt  1
  7 33515  9614   yes   yes  none  sys.peer   reachable  1
  8 33516  9014   yes   yes  none    reject   reachable  1

     remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
-216-55-159-183. 130.126.24.44    3 u  110   64  376   84.945   23.379  
76.554
-quandary.cross- 132.239.1.6      2 u   14   64  367   88.128   25.749  
83.158
xlashiir.sapros. 64.22.120.68     3 u   58   64  377   62.578  -13.184  
63.982
+clock3.redhat.c .CDMA.           1 u   60   64  377   93.040   17.595  
55.080
+octopus.stnhbr. .GPS1.           1 u    9   64  377    0.294   34.395   
5.584
 SHM(0)          .GPS.            0 l    -   16    0    0.000    0.000   
0.001
*SHM(1)          .GPS1.           0 l   17   16  377    0.000   -0.019   
0.071
 LOCAL(0)        .LOCL.          10 l   55   64  377    0.000    0.000   
0.001

Would it be violating the design spirit of gpsd to ask for some sort of 
separate status file to be (over)written each second with the 
information about the internal state of the Thunderbolt (e.g., 
http://www.ko4bb.com/dokuwiki/doku.php?id=precision_timing:states_modes_and_alarms 
) I would like to be able to monitor this with something like Hobbit, 
Nagios, or Big Brother. If I set the debug level high enough, the 
information might be in the log but that would generate very large log 
files.

Thanks for working on this.

Tim