gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More on NMEA time oscillating problem


From: Steven Sommars
Subject: Re: More on NMEA time oscillating problem
Date: Thu, 25 Mar 2021 18:23:42 -0500



On Thu, Mar 25, 2021 at 3:14 PM Gary E. Miller <gem@rellim.com> wrote:

Steven Sommars <stevesommarsntp@gmail.com> wrote:

> My previous description was erroneous, so I'll explain my observations
> again.

What o you think you got wonrg last time?

Last time I said that the tests were made using NMEA time.  Instead these were times reported by gpsd based on some combination of NMEA and binary data.

 
> Baud rate = 9600, except where stated.

Bad.

It's the default for this board and worked previously.   If high rates are required perhaps that should be added to gpsd.8

 
> Host = RPi4.   (GPIO)
> gpsd version varies.   Started directly by root.
>            gpsd [-b] -n /dev/ttyS0 /dev/pps0              # -b used
> for NMEA only tests
> chrony 3.4
>
> refclock SHM 0 delay 0.5 refid NMEA
> refclock SHM 2 offset 0.0  refid PPS

Can you verify no MAGIC_HAT option?

I didn't supply such an option.  However I see:
./gpsd-3.22/include/gpsd_config.h:#define MAGIC_HAT_ENABLE 1
./gpsd-3.22/include/gpsd_config.h:#define MAGIC_HAT_GPS   "/dev/ttyAMA0"
Why would this matter?

This particular pi4 has previously hosted other GPSs, with serial/USB connections.   
Only the Uputronics was connected during these tests.

> Plus two local servers with "noselect"

Bad, no quorum.

It's a valid configuration IMHO, and is necessary in non-networked configurations.
 
> During unrelated debugging, I ran gpsd from git head on March 9, 2021.
> The serial arrival time oscillated.  See plot in offset1.jpg.

Looks "normal".

It surprised me.   You've seen more GPS variants than I have though.

 
> The oscillation was gpsd version dependent: 3.21 was fine.  3.22 (and
> git head) was not.

I depends on a lot more than gpsd version.
gpsd version was the initial trigger.

 
> No manual ublox configuration was done during this time.

But did you reset to factory first?
Not at first.  Later on I did resets, but they did not help.

 
> At 9600 / 19200 baud chrony was in alarm about half the time.  At
> 38,400 baud or higher the alarms went away.

Of course that also means you PPS is broken.

I don't understand why you say PPS is not working.  The Ublox chip has a fix throughout this testing.  The Uputronics LED is happily blinking, except after resets.
ntpshmmon shows both serial and PPS times.
 
> 3.22 (and git head) were fine when gpsd was started with the "-b"
> option.

For some definition of "fine".  You disabled data that others want
enabled.
 
Could be.  NTP is my primary need.
 

All you have proven, again, is that your PPS is not working, your baud
rate is too slow and your chronyd config has no quorum.


Concerned that my misstatement about NMEA sentences could have voided the previous discussion, I presented the issue again.  This time with pretty graphs.

Your statements concerning serial offsets are unambiguous.   Thanks for taking the time to respond (again).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]