[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-users
Subject:    Re: [Gpsd-users] Direct access to PPS transition time
From:       Wouter Pelgrum <wouter () pelgrum ! org>
Date:       2011-08-27 3:21:58
Message-ID: 816E7DCB-2081-4795-AC00-87455917C0AE () pelgrum ! org
[Download RAW message or body]


On Friday Aug 26 2011, at 07:25:21, Roger Oberholtzer wrote:

> On Thu, 2011-08-25 at 20:58 -0400, Wouter Pelgrum wrote:
> > Hi,
> > 
> > I got gpsd to work with ntpd (thanks Gary!), but I'm running into some occasional \
> > startup issues.  The computer that needs the time sync is not connected to \
> > internet, and I need precise time quickly after startup. ntpd sometimes \
> > complains, and requires some time to lock & align with the 1PPS time.  
> > Assuming the 1PPS is correct, and the NTPD-provided time not always, the \
> > provision of the offset between the two would work. In post processing (I'm \
> > time-tagging sensor data, not a real problem to adjust the time stamps later) I \
> > can then correct for the time offsets, after outlier detection and filtering of \
> > the offset values. 
> > I can get that offset via ntpq -p, but that's not a call I can embed in my c \
> > application. I tried ntp_adjtime() but that function doesn't output a correct \
> > offset value if ntpd is in error state. (Also, ntp_adjtime() and ntp_gettime() \
> > seem to sometimes report in ns, and other times in us) 
> > Is there a way to get the 1PPS info from GPSD, similar to how NTPD is getting the \
> > information? 
> > Or is there a way to get ntpd to startup more reliably and converge faster?
> 
> Please post your findings. I am starting the exact same thing. In a
> vehicle without internet I want to have the PC time set, as close as
> possible, to the current GPS time. Other devices I have do the same.

So far the NovAtel + gpsd + chrony setup seems to work pretty good. I've tested it \
only in the lab, and with many reboots, but not yet with long power-offs.  I have to \
dive a little bit deeper in the chrony config to see what the best options are for \
that.

> Currently I compute the difference between PC and GPS time, using the
> PPS signal and the ZDA record in my own C code. I too want to drop that
> in favor of gpsd.

What I really like of the gpsd - chrony combi is that I can log the offsets between \
1PPS and PC time so I can correct things later if I want.  \
===============================================================================  Date \
(UTC) Time         Refid  DP L P  Raw offset   Cooked offset      Disp. \
=============================================================================== \
2011-08-27 03:07:19.999998 PPSp    0 N 0  1.746000e-06  2.023000e-06  6.109e-06 \
2011-08-27 03:07:20.999997 PPSp    1 N 0  3.324000e-06  3.532000e-06  6.109e-06 \
2011-08-27 03:07:22.000001 PPSp    2 N 0 -1.410000e-06 -1.254000e-06  6.092e-06 \
2011-08-27 03:07:22.999977 PPSp    3 N 0  2.282900e-05  2.294600e-05  6.079e-06

> The thing I have been worrying about is if the systems are started when
> there is no GPS available, like in a garage. Then, I would imagine the
> time is whatever the GPS receiver maintained. When the satellites come
> in to view, this may change. How quickly is that seen in the PC time? I
> do not mean how quickly it is seen from the GPS. I mean from when the
> GPS starts reporting it until the PC clock is completely adjusted. I am
> guessing that this initial time difference will be small. But whatever
> it may be, I need to know how the change is introduced into the system.

That's why I switched to chrony, ntpd sucks in this context. 
I have to do more testing to get you numbers, but from what I've seen is that the PC \
clock is adjusted (<1ms) in 10s of seconds.

For my current application I need sub-ms, and that seems very achievable. For other \
applications I would like to push it quite a bit further (I'm rather interested how \
far it can be pushed without dedicated hardware such as a ptp server and ptp-ready \
NICs)

We're also building a robotic platform (quad rotor) with a sensor payload that needs \
to be time-synchronized. I'm opting for that one to not use GPS as the common \
standard, since we want to be able to operate this thing in gps-denied scenarios. So \
I'm thinking about a reference oscillator and a time pulse that is used as the common \
time source to time-tag all sensors (some connected to FPGAs, some to a PC). If GPS \
is available, we'll determine the relation between the reference time and GPS time. \
It's probably easiest if the reference clock remains somewhat close to UTC so we can \
sync the PC to that using a gpsd-chrony combination

I'll keep you posted on the topic,

Wouter







_______________________________________________
Gpsd-users mailing list
Gpsd-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/gpsd-users


[prev in list] [next in list] [prev in thread] [next in thread]