How to detect if NTP server cannot be reached

In the HL78xx AT command reference section 6.11 AT+KNTPCFG: SNTP Client Configuration there is the following comment in the notes section.

“If the configured NTP server cannot be reached, this service will continue to retry
indefinitely. In this case, it is advisable to disable the service to save power”

What is the recommended way to detect this condition?

how about setting a wrong clock in AT+CCLK and see if it will be updated?

That would be fine as a test, but not as a real world solution.

Why not? You can set up a timer to check

If the NTP request only occurs every 24 hours, then any other code that uses the value from AT+CCLK will get the wrong value.

I remember if the ntp connection works, +cclk will be updated within 5 seconds
So you don’t need to wait 24 hours

Btw, of course you need to set some special +cclk at the beginning, like all zero, to indicate to your code this is wrong value

So, is this statement in the reference guide wrong? Or are you saying it will occur after I enable it? Does it occur after reset or relative to the last request?

Have you done any test to verify?
As said before, you can set wrong time in+cclk to verify

I kept a log tested before, e.g.

at+ctzu?
+CTZU: 0

OK
at+cclk?
+CCLK: "00/00/00,00:00:00-00"

OK
AT+KNTPCFG?
+KNTPCFG: 0,,0,+00

OK
AT+KNTPCFG=1,"pool.ntp.org",0,-32
OK
AT+KNTPCFG?
+KNTPCFG: 1,pool.ntp.org,0,-32

OK
< **Allow 1 second to get the clock from the NTP server** >
at+cclk?
+CCLK: "21/03/11,14:58:07-32"

OK

Is this the wrong place to ask questions and expect a definitive answer? I realize that some questions may require running tests, but this doesn’t seem like one of those situations.

I am not asking if there is a way to show that it works once. I am asking if there is a way to know that it has stopped working so that it can be disabled and possibly reenabled at a later time.

In my use case, it is not an option to invalidate the RTC until the next time it gets updated.

When I try to replicate your test, the RTC is not updated in 5 seconds, 20 minutes, or an hour.

// at+ctzu is 1
// Time is obtained from cell network
[00:00:04.388,183] <inf> modem_hl7800: Revision: HL7800.4.7.1.0
[00:00:48.857,635] <dbg> modem_hl7800: hl7800_rx: HANDLE +CCLK:  (len:22)
[00:00:48.857,635] <dbg> modem_hl7800: wait_for_modem_data: cur:23, exp:25
[00:00:48.907,806] <inf> modem_hl7800: RTC string: '"24/10/23,14:57:25-20"'
[00:00:48.907,897] <dbg> modem_hl7800: hl7800_rx: HANDLE OK (len:0)
[00:00:52.908,142] <inf> attr: [029] lte_sleep_state               4 Sleep

// Device has MQTT connection
// Reset RTC
// Date must be valid (cannot set to 00/00/00)
uart:~$ hl cmd 30 at+cclk=\"24/10/23,00:00:00-20\"
[00:01:34.876,708] <dbg> modem_hl7800: allow_sleep: Keep awake
[00:01:34.896,850] <dbg> modem_hl7800: send_at_cmd: OUT: [at+cclk="24/10/23,00:00:00-20"]
[00:01:34.903,289] <dbg> modem_hl7800: hl7800_rx: HANDLE OK (len:0)
[00:01:38.903,411] <dbg> modem_hl7800: allow_sleep_work_callback: Allow sleep
[00:01:38.903,442] <inf> modem_hl7800: Sleep State: SLEEP
[00:01:38.903,533] <inf> attr: [029] lte_sleep_state               4 Sleep

uart:~$ hl cmd 30 at+cclk?
[00:01:40.859,252] <inf> attr: [029] lte_sleep_state               2 Awake
[00:01:40.864,257] <dbg> modem_hl7800: hl7800_rx: HANDLE +CCLK:  (len:22)
[00:01:40.864,288] <dbg> modem_hl7800: wait_for_modem_data: cur:23, exp:25
[00:01:40.914,428] <inf> modem_hl7800: RTC string: '"24/10/23,00:00:05-20"'

// Enable client
[00:02:18.112,030] <dbg> modem_hl7800: send_at_cmd: OUT: [AT+KNTPCFG=1,"pool.ntp.org",0,-20]

uart:~$ hl cmd 30 at+cclk?
[00:03:13.393,646] <inf> modem_hl7800: RTC string: '"24/10/23,00:01:38-20"'

uart:~$ hl cmd 30 at+cclk?
[00:12:58.698,150] <inf> modem_hl7800: RTC string: '"24/10/23,00:11:23-20"'

uart:~$ hl cmd 30 at+cclk?
[00:14:53.655,609] <inf> modem_hl7800: RTC string: '"24/10/23,00:13:18-20"'
								   
uart:~$ hl cmd 30 at+cclk?
[00:22:19.480,163] <inf> modem_hl7800: RTC string: '"24/10/23,00:20:44-20"'

