Time in GPZDA on the NMEA serial port is incorrect

[MaciekMachni]

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]

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]

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]

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

[MaciekMachni]

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]

@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.