AT+QOPS? on M66 causes hangs for other commands

IoT Modules GSM Module
1

Hello,

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.

2

Hi,

In this case we need to analyze chipset logs of the module, Please contact our local FAE to get the log tool and they will help to analyze the reason. Your firmware is not the latest one so first you will get the latest firmware from local FAE and upgrade the module. You also can send email to support@quectel.com to get the support from local FAE. Thanks!

3

Thank you. We have sent a mail to support@quectel.com with a reference to this forum post for explanation, and we’re waiting for reply. I’ll post here later if we have any progress on the issue.

4

Hello,

With great support from Quectel (many-many thanks!) we have solved our issue, and I’m back here to report, to potentially help future readers with similar problems.

First we were sent a new firmware (M66FAR02A06BT), this didn’t solve anything yet, but just for reference, we were using this firmware in all later experiments.

To actually solve our issues, we made two changes. Based on advice from Quectel we made sure that QOPS isn’t called while the modem is still in the process of GPRS registration. After this change QOPS always finished reliably and we were left only with the issue where QHTTPPOST occasionally (but pretty frequently) stayed hanging.

This second issue turned out to be a problem with our power supply. We were using a lab supply in all previous tests to feed our in-application DC-DC converter, and apparently this lab supply doesn’t react fast enough to load spikes, which lead to voltage drops during data transmissions. We didn’t think of a power supply issue earlier because we could only observe the problems with a specific network operator (with good signal strength). Measurements with an oscilloscope showed the voltage on the VBAT pins of the M66 dropped to 3V occasionally for about 440us, whereas the lowest acceptable according to a Quectel engineer is 3.3V. After replacing the lab supply with batteries, this issue disappeared too and we cannot reproduce any of our original problems anymore.

Two days have passed since then with intensive testing and the M66 module seems to be rock-solid in our application now.

Thanks for Quectel’s support!