NTP Date/Time from nrfConnect v1.2.1

[dave_s]

For reasons beyond my control I need to do some changes to a nrf9160 project that was developed using nrfConnect v1.2.1.  I know the ideal situation is to upgrade it to the latest version, but it uses several deprecated config options that would require a lot of testing if I had to change.

I need to get the current time.. I thought I could easily do with the Date/Time module, but it looks like it isn't supported in v1.2.1.  Is there a way in that version to get the current time?  Or configure the modem to update the time as needed and then read the time from that?

[Håkon Alseth]

Hi,

 

Although I would recommend that you upgrade your project, you could cherry-pick the initial commit for the date_time library:

https://github.com/nrfconnect/sdk-nrf/commit/1e6e3e3530be53f5a61794fbc30c6c7f58f6f4d3

 

The current time can also be queried via AT%XTIME (if your connected network provides time):

https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/nw_service/xtime_set.html?cp=2_2_0_7_8_0

See this function for how to translate it: https://github.com/nrfconnect/sdk-nrf/blob/v2.6.0/lib/date_time/date_time_modem.c#L109

 

Kind regards,

Håkon

[dave_s]

Hi,

I changed my approach to get the time from the modem using modem_info_string_get with MODEM_INFO_DATE_TIME

Here is the response I get

24/04/19,18:50:33-20dy

What is the '-20dy' portion represent?

Is there way to retrieve the modem time in seconds since epoch?  Or do I need to parse the string to get the UTC date/time?

Is the format and string length always the same regardless of the date / time?

How / when does the modem time get updated?  Is there a way to know how recently updated it is?

[dave_s]

Q1: What modem fw version are you using? mfw_nrf9160_1.1.2
Q2: How are you implementing the routine to fetch MODEM_INFO_DATE_TIME? Can you share this?  

    char sbuf[30];

    size = modem_info_string_get(MODEM_INFO_DATE_TIME, sbuf);

The string being returned is like this

24/04/22,15:18:34-20

which doesn't seem to match a standard format

[Håkon Alseth]

Hi,

 

That is the format of CCLK:

https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/mob_termination_ctrl_status/cclkl_set.html?cp=2_2_0_4_22_0

 

You can use scanf to convert it into struct tm:

https://github.com/nrfconnect/sdk-nrf/blob/v2.6.0/lib/date_time/date_time_modem.c#L53-L65

 

Kind regards,

Håkon

[dave_s]

Thanks

That makes a bit more sense on time format if the timezone is in quarter of an hour.

But it looks like the date / time portion is UTC and doesn't have the timezone offset applied?

For example, last night I received the following response

24/04/23,01:48:50-20

I am in US central DST, so the -20 offset makes sense.  But it shows 1:48 am on April 23 2024.  I read the time at 8:48 pm April 22 local time

One additional question, for the function modem_info_string_get, it says a negative error code is returned if it isn't successful.  Where are the error codes documented?

When does the modem time get updated?
Can I programmatically tell it to update if the return value is negative?

[Håkon Alseth]

Hi,

 

The network provides this time, but there's a catch, as described in this thread:

 RE: nRF9160 AT+CCLK response time does not take into account the time zone difference 

 

The implementation depends on the network configuration, thus you can handle this in two different ways. Have you considered fetching via ntp or XTIME to better work around this?

dave_s said:

One additional question, for the function modem_info_string_get, it says a negative error code is returned if it isn't successful.  Where are the error codes documented?

It will return based on errno.h definitions.

errno.h values is based on which libc that you use, normally it is newlib-nano:

https://github.com/eblot/newlib/blob/master/newlib/libc/include/sys/errno.h

 

Kind regards,

Håkon

[dave_s]

Thanks for your responses.

I had originally intended to use NTP but after finding out the nrfConnect version I was using is too old to have it already integrated with the DateTime module it looked like it would be simpler and easier to get the modem time.