Hi,
I’m just beginning to use the GMS682 tri-band cellular module. I note that it has an internal RTC, and I wonder if it’s possible to obtain the time/date directly from the cellular network to set the RTC? The documentation for the GMS862 describes the commands used to set the RTC, but it makes no mention of where time/date is derived.
Thanks,
John
Time is a GSM network feature, but the telit module apparently does not support it. That would make too much sense now would it?
You could get creative … i just end up using the GPS to set the clock, but unless you are interested in the alarm function, that would be silly. I take it you dont have the GPS version.
You could send yourself an SMS or write an NTP client, but thats about it.
AT#NITZ
Set command enables/disables automatic date/time updating and Network
Timezone unsolicited indication.
Date and time information can be sent by the network after GSM
registration or after GPRS attach.
Parameters:
0 - disables automatic set (factory default)
1 - enables automatic set
0 - disables unsolicited message (factory default)
1 - enables unsolicited message; after date and time updating the following
unsolicited indication is sent:
#NITZ: “yy/MM/dd,hh:mm:ss”
Has anyone figured out how to force an RTC sync to network time?
I ran a GM862-QUAD-PY with firmware 7.03.500 today for over 6 hours and never got current time with “AT+CCLK?”. This included numerous SMS sends and receives, and GPRS data transmissions.
This is, of course, with “AT#NITZ=1”.
Setting NITZ to 0 and back to 1 did not cause an update.
Hmm… I may have just found a solution.
With NITZ=1 I changed to CFUN=4, then back to CFUN=1.
After a few seconds AT+CCLK? returned the correct time.
Does this sound correct you folks, or is there a better way?
Thanks in advance.
-Task
You’re correct, the time sync is very quirky. At a minimum, you’d think the module would do a time sync (with #NITZ notification) anytime it attaches to a network.
I don’t have my code in front of me, but I think I put “AT#NITZ=1,1” into my initialization routine right powering up the Telit and setting the baud rate. This causes the #NITZ notification every time, for the first network attach.
By toggling CFUN you’re basically doing the same thing, and might be the only way to cause it without power cycling the Telit module.
-Brett
One other observation - the GSM network time information doesn’t include any timezone information. Technically you could determine the location by using the cell tower ID or area code, but I haven’t found any free databases with this information.
Since my system also has a GPS receiver, I just use the UTC time/date information from the GPS. This makes it easy to have a consistent time value for both the server and client devices. My plan was to use the GSM network time as a backup in case I didn’t have GPS coverage (ie: parking garage), but with the caveat that it’s not as reliable as UTC data from GPS.
HTH!
Hi,
I do the same with a GE865 Telit module but could not get the time from the network. I also used “AT#NITZ=1,1”, tried to de-register et register again (with CFUN=4 and CFUN=1). However, the command “AT+CCLK?” returns something like “00/01/01,00:01:23+01”, so the elapsed time from startup counted at the 1th Jan 2000 00:00.
I also played with “AT+COPS=2” to de-register and “AT+COPS=0” to automatically register again but time is still unset.
The networks used are either “Orange CH” or “SWISS GSM” and I suppose they both should be able to send the hour.
Has someone an idea what’s the problem?
Thanks,
Bernard
i am not positive but i think nitz support is dependant on the provider and i hear that in europe it isn’t well supported. that may be why you are not getting the clock set. i am in georgia using a 865 also and it works here but i seem to be getting the wrong value for timezone offset?
I could be way off base here but I think the GSM provider has the option of sending a time message as often or as rarely as it wants (or never). So you may have to wait for one to be transmitted.
my bad about the timezone being wrong… i didn’t realize it reports in quarter hour offsets… so it looks like it is right. i also verified the time given at the same moment as the gps chip gave me a utc time and they both appear to be dead on to the second. so the idea here is to use the gsm time to provide time aiding to the gps on boot…