Q2686 - SIM phonebook init

#1

If the SIM Speed Enhance feature is enabled (which it is by default), sometimes the module indicates it has finished initialising phonebooks, but the SIM phonebook is not included in the list.

Ex (fail):
+WIND: 4
+WIND: 10,“ON”,0,“EN”,0
+WIND: 11,“D950D63A11CD01D287DAFEBA330B4C24”,“CCCADE35260DE31CC4EF57E61A430088”
AT+CPBS=?
+CPBS: (,“LD”,“MC”,“ON”,“ME”,“RC”,“MT”,“EN”)
OK

Ex (normal):
+WIND: 4
+WIND: 10,“SM”,1,“ON”,0,“EN”,0
+WIND: 11,“AED12B36455D20A07AE1524B11981B99”,“C3D42094E61C5EDB80A0B9AEDD3094D0”,“5F74DCE9EC505D349047EBF2D7CEC7F4”
AT+CPBS=?
+CPBS: (“SM”,“LD”,“MC”,“ON”,“ME”,“RC”,“MT”,“EN”)
OK

When SIM Speed Enhance is disabled with AT+WFM=0,“SIMSPEEDENH” and a reset, I haven’t been able to trigger the problem.

Anyone recognize?

#2

Maybe this is just (another) case of poor documentation?

I couldn’t see a definition in the AT Commands guide of exactly what happens when the “SIM Speed Enhance” feature is enabled - let alone how that should be expected to affect things like this… :cry:

#3

I see that all the time, so you are not the only one. I don’t explicitly use the phonebook, but I do send SMS and it has never been a problem. Do you whitness an impact on the functioning later on?

Regards,

wismo_coder

#4

Selecting SIM phonebook is one of the “checkpoints” in our application.
On Q24 this has never been a problem, and for a time we didn’t have any problems with Q26 either, but now it has appeared.

Testing have shown that it’s better to let the module take up towards 30 seconds to properly initialise all phonebooks than to hope it finishes all phonebook inits in 6 seconds.
This wouldn’t be a problem if the SIM phonebook could actually be selected after the fail-case described.

This particular problem we’ve managed to evade now by disabling the SIM Speed Enhace feature, but there are already way too many “features” or bugs in 6.60-6.63.

Examples of other problems:
The tone generator used to make DTMF sounds doesn’t work unless the module is forced into a mode where it consumes more power (Fast Standby Mode?). Our workaround: Pull DTR low before start playing DTMF sound.
The module can decide to switch over to Fast Standby Mode even though Fast Idle Mode is default, and there is no way to programmatically detect this condition or force it back down to Fast Idle Mode other than a reset. This can happen practically any time at all. Testing have shown days w/o a single problem as well as just a few minutes before it does this. Seems to trigger more often if there is data coming in on any UART repeatedly. Impact: ~18mA higher power consumption.
Use of AT+CCED=0,x to get TA information can make following commands take several seconds instead of 0.1s or less to finish.