[Linuxptp-users] ts2phc with a GPS and i210-T1

[James C. <jj...@jc...>]

I am experimenting using ts2phc with a GPS module connected to an i210-T1.
I have a question and a bug report.

1. In Richard's helpful guide (
https://linuxptp.sourceforge.net/i210-rework/i210-rework.html), he
describes making this connection via two RS232 transceivers. In my
experiment, I am powering the GPS with a USB-to-TTL converter plugged into
the same PC as the i210-T1 with

- the GND pin of the GPS, the GND pin on the 6-pin header of the i210-T1
and the GND pin of the USB-TTL converter all connected
- the PPS pin of the GPS connected to the SDP0 pin on the i210-T1
- the other GPS pins (TX, RX, VCC) connected to the USB-TTL converter

This seems to work fine, but I am wondering if it risks damaging the PC (I
know very little about the hardware side of things).

2. The GPS pulse width is 0.1s. Since the i210 timestamps both edges, I am
using

ts2phc.extts_polarity both
ts2phc.pulsewidth 100000000

This works great with ts2phc -s generic (with the system clock synchronized
by chrony).  But when I use ts2phc -s nmea, both edges are ignored. The log
looks like this:

Dec 13 21:47:13 fedora ts2phc[5953]: [9098.668] nmea sentence:
GNRMC,144713.000,A,1343.91532,N,10038.69349,E,0.00,0.00,131222,,,A,V
Dec 13 21:47:13 fedora ts2phc[5953]: [9098.748] nmea sentence:
GPTXT,01,01,01,ANTENNA OK
Dec 13 21:47:14 fedora ts2phc[5953]: [9099.354] nmea delay: 313627523 ns
Dec 13 21:47:14 fedora ts2phc[5953]: [9099.354] enp1s0 SKIP extts index 0
at 1670942870.999978485 src 1670942870.686460377
Dec 13 21:47:14 fedora ts2phc[5953]: [9099.454] nmea delay: 313627523 ns
Dec 13 21:47:14 fedora ts2phc[5953]: [9099.454] enp1s0 SKIP extts index 0
at 1670942871.099978644 src 1670942870.786456578
Dec 13 21:47:14 fedora ts2phc[5953]: [9099.675] nmea sentence:
GNRMC,144714.000,A,1343.91532,N,10038.69349,E,0.00,0.00,131222,,,A,V
Dec 13 21:47:14 fedora ts2phc[5953]: [9099.739] nmea sentence:
GPTXT,01,01,01,ANTENNA OK
Dec 13 21:47:15 fedora ts2phc[5953]: [9100.354] nmea delay: 320719950 ns
Dec 13 21:47:15 fedora ts2phc[5953]: [9100.354] enp1s0 SKIP extts index 0
at 1670942871.999978482 src 1670942871.679368362
Dec 13 21:47:15 fedora ts2phc[5953]: [9100.454] nmea delay: 320719950 ns
Dec 13 21:47:15 fedora ts2phc[5953]: [9100.454] enp1s0 SKIP extts index 0
at 1670942872.099978632 src 1670942871.779363564
Dec 13 21:47:15 fedora ts2phc[5953]: [9100.682] nmea sentence:
GNRMC,144715.000,A,1343.91532,N,10038.69349,E,0.00,0.00,131222,,,A,V
Dec 13 21:47:15 fedora ts2phc[5953]: [9100.762] nmea sentence:
GPTXT,01,01,01,ANTENNA OK
Dec 13 21:47:16 fedora ts2phc[5953]: [9101.354] nmea delay: 328011876 ns
Dec 13 21:47:16 fedora ts2phc[5953]: [9101.354] enp1s0 SKIP extts index 0
at 1670942872.999978478 src 1670942872.672071554
Dec 13 21:47:16 fedora ts2phc[5953]: [9101.454] nmea delay: 328011876 ns
Dec 13 21:47:16 fedora ts2phc[5953]: [9101.454] enp1s0 SKIP extts index 0
at 1670942873.099978629 src 1670942872.772072077

I have tried both 3.1.1 and the current git source.

I had a look at the source, and it is not clear to me that the current
approach can work in the nmea case. I wonder if we could decide whether to
ignore an edge by considering the time elapsed since the previous edge.
This won't work if the pulsewidth is close to 0.5s, but the most common
default pulsewidth for GPS modules seems to be 0.1s.

James