We are using the M66 (ver1) module revision M66FAR01A12BT. We are using “AT+QOPS?” as documented in the “GSM QuecCell AT Commands Manual V1.1” with the goal of collecting cell tower information for location estimation.
Our problem is that with some SIM-cards, this command seems to prohibit correct operation for later AT commands until the modem is power-cycled. For example, if we insert a SIM from Telenor Hungary (we are in the home network 21601), everything works fine. This means, QOPS returns with the list of operators and cells and we can continue to attach GPRS and use QHTTP* AT commands to do our communication. Everything is fine in this case.
However, if we replace the SIM card with one from A1 Austria (in which case it registers itself with the roaming partner 21670), then only simple getter/setter commands work after QOPS, and network-related commands hang indefinitely. QOPS itself often hangs with this SIM card (but not with the Telenor card), but even when it works, QHTTPPOST always hangs afterwards.
We initially thought this might be a roaming or data problem, but it soon turned out this is not the case. If we do QOPS before registering on the network, then the modem hangs already at network registration (AT+COPS=0) afterwards. Otherwise network registration is OK.
In a third test-case, if we do not issue QOPS at all, then we can register to the network and send data using QHTTPPOST consistently without any problems with both SIM cards. In other words, it is clear that problems only occur after issuing “AT+QOPS?”. Only simple command like AT+QIFGCNT=0 or AT+QIDNSIP=1 still work after that.
The problem is 100% reproducible, at least with this SIM card. The only uncertainty is whether AT+QOPS? itself hangs or returns with the list and an OK, but even when it finishes correctly, the next network operation surely hangs afterwards. When the modem hangs, it must be power-cycled by hand. It does not react to AT+QPOWD=1 and toggling the PWRKEY pin also doesn’t help.
We are asking for Quectel’s help with this problem. Maybe this is a known problem and a firmware update exists to solve it. Or maybe we can bring back the modem after AT+QOPS? into a known working state with another AT command. Or maybe AT+QOPS can only be called at very specific times (not documented in the manuals) to not cause problems.
Thank you for your support.