When I setup M95 modem to synchronize clock with the cellular network, the clock is not set up correctly:
AT+CTZR=0
OK
AT+QNITZ=1
OK
AT+CTZU=1
OK
Then I do:
AT+QLTS
+QLTS: “19/10/08,12:11:49+08,1”
OK
AT+CCLK?
+CCLK: “19/10/08,13:11:54+08”
OK
The QLTS hour is correct, but modem clock is set 1 hour later.
I have seen this happen also with other modem models (BG96) and also with AT+QNTP.
Does anyone know why that happens?
I did some tests with CTZU=1 =2 and =3
My previous results were bogus, because the RTC clock is not updated immediately after QLTS reports the new time. Go figure why!
So now I confirmed: the following:
Here in Italy we are in Time Zone +01hr and we have DST, so we are 2hr later than GMT, or better UTC.
So what happens is that the modem sets the hour according to CTZU mode setting, but does not change the TZ offset accordingly, so it’s impossible to tell what time the RTC clock is using. If you assume the time format of CCLK is GMT “hh:mm:ss±zz” (as it is documented) you get the wrong time!
Dear Sir,
Could you try to follow up the following steps to confirm GSM network time synchronization? Thanks!
Thank you Kyson, I didn’t know I had to reset the modem for the time synchronization settings to take effect.
Anyway, you just proved what I said:
QNITZ reports time as 07:09:54+32 (that is 7 hour GMT +8 hours timezone)
Afterwards the RTC clock is set to 15:09:54+32 (that is 15 hour GMT +8 hours timezone)
The RTC clock has been updated to the local time (7+8=15) but the timezone offset is still there. This is confusing. How do you know the RTC clock is using local time if you keep the timezone offset? To interpret CCLK result correctly you have to know it’s using local time and then the time format is something like LOCAL time + TZ offset.
In order to avoid confusion, I will use CTZU=1, as that seems to keep the time received by the GSM network unchanged, which is correctly in the expected format (GMT time + TZ offset).
Dear Kyson,
Could you please explain in which part of 3GPP 27.007 standard described that the parameter of the command +CTZU can have have values other than 0 and 1? Whether does Quectel not follow 3GPP standards?
Just for information, +CTZR works not according the standard also. According the standard the module with AT+CTZR=2 setting should derive the local time in URC but all Quectel modules derive the GMT time. This is a minor bug, so no one pays attention to it.
Dear Servo,
Please note that GSM module follow up the GSM 07.07, 07.05 and other enhanced AT commands developed by Quectel. I do not know why you will said the 3GPP 27.007, the standard is apply for traditional GSM module ?
Thanks for your information, if it is really our software bug, we will modify it as soon as possible.Thanks!
Dear Kyson,
thanks for the response. Either +CTZU nor +CTZR are not defined in the GSM 07.07, which is predecessor of the 3GPP 27.007. So I refer to the last one. But it is not change the meaning of my post. Quectel does not follow the standard. According the standard the parameter of +CTZU must have values 0 and 1. So if the values of the parameter will be extended the values used by Quectel can interfere with new definitions. That is the one inconsistency.
Further more, Quectel does not make sure that this setting has the same value in all of its modules. For example, + CTZU in UC15 has two meanings, as in the standard. Therefore, if we move from the GSM module to UMTS, we will get incompatibility. In addition, for some modules, this parameter has a default value of 3, and for others, 0. This is the second inconsistency.
Even more, Quectel does not monitor the consistency and uniformity of commands formats for all of its modules. Therefore, we must more carefully check the algorithms for compatibility with Quectel modules when moving from one to another. That means we must do the work of Quectel testers. This is extremely sad.
Dear Servo,
Thanks for your clarification.
For your concerns, different module use different chipset, such as GSM module, we use Meditake chipset, UMTS module we use Qualcomm chipset. Quectel also should follow up the chipset spec.
About the command CTZU, different chipset have different mechanism to deal with it, it is hard to do the same for different chioset. For Quectel, we also need to follow up it, and do some basic extension, all modules cannot use the same instructions, they are all more or less different.
Sorry that this causes you any inconvenience. Thanks!
I have a similar issue with the BC66. After recent DST updates, AT+CCLK? does not return the correct time zone. It returns the correct time zone after a reset and re-registration with the network which is a very poor way of handling the update.
