GSM network time

Hi all!

I have tried looking for the information on the Internet, but could find
nothing... I hope someone can help me out. 

I am trying to build a system based on Siemens TC65. It is very important
for the application that runs on it to know the exact time (well, +- 1
minute) at all times - even after power off. 

Now I know my nokia GSM has an option to get the time from network so it can
be done - but how do I tell TC65 it should do it every once in a while?
Does it syncronize the time automatically? 

AT command set documentation says:
---
<time> will be reset to its factory default if power is totally
disconnected. In this case, the clock starts with
<time>= "02/01/01,00:00:00" upon next power-up.
Each time TC65 is restarted it takes 2s to re-initialize the RTC and to
update the current time. Therefore, it is
recommended to wait 2s before using the commands AT+CCLK and AT+CALA (for
example 2s after
^SYSSTART has been output).
---

Does that mean that the module updates the time from the network 2s after
power-up?

Should I use AT+CCLK to set the time to the one I get from my server on the
Internet (GPRS)?

Another thing: is the time on RTC always UTC? I will be using J2ME
Date.getTime() to get the number of milliseconds from epoch... Will the
time be exact or should I worry about it?

I just need the accurate UTC time. :)

Any help would be appreciated.

Kind regards,

Anze

Anze <anzenews@volja.net> wrote:
> Now I know my nokia GSM has an option to get the time from network so it can
> be done - but how do I tell TC65 it should do it every once in a while?
> Does it syncronize the time automatically? 

As far as I know GSM can only synchronise the timezone to the network and
there is no sync of realtime between the base station and the handset.

> Should I use AT+CCLK to set the time to the one I get from my server on the
> Internet (GPRS)?

Network time is a can of worms, the best you will probably be able to do
(unless your phone runs Linux and can run an NTPd) is forcibly reset the
time if it is too far out. However you can't just ask your server what the
time is as that doesn't take into account the network latency, NTP takes all
of this into account.

> Another thing: is the time on RTC always UTC? I will be using J2ME
> Date.getTime() to get the number of milliseconds from epoch... Will the
> time be exact or should I worry about it?

Again hard. It should return milliseconds since epoch however it may not
dependant on host environment. I would not be at all surprised if WinCE
based handsets moved the position of the epoch to deal with daylight saving
time as desktop based versions of Windows do.

> I just need the accurate UTC time. :)

Mandate a phone with a GPS in it :p

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------

Paul, thanks for the reply! Really appreciate it... :)

> As far as I know GSM can only synchronise the timezone to the network and
> there is no sync of realtime between the base station and the handset.

Hmmm, that would explain why I couldn't find anything except NITZ
synchronisation on the Internet... However, the Nokia N70 has an
option "automatically update time" (I am translating this from my language
so the wording might be different). It might be just a misnamed option
though... Weird. 

>> Should I use AT+CCLK to set the time to the one I get from my server on
>> the Internet (GPRS)?
> 
> Network time is a can of worms, the best you will probably be able to do
> (unless your phone runs Linux and can run an NTPd) is forcibly reset the
> time if it is too far out. However you can't just ask your server what the
> time is as that doesn't take into account the network latency, NTP takes
> all of this into account.

I only need an "approximate accurate time" - I don't care if it is a minute
off, but it must be at least this accurate at all times. So I don't really
care that much about network latency...

>> Another thing: is the time on RTC always UTC? I will be using J2ME
>> Date.getTime() to get the number of milliseconds from epoch... Will the
>> time be exact or should I worry about it?
> 
> Again hard. It should return milliseconds since epoch however it may not
> dependant on host environment. I would not be at all surprised if WinCE
> based handsets moved the position of the epoch to deal with daylight
> saving time as desktop based versions of Windows do.

TC65 doesn't have Window$ on it, and it is meant for industry usage, so I
guess it shouldn't change the time no matter what... I would just feel a
lot better if that was written somewhere. :)

>> I just need the accurate UTC time. :)
> Mandate a phone with a GPS in it :p
I'd love to know better alternatives than Siemens TC65, but for now I'm
stuck with it... Besides, I have no real grumbles over it (yet). It is a
delight to program for it. :)

OK, so I'll just hope nothing changes the RTC clock, and I'll also get the
time on update via network and use the difference between times to
calculate more or less accurate time. Ufff. It could be so much easier. :)

Thanks again!

Best, 

Anze

This is the solution I have found... I'm posting it for reference if someone
else might need it in future. Comments are of course welcome... :)

Siemens TC65 J2ME engine reads the time only on startup and therefore you
can't set the time with AT+CCLK. Well, you can, but Java knows nothing
about it, so it doesn't help. 

Solution? Write your own class that sets the time through "AT+CCLK=..." and
reads it through "AT+CCLK?". Easy really. It can also take care of the DST
changes and timezone if needed. Just be careful to cache the time - this
might not be the fastest way to get the time. Also, don't be like windows,
be nice to other midlets (and yourself) and set the time to UTC/GMT. :)

If you need a faster alternative then use AT+CCLK=... to set the time and
remember the time offset between AT+CCLK? and System.currentTimeMillis().
Again, write a class that takes the offset into account. 
This is a bit more complicated solution but it might be faster (important if
you often query the time, which I don't). 

So, just ignore Date and Calendar class... And use a good old-fashioned
clock. Set it, read it. That's all. :)

Best,

Anze