Hi,

Wonder if anybody knows the answer to this one, because I can't seem to find the answer to it.

There is an AT command which retrieves the GSM network time, this is:

AT+CCLK?

And it returns something like:

+CCLK: "13/02/06,09:25:12+08"

Which gives you the time and date and the offset from GMT, now not being a timezone guru does this indicate that the time is 09:25:12 GMT in the morning or 09:25:12 local time with the time zone being 2 hours ahead? (the offset is in 15 minute units so 8=2 hours).

All the documentation I have got for the modules we use don't actually tell you whether it's GMT or local time which it returns, and with the UK being on GMT at the moment I can't actually tell whether it returns GMT or local time, either way you know the offset to GMT, I just don't want to make the wrong call here.....

Thanks.

Adrian

Note that this usually reads the module internal clock, NOT the network time. You need to configure the modem to sync its RTC to the network with a separate command. Off the top of my head it's AT+NITZ or AT#NITZ for Telit models at least.

I'm pretty sure the time includes the offset already. I can check if you give me a day or two.

Pretty sure that is pacific std time, and it's in 24 hour format.

I just tried this on a Telit HE910 module. The AT#CCLK? command is reporting local time, the offset here in Sydney is 44 (11 hours).

Yeah, but the module doesn't have battery backup, so it either reads time starting at the epoch or network time once it's synced, it's easy enough to figure out if it's done a sync.

The modules that we're using have a default configuration which has NITZ enabled (they're motorola ones, although telit bought motorola and the latest batch we have got from them are badged as telit).

Quite why they don't explain whether this is GMT or localtime in any of their manuals (or any other manufacturers manuals that I could find) is, well, beyond me....

I think rod has given me the definitive answer with his reply.

I'm guessing that you did that at 15:14 local time because your post time lines up with the offset from the CCLK.

localtime it is.

Many thanks.

Adrian

Right. I'm just saying you will need the smarts even if NITZ is set.

And Rod confirms what I was remembering so you should be good to go. Telit can't tell you? Their support of us is pretty responsive.

Also one thing I have noticed is that this doesn't work in all countries around the world. Usually less developed ones. Is it for the UK only?

I know just recently it's worked in UK, India, UAE, Singapore and Australia but 6 months ago, India didn't work for example. It's quite handy to just turn your phone on and have the time and timezone update itself.

Tbh I've found so many bugs in this device that I've lost faith in it, to be fair they do usually fix them, but some of them have required me to send stuff off to israel by "snail mail" and it takes ages....even longer when you have a customer breathing down my neck.

Primarily UK, some are in europe as well.

This is actually a stop gap fix for another issue, we have a maxim-dallas RTC on board which under "some" circumstances forgets its clock, it's fully battery backed, go figure. There are plenty of other people mentioning this issue on the net, but nobody seems to know how to fix it.

The network time allows me to reset the clock on the RTC if I know that it's gone bad. We've tried just about every experiment under the sun to try to get the RTC to fail in the office and can't, but you can guarantee that it will happen out in the field, it's rare, but it happens and when it does happen, it's painfully obvious.

Still need to find the issue with the RTC, but this gives a bit of a safety net as most of these units that require date/time have our modem board fitted.

Adrian

Perhaps a unrelated interrupt happening during low-level RTC accesses, resulting in stretched/incorrect transfer timing?

I have no idea, the RTC appears to have been reset (i.e the registers have gone back to "zero"), as far as I can tell this can only happen if power is removed from the RTC. The RTC battery backup is directly connected to the RTC, so even if the main power goes, the battery kicks in. On powerfail you cannot write to the registers of the RTC.

Infact, the only time we write to the RTC is when the device receives instructions to do it.

i2c (afaik) should be immune to timing, you can go as slow or fast (as long as the device can keep up) as you want. It's not even like a single register is getting corrupted, the whole thing just "resets".

It's very odd. The battery on it should be good for 20 odd years!

Thing is that these particular pieces of equipment are sat on poles by the side of the road, so it's not a convenient place to debug!

Adrian

I have seen many I2C style interfaces that clearly specify a minimum clock (yeah, sounds odd, but..). Going slower has unspecified side effects. So that's an outside possibility, but the chip datasheet ought to have something to say about that.

Apart from a chip bug, the only other thing that comes to mind is EMI / spikes on the interface lines or mains power to the chip.

I'm sure you're poking at that stuff already, but there's only so many ways to get an RTC chip to mess up. It's got to be one of them.

Cheers

High vibration/shock environment? Are these plug in batteries or an all in one solution?

Temperature?

EMI/EMC is my other thought too.

So is the RTC being corrupted whilst powered or on battery backup (or both)?