Q2698 NITZ handling different to Q2686

Hi All,

This is a quick heads up for those migrating from Q2686 to Q2698 and are using NITZ messages to set/discipline the internal RTC to keep reasonably accurate time on the module.

***NOTE: This assumes that your Telco issues NITZ messages. Not all do…

On the Q2686, NITZ notifications (+WIND:15 unsolicited messages) and Automatic RTC updates (+CTZU=1) are separate and discrete operations. That is, you can get NITZ notifications by setting bit 13 of +WIND (eg AT+WIND=8192). This will send unsolicited +WIND:15 messages to the console and your OpenAT application can also subscribe to them.
If you don’t want to handle the NITZ timesetting messages, you can enable the Automatic Time Zone Update functionality using AT+CTZU=1. Note that this will set the RTC clock on the module to the local time as described by the NITZ message - but the timezone information is lost.

On the Q2698 (in the latest 2.53 beta), the above is not true. NITZ messages are ONLY passed on to the module and OpenAT if AT+CTZU is set to 1. So by the time the application gets the NITZ message (UTC time and timezone), the RTC has ALREADY been adjusted to localtime by the firmware. If you are using the RTC to timestamp data, then you potentially have a clock jump to deal with. Setting AT+CTZU=0 disables the automatic time updates BUT ALSO STOPS THE UNSOLICITED +WIND:15 NITZ messages being passed on to the application. In the latter case, you then can’t use the NITZ messages AT ALL to discipline the clock.

This is also a problem where the module is in an area that crosses timezone boundaries and is switching between cells on either side of the zone boundary (Coolangatta/Tweed Heads on the Qld/NSW border in Australia is a case in point - but there must be lots more). As the module switches between cells, the RTC is moving backwards and forwards as it connects to different cells.

Solution? You’ll have to use another method of setting/maintaining the RTC on the Q2698 - GPS if you’ve brought the GPS antenna out, or NTP across the network.

Note that this also applies to those transitioning to the FTX100 and some of the SL series modules as well.

ciao, Dave

Sounds like a BUG to me - and something that needs to be fixed :exclamation:

:open_mouth:

There are places on the English South Coast where there’s no service from the English networks, but French networks can be seen (I guess the converse may apply in France?).

This could lead to some really obscure & hard-to-debug problems…

:open_mouth:

Lots of useful timezone info here: worldtimezone.com/

Including timezone maps - which clearly show that there are lots of places where timezone borders occur on dry land…

Hiya,

You and me both. My SiWi FAE also thinks that it’s an issue - and has pushed it further up the chain - but apparently it’s “just the way the qualcomm chipset works” and is not likely to be fixed. Let’s just say I’m less than impressed.

A long time ago I was using mobile phones on the north coast of Tasmania that were registering to cells across Bass Strait in Victoria. It led to some questions being asked when the bill came in!

You’re not wrong there.

But I wonder how many run down the middle of a street in a major urban area? It’s a perennial problem here when New South Wales goes onto Daylight Savings time and Queensland doesn’t. And then there are the proposals for SE Qld to go onto daylight savings and the rest of the state not to - a timezone boundary within the state…

Arrgghh. Just make it easy for me to keep time in UTC…

ciao, Dave

ISTR it used to be the case that England & France switched DST at different times - but I think we’re synchronised now.