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?
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? 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?
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?)? 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?
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. See
my question about direction in #2 (linux clocks as source or the time
in the PHC as source)
Assumption #4: Prior to the NMEA stuff in ts2phc, I thought the way to
do this was to have a gps program (gpsd 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
("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?
Assumption #5: Now that ts2phc has a NMEA option in it, does it now
set the ToD in the PHC directly? 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?
Hopefully this can help drive clarity for myself or others.
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
