> -----Original Message-----
> From: Richard Cochran <richardcoch...@gmail.com>
> Sent: Tuesday, March 8, 2022 3:51 PM
> To: David Jedynak <sileasresea...@gmail.com>
> Cc: linuxptp-users@lists.sourceforge.net
> Subject: Re: [Linuxptp-users] GPS + PPS PTP master - confusion about
ts2phc,
> phc2sys, ptp4l options and interdependencies
>
> On Tue, Feb 22, 2022 at 01:50:39PM -0600, David Jedynak wrote:
> > For use case orientation: Embedded system installed on a remote (no
> > internet) infrastructure, receives GPS w/PPS, sets time from power-up
> > (e.g. 1970) and acts as PTP grandmaster for the entire local
> > infrastructure. Hardware includes intel i210 with PPS input to SDP3
> > (this cannot be changed, hardware already exists). Occasional loss of
> > GPS signal for a few seconds (< 10) at a time is expected, but no
> > sophisticated clocks (e.g. TCXO or atomic) needed for better
> > hold-over.
> >
> > General query: With linuxptp 3.1 and newer (since ts2phc was added),
> > it has become a bit confusing how to stitch together all the bits and
> > how they interact. I see a caution in the ts2phc man page about
> > sharing config files and overlapping options. Seems like
> > clarification is needed. Are these assumptions below correct?
>
> You do need to stitch the pieces together yourself, especially things
> like monitoring GPS health/quality are yours to implement.
Sometimes you can use the GPS's ability to squelch the 1PPS out when it
loses track of satellites and monitor ts2phc logs for that purpose.
> WRT configs files: The warning is only there because each program
> might need different options. So the simple way is to provide each
> program its own file.
>
> > Assumption #1: ts2phc and associated config file is how I configure
> > the input (e.g. SDP3 on the i210) and some very basic options
> > regarding pulse width. ts2phc also has a NMEA option - stick a pin in
> > that (see below). ts2phc doesn't seem to have anything for actually
> > configuring servo loops other than some step options. Correct?
>
> No. You can choose the servo too.
Out of curiosity - do you need a servo there? Usually, we put them where we
expect some randomness (PDV in PTP or time read jitter in phc2sys). The
GNSS usually has low jitter and is local to the device and hence doesn't
need much filtering.
> > Is
> > this why ts2phc run all by itself (no phc2sys running) has a bunch of
> > (null) for clock related config items (e.g. "(null).clock_servo",
> > "(null).pi_proportional_cont", etc.)? Am I missing something?
>
> No, that is not the reason, but don't worry about the "null" debug
> message. It doesn't indicate an error.
>
> > Assumption #2: phc2sys and associated config file is how I configure
> > servo loops (how do those interact w/ts2phc that's actually getting
> > the pulses?)?
>
> Well, each program has its own servo.
>
> > It looks like phc2sys is how to link the phc to system
> > time, and there are options for *sys* to set PHC Time of Day, or PHC
> > to set *sys*, depending on the architecture's end goal and use case,
> > right?
>
> Yes. But you don't want to let phc2sys change the PHC. ts2phc will
> take that job.
>
> For a GPS GM, you don't actually need phc2sys at all. It is merely a
> nice-to-have when the Linux system time also follows the GPS.
>
> > Assumption #3: ptp4l and associated config file handles the actual ptp
> > sourcing - configuring the phc's timestamping mechanisms and driving
> > ptp packets across the network, using time of day from a source.
>
> It runs the PTP stack.
Just make sure you configure the correct data set in the config file and
(preferably) change it accordingly when you lose the 1PPS. Currently it's
not automated, but once you implement 1PPS monitoring, you can use
PMC protocol to change it.
> > Assumption #4: Prior to the NMEA stuff in ts2phc, I thought the way to
> > do this was to have a gps program (gpsd
>
> I wouldn't recommend that program at all.
>
> > or equivalent) capture the GPS
> > Time of Day, which is then used to set the local system clock. Then
> > phc2sys is used to push that from the system clock to the phc
>
> No. That introduces unwanted time error.
>
> > ("sys2phc" if you will), and then somehow either phc2sys or ts2phc
> > would align the least significant time digits (e.g. < 1 usec) using
> > the inbound PPS to tweak the PHC clock to be aligned to exactly 1
> > second, by reaching in to the PHC itself and stepping or frequency
> > tweaking. Is that (was that?) correct?
>
> No
>
> > Assumption #5: Now that ts2phc has a NMEA option in it, does it now
> > set the ToD in the PHC directly?
>
> Yes of course. That is the whole point.
>
> > If so, is phc2sys still used to push
> > that GPS-based (via NMEA) time that was pushed into the PHC by ts2phc
> > up to the system? Does it still need to be there for servo config?
>
> No you can omit phc2sys altogether if you don't care about the local
> Linux system time.
>
> You *can* use phc2sys to provide PHC -> CLOCK_REALTIME
>
> HTH,
> Richard
Just make sure you don't use "generic" (aka CLOCK_REALTIME) time source
in ts2phc and phc2sys to transfer the time from the same PHC, as that
creates
the sync loop will end up bad.
The best way is, as Richard suggested, to use NMEA in ts2phc to set time
inside
the PHC, and use phc2sys to transfer that to system time.
Regards
Maciek
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Linuxptp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
