Thanks for your reply Gary. I found out from a couple of posts on the EEVBlog forum that the particular BG7TBL GPSDO unit I have contains a fake u-blox NEO-7m device and will not respond to certain commands sent to it.
As for the Trimble, it is a ThunderBolt unit from 2003. As it has been a good unit for a 10 MHz reference and pretty good for an NTP implementation, I'll keep it in service a while longer.
I have however started to look at refurbished Symmetricom SyncServer 1520R and Spectracom 9183 time servers, as well as some new GPS devices containing more recent u-blox devices in them (which are also attractive as they run on 12v from my solar system).
I'll try the gpsdebuginfo tool as it sounds interesting.
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Apr 2021 12:59:59 -0700
From: "Gary E. Miller" <
gem@rellim.com>
To:
gpsd-users@nongnu.org
Subject: Re: PPS issue on Ubuntu 20.04 server
Message-ID: <
20210425125959.6f8e4db1@spidey.rellim.com" target="_blank">
20210425125959.6f8e4db1@spidey.rellim.com>
Content-Type: text/plain; charset="utf-8"
Yo Russ!
On Sun, 25 Apr 2021 12:31:10 -0500
Russ Ramirez <
russ.ramirez@gmail.com> wrote:
> I am in the process of migrating my Trimble gps based NTP server from
> Windows to Linux.
Interesting. Which Trimble? The devil is in the details.
> For testing purposes, I am using an NMEA gps box, the BG7TBL unit
> with a u-blox NEO 7m.
WHy a 7? Much better GPSDO now.
> When I run the pps-tools ppscheck /dev/ttyS0, I
> see CTS asserting, which is the RS-232 line this gps unit ties to PPS
> (see attached png).
Good.
> However, when I run ppstest /dev/pps0 I receive
> time_pps_fetch() error -1 (Connection timed out).
Hard to say without details. What kind of hardware? PC? Mac? RasPi?
"connection timeed out" just means no PPS was seen on your /dev/pps0.
Many things can cause that.
Rather then us playing 20 quesionts, please run this script and reply
here with the output it shows you:
https://gpsd.io/gpsdebuginfo
> As such when I
> check chronyc sources, the PPS is registering as a source, but w/o
> data, i.e. Reach of 0 and LastRx of '-'.
Since this is the gpsd users list, it should be no surprise that here
we think that gpsd should be managing the PPS, and not chronyd. Then
gpsd passes the massaged PPS time to chronyd, or ntpd.
> How can I check that the linux PPS configuration to ensure it is not
> expecting DCD assertion or that pps0 is configured as a ldisc source?
KPPS (RFC2783) does not care which line is in use. gpsd prefers to use
KPPS, but will fall back to TIOCMIWAIT if it can and then gpsd looks at
all the possible inputs.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <
https://lists.nongnu.org/archive/html/gpsd-users/attachments/20210425/7b6c3d2d/attachment.sig>
------------------------------