Getting correct (synced time) from `AT+CCLK?`

LTE Cat 1 / Cat 1 bis (Calliope)
1

We are using Calliope (GC02S1-EU2) on our IoT gateway. The gateway needs to run CCLK for several reasons and we found some time sync issues. Later, we discovered that the fetched time was wrong.

D (28456) AgNode: TX: AT+CEREG?
D (28456) AgNode: RX: +CEREG: 1,5
D (28456) AgNode: RX: OK
D (28456) AgNode: TX: AT+CCLK?
D (28466) AgNode: RX: +CCLK: "70/01/01,00:00:16+00"
D (28466) AgNode: RX: OK

I (28476) app: Unix time received: 3155760016

Questions:

  • Is "70/01/01,00:00:16+00" a default value of some sorts?
  • Is there some ideal time we should wait to get the correct value or is there some command to check if the time has actually synced.
  • What’s the recommended application domain logic to avoid this situation?

For reference, 70/100 times, the time is indeed correct as follows

D (26463) AgNode: TX: AT+CEREG?
D (26463) AgNode: RX: +CEREG: 1,5
D (26463) AgNode: RX: OK
D (26463) AgNode: TX: AT+CCLK?
D (26473) AgNode: RX: +CCLK: "25/12/19,16:33:18+04"
D (26473) AgNode: RX: OK

I (26483) app: Unix time received: 1766158398

2

Hi,

At boot time, the module internal time is “70/01/01,00:00:00+00”.

During registration, in most networks, the network provides the current date and time in the NAS EMM information message. This message comes a few dizains or hundreds of ms after the registration is complete, after you see +CEREG: x,1 or +CEREG: x,5.

There is a possibility that if you send AT+CCLK? too quickly after the +CEREG: URC, the NAS EMM information message has not arrived yet. It could depend on cell signal conditions, or network congestion. I recommend that you retry AT+CCLK? 200ms later if it replies with the date “70/01/01”.

I did the experiment in a commercial network with a Teraterm script (I can provide it to you if you need) by retrying AT+CCLK? if the response date is “70/01/01”. Out of 118 registration, 14 times the retry was required to receive the time from network.

Log example:

[2026-01-29 15:54:13.696] +CEREG: 5,“CDA4”,“0188D801”,7
[2026-01-29 15:54:13.712] AT+CCLK?
[2026-01-29 15:54:13.712] +CCLK: “70/01/01,00:00:04+00”
[2026-01-29 15:54:13.727]
[2026-01-29 15:54:13.727] OK
[2026-01-29 15:54:13.744] AT+CCLK?
[2026-01-29 15:54:13.744] +CCLK: “26/01/29,15:54:12+04”



[2026-01-29 16:02:29.630] +CEREG: 5,“CDA4”,“0188D801”,7
[2026-01-29 16:02:29.687] AT+CCLK?
[2026-01-29 16:02:29.687] +CCLK: “70/01/01,00:00:04+00”
[2026-01-29 16:02:29.687]
[2026-01-29 16:02:29.687] OK
[2026-01-29 16:02:29.725] AT+CCLK?
[2026-01-29 16:02:29.725] +CCLK: “70/01/01,00:00:04+00”
[2026-01-29 16:02:29.725]
[2026-01-29 16:02:29.725] OK
[2026-01-29 16:02:29.788] AT+CCLK?
[2026-01-29 16:02:29.816] +CCLK: “26/01/29,16:02:29+04”
[2026-01-29 16:02:29.816]
[2026-01-29 16:02:29.816] OK

Here is an example of Wireshark capture where NAS EMM Information message came 630ms after the NAS Attach Accept:

image
image1351×732 39.3 KB

Note: You can capture such Wireshark log from GC02S1 or GM02S(P) modules with Sequans DM Light tool, available at Sequans Communications

Sometimes, the network provides the time in the System Information Block Type 16 message, which can even a few seconds to be available to AT+CCLK?

Finally, some network do not provide the date and time at all. In that case, you need to use a NTP or SNTP server to get the time, through the AT+SQNNTP command.

For example:

AT+SQNNTP=0,“time.esa.int,time.nist.gov,pool.ntp.org”,1
+SQNNTP: 0,“26/01/29,14:23:29+04”

OK

You may refer to the AT command user manual available at https://cloud.sequans.com/f/2718636 to know more about the usage of AT+SQNNTP command:

  • Calliope2-ATCommandsUseCases-LR90.pdf, chapter 13.1. Time Synchronisation
  • Calliope2-ATCommandsReferenceManual-LR9.0-Rev.3.pdf, Chapter 10.15. Time synchronisation with NTP: AT+SQNNTP

Best regards,

Benoit.