// Still hasn't been updated after 20 minutes, is configuration valid? (Appears to be.)
uart:~$ hl cmd 30 AT+KNTPCFG?
[00:32:01.013,458] <dbg> modem_hl7800: hl7800_rx: 
                                       2b 4b 4e 54 50 43 46 47  3a 20 31 2c 70 6f 6f 6c |+KNTPCFG : 1,pool
                                       2e 6e 74 70 2e 6f 72 67  2c 30 2c 2d 32 30       |.ntp.org ,0,-20
// Try another server
uart:~$ hl cmd 30 AT+KNTPCFG=1,"ntp.airvantage.net",0,-20
uart:~$ hl cmd 30 at+cclk?
[00:47:34.677,398] <inf> modem_hl7800: RTC string: '"01/01/23,00:19:23+00"'
uart:~$ hl cmd 30 at+cclk?
[00:47:45.801,422] <inf> modem_hl7800: RTC string: '"01/01/23,00:19:34+00"'

// PC
ping pool.ntp.org
Ping statistics for 66.228.58.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 26ms, Maximum = 31ms, Average = 27ms

ping ntp.airvantage.net
Pinging twc.trafficmanager.net [168.61.215.74] with 32 bytes of data:
Ping statistics for 168.61.215.74:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 13ms, Average = 12ms

I have just made a test with my HL7802 with GSM network here.
I found that the CCLK time is updated after starting some UDP communication:

ati3
HL7802.4.6.9.4

OK
at+cpin?
+CPIN: READY

OK
at+ksrat?
+KSRAT: 0

OK
at+ksrat=2
OK
at+cfun=1,1
OK


at+cpin?
+CPIN: READY

OK
at+cgdcont?
+CGDCONT: 1,"IPV4V6",,,0,0,0,0,0,,0,,,,,

+CGDCONT: 2,"IPV4V6",,,0,0,0,0,0,,0,,,,,

OK
at+cgdcont=1,"IP","hkcsl"
OK
at+cgpaddr=1
+CGPADDR: 1

OK
at+creg?
+CREG: 0,1

OK
at+cclk?
+CCLK: "24/10/24,14:27:42+32"

OK
at+ctzu?
+CTZU: 1

OK
at+ctzu=0
OK
at+cclk="24/10/23,00:00:00-20"
OK
at+cfun=1,1
OK

at+Cpin?
+CPIN: READY

OK
at+csq
+CSQ: 99,99

OK
at+creg?
+CREG: 0,1

OK
at+cclk?
+CCLK: "24/10/23,00:00:26-20"

OK
at+cgdcont?
+CGDCONT: 1,"IP","hkcsl",,0,0,0,0,0,,0,,,,,

+CGDCONT: 2,"IPV4V6",,,0,0,0,0,0,,0,,,,,

OK
AT+KNTPCFG=1,"pool.ntp.org",0,-32
OK
at+kntpcfg?
+KNTPCFG: 1,pool.ntp.org,0,-32

OK
at+cclk?
+CCLK: "24/10/23,00:06:55-20"

OK
at+cfun=1,1
OK
at+creg?
+CREG: 0,1

OK
at+cclk?
+CCLK: "24/10/23,00:07:47-20"

OK
at+cgact?
+CGACT: 1,0
+CGACT: 2,0
+CGACT: 3,0
+CGACT: 4,0
+CGACT: 5,0
+CGACT: 6,0
+CGACT: 7,0
+CGACT: 8,0
+CGACT: 9,0
+CGACT: 10,0
+CGACT: 11,0
+CGACT: 12,0
+CGACT: 13,0
+CGACT: 14,0
+CGACT: 15,0

OK
at+cgatt?
+CGATT: 1

OK
at+cgact=1,1
OK
at+creg?
+CREG: 0,1

OK
at+cgpaddr=1
+CGPADDR: 1,"10.105.62.127"

OK
at+cclk?
+CCLK: "24/10/23,00:09:08-20"

OK
AT+KCNXCFG=1,"GPRS","hkcsl"
OK
AT+KCNXPROFILE=1
OK
AT+KUDPCFG=1,0,5043
+KUDPCFG: 1

OK

+KCNX_IND: 1,1,0

+KUDP_IND: 1,1
at+cclk?
+CCLK: "24/10/23,00:09:44-20"

OK
AT+KUDPSND=1,"123.123.123.123",123,48
CONNECT

OK
at+cclk?
+CCLK: "24/10/24,01:54:19+20"

OK

On the other hand, perhaps you can also try to start the NTP communication manually.
In this case, you can control everything including the +CCLK setting and the connection to the NTP server and retry mechanism.

AT+KUDPCFG=1,0,5043


+KUDPCFG: 1

OK


+KCNX_IND: 1,4,1



+KCNX_IND: 1,1,0



+KUDP_IND: 1,1

AT+KUDPSND=1,"pool.ntp.org",123,48

CONNECT
//here send binary file "init_udp.bin"
OK


+KUDP_DATA: 1,48

AT+KUDPRCV=1,48

CONNECT
 ç  6   †
GòêÄZeÿ´º1        êÄZ5@bþ7êÄZ5@iV--EOF--Pattern--
OK


+KUDP_RCV: "162.159.200.1",123

init_udp.bin (64 Bytes)

To decode, you can see here: