emnify
(Behavior is similar across SIMs: registration/attach not reliable.)
AT
OK
RDY
ATE0
OK
RDY
RDY
AT+CMEE=2
OK
RDY
RDY
AT+CPIN?
+CPIN: READY
OK
RDY
RDY
RDY
AT+QCCID
+QCCID: 89883030000131874932
OK
RDY
RDY
AT+CIMI
295050907578194
OK
RDY
RDY
RDY
AT+CFUN?
+CFUN: 1
OK
AT+CEREG?
+CEREG: 0,2
OK
RDY
RDY
RDY
RDY
AT+QENG="servingcell"
+QENG: "servingcell","SEARCH"
OK
RDY
RDY
RDY
RDY
AT+QNWINFO
+QNWINFO: No Service
I’ve sent you the flowchart we follow via Zendesk.
With regards to these AT commands, it appears to me that it has no stable power supply. Maybe you can increase the current limit of your DC supply or use a more reliable cable? Maybe there are dips on voltage?
Hello @carlrowan!
Thanks for the flowchart. We already followed the same high-level steps (CPIN/CEREG/QICSGP/QIACT), but we never get service: QCSQ: "NOSERVICE", QNWINFO: No Service, QENG servingcell: "SEARCH", neighbourcell empty.
Regarding power: we tested multiple supplies (bench PSU with current limit raised, short/thick leads, different cables) and also a 3.6V Li-SOCl2 ER34615M 14.5Ah pack. The module answers AT commands consistently (ATI/GSN/CFUN/CPIN OK) and ATE0 stays effective across the repeated RDY URCs, so we don’t see evidence of full resets.
To close the power question, can you point us to the exact VBAT test points / expected minimum VBAT at the RAK5860 during network search? Also, is there a recommended firmware update for BG77LAR02A04 on RAK5860, or a known limitation (e.g., missing AT commands like CLAC/QSCAN/QSCAN=? returning ERROR)?
Finally, do you have an RF sanity test procedure to verify the LTE MAIN antenna path/port (without depending on network registration)? If not, would you recommend RMA for the RAK5860 module?