search

opencomputeproject / Time-Appliance-Project

Develop an end-to-end hypothetical reference model, network architectures, precision time tools, performance objectives and the methods to distribute, operate, monitor time synchronization within data center and much more...
MIT License
1.32k stars 101 forks source link

Time in GPZDA on the NMEA serial port is incorrect #70

Open MaciekMachni opened 2 years ago

MaciekMachni commented 2 years ago

The time reported in the $GPZDA NMEA message on the NMEA serial port is incorrect. It returns GPS time instead of UTC.

The upper part shows the G*ZDA message from the Time Card, while the lower - reported by the UBX module (on the UBX serial port)

$GPZDA,144310.00,09,08,2022,00,00*66
$GPZDA,144311.00,09,08,2022,00,00*67
$GPZDA,144312.00,09,08,2022,00,00*64
$GPZDA,144313.00,09,08,2022,00,00*65
$GPZDA,144314.00,09,08,2022,00,00*62
$GPZDA,144315.00,09,08,2022,00,00*63
$GPZDA,144316.00,09,08,2022,00,00*60
$GPZDA,144317.00,09,08,2022,00,00*61
$GPZDA,144318.00,09,08,2022,00,00*6E

───────────────────────────────────────────────────────────────────────────────────
NT����$GNZDA,144155.00,09,08,2022,00,00*7B
MT����$GNZDA,144156.00,09,08,2022,00,00*78
LT����$GNZDA,144157.00,09,08,2022,00,00*79
KT��s�$GNZDA,144158.00,09,08,2022,00,00*76
JT��^$GNZDA,144159.00,09,08,2022,00,00*77
IT��I$GNZDA,144200.00,09,08,2022,00,00*78
HT��3$GNZDA,144201.00,09,08,2022,00,00*79
GT��($GNZDA,144202.00,09,08,2022,00,00*7A
FT���   8$GNZDA,144203.00,09,08,2022,00,00*7B
thschaub commented 2 years ago

Please check the TOD Master Reference Manual: https://github.com/opencomputeproject/Time-Appliance-Project/blob/master/Time-Card/SOM/FPGA/Doc/Tod_Master_ReferenceManual.pdf

The NMEA Master takes the time from the adjustable clock which is usually TAI (Chapter 2.4). Correction has to be done via the available register (Chapter 3.2.1.5).

@jlemon: Maybe something which could be done directly in the driver?

MaciekMachni commented 2 years ago

Just note that the difference between the two messages is at -75 seconds, which is more than 2x the current UTC vs. TAI difference. Most likely, the correction is done twice, and we're getting stale messages.

jlemon commented 2 years ago

The sysfs file utc_tai_offset should apply its correction to the NMEA master, as @thschaub mentioned. I'd suggest checking that value.

MaciekMachni commented 2 years ago

Unfortunately, writing to that file has no effect: https://asciinema.org/a/RbQNaJarzDvWflWP3RoE0TDG1 Also, it does not accept negative corrections (which makes sense but prevents testing a workaround). I'll try to hack the code tomorrow, but the thing that worries me is we get the extra 1 s offset.

Edit: a bit of background on the video - the adapter is connected via SMA cable to the time card and was synchronized to the GNSS output before the test. In the test, it was running with the --free_running 1 to measure the offset and not apply the correction.

MaciekMachni commented 2 years ago

@thschaub, unfortunately, it's not fixable in the software. The NMEA offset is already set correctly at the ptp_ocp_utc_distribute() function at the driver initialization, but it seems the IP block applies the 37 s correction by default.

I tried setting the bp->nmea_out->adj_sec (which maps to the register you mentioned) to 0, resulting in the 38-second offset in the NMEA received from the Time Card NMEA UART vs. the ZED-F9T UART.

Setting the negative correction in the register results in time reverting to 1980.