SIM7020G unresponsiveness
-
We are currently having issues with our new batch of NB-IoT devices equipped with the SIM7020G modem (own PCB design).
With the previous batch (100 devices) we encountered no communication issues using this exact software and hardware design, however with this batch we do seem to have a problem. Both batches are running the same FW version (Revision:1910B05SIM7020G).Problem:
• Devices at some point become unresponsive to AT commands sent to the 7020G modem.
• When rebooting the modem using the PWRKEY we get responses to the first couple of AT commands, but after a while (several seconds) the modem stops responding (no AT echo and response anymore).The AT commands I am sending are:
- AT+GSV
- AT&V
- AT+GSN
- AT+COPS?
- AT+CFUN=0
Waiting up to 30 seconds for “OK” response here. - AT*MCGDEFCONT=“IP”,“cdp.iot.t-mobile.nl”
- AT+CFUN=1
- AT+CBAND=8,20
- AT+CBANDSL=0
- AT+CRESET
Short wait here for boot time. - AT+CSMINS?
Modem does not become unresponsive after a specific command, this varies. And at times, devices are not able to get responses from the modem at all on one day, but can run perfectly fine the day after.
I have tested with several batteries, with different antenna’s connected (U.FL) and by using different SIM cards. Am also not able to detect a voltage drop on the VCC when sending my data.
Anyone ever had any experience like this?
Again, I am using the same SW and HW as before… -
What a strange and annoying problem! I think that it makes most sense to report this problem directly to Simcom. But in the meantime I have asked some colleagues if they recognize this behaviour.
Will let you know
-
“Might be a different default setting for the UART slow clock control.”
-
Thanks for the quick reply.
Unfortunately, I have already verified that slow clock is disabled in both batches, meaning the device should not enter any sleep mode on its own.SIM7020G: AT+CSCLK? +CSCLK: 0
-
Both batches are also booting with the same ‘active profile’.
SIM7020G: AT&V ACTIVE PROFILE E: 1 L: 0 M: 0 Q: 0 V: 1 X: 4 S0: 0 S1: 0 S2: 43 S3: 13 S4: 10 S5: 8 S6: 2 S7: 60 S8: 2 S10: 15 S12: 50 S25: 5 +CMGF: 0 +CSDH: 0 +CMEE: 0 +IFC: 0,0 +ICF: 3,3 +CNMI: 2,2,0,1,0 +CSCS: "IRA" +IPR: 0 &C: 1 &D: 2 +CGEREP: 0 +CEER: 0 +CGPIAF: 0,0,0,0 +CPSMSTATUS: 1 +CSMINS: 0 +CMUX: 0,0,0,31,10,3,30,10,2 OK
Also ending with OK instead of ERROR.
However, I have not yet looked into the meaning of every value in this status report before. Just printing this for debugging purposes if our DEBUG mode is on (extra Serial prints in the lib). -
Hello @meneerjacco
what about power saving mode? Maybe that’s enabled by accident?
AT+CPSMS?
Thanks
Felix -
@MeneerJacco any news? Did you reach out to Simcom?
-
Yes, getting to the right person at SIMCom took longer than we hoped.
Nevertheless, we might have a solution for our problem (stress-tests currently running).SIMCom is unclear as to why the previous batch did not have this issue, but they suggest that the trace width at the VBAT “line” to the SIM7020G modem is too narrow (0.254 instead of 1 mm) and can limit the current provided when modem is actively using the LTE antenna.
So, currently bypassing this VBAT trace (except for the reference design’s capacitors and TVS) and connecting the VBAT pins straight to the 3.6V battery.
We’ll see next monday if all our testdevices are still up and running. -
They are still running, so this seems to be the (temporary) solution.