Was hoping to see some responses on these questions. Anything?
On Tue, Feb 22, 2022 at 1:50 PM David Jedynak <sileasresea...@gmail.com> 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?
>
> 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
