ST67W611M1: low accuracy of SNTP

[nicolas]

I'm using the ST67W6X_MQTT example on a NUCLEO-U575ZI-Q and i got the following result:

04/11/2025 16:11:02.217 [RX] - SNTP Time: Tue Nov 04 16:11:03 2025
04/11/2025 16:11:27.886 [RX] - SNTP Time: Tue Nov 04 16:11:27 2025
04/11/2025 16:11:46.452 [RX] - SNTP Time: Tue Nov 04 16:11:48 2025
04/11/2025 16:12:02.734 [RX] - SNTP Time: Tue Nov 04 16:12:05 2025
04/11/2025 16:12:20.904 [RX] - SNTP Time: Tue Nov 04 16:12:21 2025
04/11/2025 16:12:37.945 [RX] - SNTP Time: Tue Nov 04 16:12:38 2025
04/11/2025 16:12:54.605 [RX] - SNTP Time: Tue Nov 04 16:12:57 2025
04/11/2025 16:13:12.778 [RX] - SNTP Time: Tue Nov 04 16:13:15 2025
04/11/2025 16:13:30.028 [RX] - SNTP Time: Tue Nov 04 16:13:30 2025
04/11/2025 16:13:49.107 [RX] - SNTP Time: Tue Nov 04 16:13:49 2025
04/11/2025 16:14:05.867 [RX] - SNTP Time: Tue Nov 04 16:14:09 2025
04/11/2025 16:14:23.925 [RX] - SNTP Time: Tue Nov 04 16:14:24 2025

this correspond to an error of: +1, +0, +2, +3, +1, +1, +3, +3, +0, +0, +4, +1

I was expecting errors of under a second.

--------------- ST67W6X info ------------
ST67W6X MW Version: 1.1.1
AT Version: 1.0.0
SDK Version: 2.0.89
Wi-Fi MAC Version: 1.6.44
BT Controller Version: 1.6.112
BT Stack Version: 1.9.56
Build Date: Sep 4 2025 11:32:47
Module ID: C6AFDBD111400004 (-B)
BOM ID: 1
Manufacturing Year: 2024
Manufacturing Week: 47
Battery Voltage: 3.302 V
Trim Wi-Fi hp: 6,6,6,6,6,6,5,5,5,5,6,6,6,6
Trim Wi-Fi lp: 5,6,6,7,7,8,8,8,8,8,9,9,9,9
Trim BLE: 5,4,4,5,6
Trim XTAL: 37
MAC Address: 40:82:7b:00:22:ce
Anti-rollback Bootloader: 0
Anti-rollback App: 0

[Andrew Neil]

Where does the RX timestamp come from? How accurate is it?

[nicolas]

From my computer, it should be accurate enough.

Having an error difference of 4s in less than 20s is extremely unlikely from the PC side (if it is the case, i should have easily detected it).

[mbarg.1]

You need to trim RTC and you can easily keep your local clock within 16/256 of second using SNTP - of course some additional coding required - more exact sincronization is possible but would waste a lot of resources.

PAY attention to SNTP server - some have large drift.

[nicolas]

Maybe i didn't explain clearly how i got my results. Each line was obtain after restarting the firmware, so it's not a problem of the STM32 RTC.

[mbarg.1]

I see - you are asking why MQTT does not sync better than that - SNTP in stratum 0,1,and 2 is by sure better than that, with SNTP I get better less than 1 second after first (coarse) syncronization, but i am using a task with SNTP to do it. Probably someone from MQTT can reply or you can reverse engineer the code to see how they get a sync from a UDP packet that has picoseconds precision time stamp with Stratum 0 reference.

An easy test could be to use wireshark and grab SNTP packets - you easily see what can be the loop delay between query and reply - precision acheavable is better than loop delay with zero effort.

[nicolas]

I'm using the MQTT example only because it's the only example with SNTP.

I can't see the traffic because it's all done inside the ST67, the driver just send an AT request "AT+CIPSNTPTIME?" to get the time.