I am having some trouble with the reliability of the WP7700 modules.
A few times a day I will encounter the following error: swiQmi.c swiQmi_CheckResponse() 820 | Sending QMI_NAS_GET_SIG_INFO_REQ_MSG_V01 failed: rc=0 (), resp.result=1.[0x01], resp.error=74.[0x4a]
Previously when I was getting this error the radio would be in the off state and be unable to turn on (cm radio on was ineffective), and AT!PCINFO? would indicate W_DISABLE was set.
I have since issued the command AT!PCOFFEN=2 and the W_DISABLE is no longer being set. The radio is now staying on (cm radio indicates power is on), but that error is being spammed in the log and signal strength stays on 0.
AT!IMPREF? does not indicate an image preference mismatch.
It sounds similar to the issue reported in this thread, however disabling W_DISABLE has not fixed the issue.
Hi @shib, that error (0x4a) translated means that there’s no measurement information available to provide. That can indicate that the radio is in the wrong state (i.e. LPM), or just has no measurements to provide.
Do you have good LTE Cat M1, NB-IOT, or GSM coverage locally? Some diag responses might shed some light: just “cm radio” and “cm sim” should give some idea of the environment, and “cm radio getRAT” might show that you’ve got a subset of access technologies enabled for which there’s no (or close to no) local coverage. I was able to reproduce that error message in two ways at my desk:
Enable only one band, for which there’s no local coverage (even with no antenna, I still get a signal strength).
Hold modem in LPM.
Even with no SIM, or with a SIM but an inactive account, I was still observing valid signal strength information, once I allowed time for a scan. I’m just sampling this though, so not performing a long-term reliability test of the message. If your coverage is so poor that it occasionally loses the signal, that’s a possible cause.
Thanks Ryan, that might help. I will check back in when it happens again.
I am away from testing for a few days, but hopefully should have some feedback after that.
The signal strength normally sits at 4-5 with LTE (pretty sure it is Cat M1 but I haven’t actually checked) when they are working properly.
The error message always coincided with being put in LPM by W_DISABLE. Since disabling with AT!PCOFFEN the problem still occurs, just that the radio stays on now…
some more info for you.
When this happens cm radio shows 0 signal strength. I let it sit for a few hours, but the device never registers any signal.
Reset the device and on next power up it had full signal (5) in less than a minute.
This is happening pretty frequently on power-up. It doesn’t happen as often when the units are running.
I was also disappointed to find that pa_mrc_SetRatPreferences() has been so hamstrung that ‘cm radio rat’ it is basically useless. Doesn’t support even a quarter of the options of AT+KSRAT.
root@swi-mdm9x28-wp:~# cm radio
Power: ON
Current Network Operator:
Current RAT: Not available
Status: Not registered but currently searching for a new operator (LE_MRC_REG_SEARCHING)
Signal: No signal strength (0)
PS: Packet Switched Not registered (LE_MRC_REG_NONE)
root@swi-mdm9x28-wp:~# cm sim
SIM card is inserted and unlocked (LE_SIM_READY).
root@swi-mdm9x28-wp:~# cm radio getRAT
Prefered RATs : GSM LTE
Hi @shib, sorry for the delayed response. Regarding the “cm radio rat” command - it accepts a bitmask, and it’s slightly different than +KSRAT in that it only accepts the supported RATs, whereas you’ll see options with UMTS in the mask for +KSRAT. Does that explain the difference you’re seeing? For WP77xx, the only valid combinations for cm radio rat would be “GSM”, “LTE”, or “GSM LTE”. If you want to try to narrow down the LTE capabilities, in case you suspect a difference there, AT!SELCIOT can enable only Cat-M1 or NB-IOT, which can optimize scan times if you know you have no service in one or the other. If I’m misinterpreting the problem with pa_mrc_SetRatPreferences(), let me know and I can follow-up.
The fact that the issue seems to coincide with an unexpected W_DISABLE signal is alarming to me. In the thread you linked, the root cause of that unexpected signal wasn’t described. Are you using a mangOh platform (as in that thread), or something custom?
Do you have any custom software that might be exercising radio control APIs when coverage is lost? I’m not aware of anything specific, but I wonder if the radio could be accepting a mode that isn’t valid, leading to it becoming stuck in this state. If you can get a device in this state, you could try a series of AT!GSTATUS? to get an idea of the band’s being scanned. When in a no-service state, you’ll see periods of idle, which is a power saving mechanism if the device thinks there is no signal. But if you keep sending the command, you should see some cycling band information during the scans, in this state. Feel free to send me a log of this by attachment, and I can see if there’s any clues there.
Lastly, if there’s any reduction of variables you’re able to make to narrow down the issue, that would be good to try. For example, if this isn’t the baseline WP77 software release, it would be good to confirm whether or not it happens with that (also, which Modem release is being used?). Same for hardware, especially based on the W_DISABLE problem - if this isn’t a mangOh platform, it would be good to have a result from some reference hardware, if possible.
There is some discrepancy between the AT command reference r6 and the capabilities of “cm radio rat”. If I understand you correctly “cm radio rat” will accept only valid options, pa_mrc_SetRatPreferences and AT+KSRAT accepts options which may be invalid.
It is interesting to note that the units come shipped with GSM LTE which is actually invalid for the WP7700 (2G has been turned off in Australia anyway).
I am using the mangoh platform. I have been jumping between different versions of things to try to get something that is stable. Previously I have been using 18.10.3 with the mangoh apps installed, currently I am using stock legato 18.6.1 with my own app. Things are definitely more stable without the mangoh apps running.
I do occasionally see devices that are unable to get a data connection, but no longer see W_DISABLE since issuing AT!PCOFFEN=2.
My application requests a data connection through le_data_Request(), when a valid data connection exists it uploads data from an external device to our server. In this instance the mangoh is being used as an IoT gateway for some existing logging devices.
I am doing a bit of dev work right now, but will have to program over 100 units when this is done, when I encounter this problem next I will send you an update.
Sorry for the delay in revisiting this, I have only just encountered this issue again.
My own investigation points to this error being caused by a poor antenna connection, I am not sure whether this was the issue with the original device, but on its most recent occurrence the fault was in the antenna connection.
I was able to reproduce the error by removing and replacing the antenna on a device with an active data connection. On doing so the device would repeatedly display the error below, and never recover its data connection.