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.
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.
> 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.
> 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
_______________________________________________
Linuxptp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
