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