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:
--
will be reset to its factory default if power is totally
disconnected. In this case, the clock starts with
= "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).
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.
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.
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.
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... :)
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.
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...
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'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. :)
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. :)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.