AT+CCLK reporting bogus time

[vkbakken]

I am seing odd time strings from AT+CCLK... Like: "+CCLK: "15/02/01,00:00:08"\r\nOK\r\n"

I think it is required that AT+CCLK responds error until it has gotten network time. Otherwise how can I trust it?

Is there a point where the AT+CCLK is not safe?

[jbrzozoski]

In my experience, once the clock has time it has stayed good, but you are definitely right about reporting a bogus time before it syncs with the cell towers.  I have seen no mention of any way to retain the modem RTC around reboots, which (fortunately?) means that the modem will always report a time back in 2015 until it is synced, and you can simply check if the date is before 2018 as a workaround test to determine if you should trust it.

[vkbakken]

That is the current workaround - check for time being well in the past :D . But it would be much cleaner with ERROR returned before RTC is valid...

[tesc]

Hi,

While an error would have been cleaner, from what I understand that is not what is mandated by the relevant AT command specification. (It simply tells to return the value of the RTC, which in our case has never been updated to reflect the current time and therefore is not the correct time, although not "invalid" per se.)

I have contacted the team to see if we have a better solution. For now the workaround of checking if the time is from before the production date of the device seems to be the best solution.

You can also use the set command and set the RTC time manually, if you want full control over what value it is initialized to. (Or, if you have a separate time source, so that you can set the RTC to the current time using that one instead of relying on the network.)

Please note that the frequency at which the network distributes time data is controlled by the network operator. Unless stated by the operator, there is no guarantee that a user equipment will receive time data within a given time period.

Regards,
Terje

[vkbakken]

Thanks for your reply Terje.

Since the AT command spec says just to return a value -  I would take my suggestion as an application input to what it could be implemented as! Wrong time is simply confusing and not what is done by other modems.

Since Nordic is implementing a bit of their own AT commands using % I would also suggest allowing for cclk valiant with unix epoch time.

Looking forward to the reply from the product team.

Vemund

[tesc]

Hi,

I can confirm that the RTC stored and managed internally by modem firmware is currently set to 2015-01-01T00:00:00 on startup. Time will tick, so until updated the time read will reflect the uptime of the device.

Note that for devices that are on for a few years (without any reset), the RTC value will overtake the production date. After that point in time the workaround of comparing the date read to the production date is not enough on its own. One mitigation is to set the RTC value manually back to e.g. Unix epoch (1970-01-01) if between 2015-01-01 and production date.

It is not yet decided what we will do, but the proposed workarounds are considered OK by the team and they are looking into the possibility of either returning error or change reset value to Unix epoch. (The latter would make the production date comparison err after ~50 years uptime instead of after ~5.)

AT command with Unix timestamp definitely sounds like something we should look into. I have registered a feature request, currently awaiting feedback from the team.

Regards,
Terje

[tesc]

Hi,

A short update:

We plan to implement an error to be returned from AT+CCLK if time has not been received from the network.

We are not planning to implement a Unix timestamp AT command. Use AT+CCLK and convert in application space instead.

Regards,
Terje