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?
We really have to solve first the repeated READY. That is not normal and commonly caused by power supply related issue.
For the voltages, 3.6v should be fine but if you can have higher like with the 4.0v on DC source is better.
For test points, you can use the VBAT and GND header on RAK19001. Please measure it will oscilloscope and share it to me so we can see if there are any voltage dips.
FW BG77LAR02A04 version is ok and should work fine.
What FW are you using? Are there other modules except on RAK4631 and RAK5860 attached to the baseboard?
Thanks. Unfortunately I don’t have an oscilloscope available.
Power tests done so far: Li-SOCl2 ER34615M 3.6V 14.5Ah on the “non-rechargeable” input and a bench DC source at 4.0V with higher current limit and short/thicker leads. With a DMM we don’t observe any measurable VBAT drop during search/attach, but I understand this may miss fast transients.
Regarding the repeated RDY: AT interface remains stable and ATE0 persists (echo does not come back), so it doesn’t look like full reboots.
Hardware on the baseboard: RAK4631 + RAK5860, and RAK1904 (accelerometer) is installed. No other modules.
Since I can’t provide a scope capture, do you have an alternative verification method (e.g., recommended bulk capacitor value/location on VBAT as a diagnostic, or a way to check for reset reason/URC indicating brown-out)? If VBAT transients are the main suspect, would you recommend an RMA to rule out a faulty module?
Thanks, understood.
We will do a controlled test with a good quality 18650 Li-Ion directly on VBAT (no current limit, short leads) and run a minimal AT passthrough sketch for logging.
We will also remove the RAK1904 and keep only RAK4631 + RAK5860 on the RAK19001 to isolate any interaction.
Current FW on the RAK4631: we are using the official RAK example BG77_Unvarnished_Transmission.ino and our own minimal AT passthrough/lab test (Arduino IDE, RAK nRF52 BSP, board: WisBlock Core RAK4631 + RAK19001).
We will share:
the exact wiring of the 18650 to VBAT/GND,
the AT passthrough log (including RDY frequency),
results of ATI, AT+CFUN?, AT+CPIN?, AT+CEREG?, AT+QCSQ, AT+QENG="servingcell".
If the same behavior persists with 18650 on VBAT and only RAK4631+RAK5860, we will proceed with RMA via Zendesk as you suggested.