[ntp:questions] Pi 4 and Ultimate hat weirdness
jimp at gonzo.specsol.net
Mon Jan 25 16:33:26 UTC 2021
On Mon, Jan 25, 2021 at 11:03:46AM +0000, David Taylor wrote:
> On 25/01/2021 02:06, Jim Pennino wrote:
> > I got a Pi 4 and Adafruit ultimate gps hat to play with and decided to see
> > how good it was as a timekeeper.
> > First weird thing; xgps does not show a skyview but both xgps and cgps
> > show at least 10 satellites in use.
> > I don't care too much about this one as AFAIK xgps is broken on Pi.
> > Second weird thing; I started the 20 driver in mode 0. ntpq showed lots
> > of syntax errors on the $GPGGA message.
> > I changed the mode to 29 to deselect $GPGGA; no errors from ntpq. So maybe
> > it was a satellite thing, but whatever it was, no more errors.
> > Third and biggest weird thing; I had fudge 127.127.20.0 flag1 1 time1 0.001
> > in ntp.conf. After everything settled down, the clock was showing an
> > offset of -1043. OK, So I changed time1 to 1.044 even though it looked
> > too big. ntp wouldn't lie to me...
> > After everything settled down this time the offset was showing an average
> > of -738. For grins and giggles I set time1 to 0.738 and now the average
> > offset is -584.
> > time1 offset
> > 0.001 -1043
> > 1.044 -738
> > 0.738 -584
> > It seems there is no way to get time1 to correct the offset.
> > Also the jitter times look high. At this moment ntpq shows:
> > xGPS_NMEA(0) .GPS. 0 l 6 16 367 0.000 -849.36 25.536
> > *SHM(0) .SHM. 0 l 4 16 377 0.000 -106.55 72.688
> > xPPS(0) .PPS. 0 l 4 16 377 0.000 18.702 18.812
> > For comparison, a GlobalSat BU-353-S4 USB GPS on a PC ubuntu system shows:
> > *SHM(0) .SHM. 0 l 3 16 377 0.000 -0.728 1.356
> > Anyone got any suggestions other than to trash the Ulitmate hat and get
> > another GlobalSat USB?
> I've been playing with the RPi4 recently and had mostly success. I've
> used a couple of different devices including the Uputronics/ublox HATs.
> GPSD has proved problematical, and the only satisfactory way is not to
> use the one in the distribution, but to build from scratch.
I have tried it without gpsd using just the type 20 and 22 drivers; no
difference in the weird offset that can not be calibrated out.
> It's the PPS which matters, and for that I've found it most satisfactory
> to use the type 22 driver. For time of day I tend to use other local or
> Internet servers. I've been experimenting with an RTC, but
> experimenting with its unstabilised drift first to understand how well
> it might behave left for a day, week or month.
One of the reasons for trying the ultimate hat is the on board, battery
backed up, clock so there is some reasonable reference at boot.
But the PPS has a lot of jitter. Note the xPPS(0) in the ntpq line.
> Offsets near 1 second introduce an ambiguity and I would suggest
> avoiding such devices. However, I would expect the AdaFruit to be good
> - have you set a sufficiently high baud rate? Recent ublox are being
> set to 115200 to capture all the data. IIRC, $GPRMC alone is enough.
The default for NTP is 4800 baud, but I am running at 9600 and there is
no loss of data.
It doesn't make any difference if I run the 20 driver in mode 1 (lower
bits) or 13, it still has the uncorrectable offset problem.
Right now, having been running for a little over 12 hours, ntpq shows:
x127.127.20.0 .GPS. 0 l 14 16 335 0.000 -761.21 307.138
*127.127.28.0 .SHM. 0 l 12 16 377 0.000 -30.575 35.029
o127.127.22.0 .PPS. 0 l 3 16 377 0.000 -0.378 0.034
I'm going to let it run for several days without disturbing anything.
I doubt it will keep the 28 clock selected with that high jitter.
> Just some random thoughts, not a definitive solution!
> SatSignal Software - Quality software for you
> Web: https://www.satsignal.eu
> Email: david-taylor at blueyonder.co.uk
> Twitter: @gm8arv
> questions mailing list
> questions at lists.ntp.org
More information about the questions