[time-nuts] thunderbolt for ntpd or gpsd
timenuts at stnhbr.com
Tue Jul 15 08:37:28 EDT 2008
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
-216-55-159-183. 18.104.22.168 3 u 110 64 376 84.945 23.379
-quandary.cross- 22.214.171.124 2 u 14 64 367 88.128 25.749
xlashiir.sapros. 126.96.36.199 3 u 58 64 377 62.578 -13.184
+clock3.redhat.c .CDMA. 1 u 60 64 377 93.040 17.595
+octopus.stnhbr. .GPS1. 1 u 9 64 377 0.294 34.395
SHM(0) .GPS. 0 l - 16 0 0.000 0.000
*SHM(1) .GPS1. 0 l 17 16 377 0.000 -0.019
LOCAL(0) .LOCL. 10 l 55 64 377 0.000 0.000
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.,
) 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
Thanks for working on this.
More information about the time-nuts