"PDP DEACT" every 60 minutes on SIM7000E

[knee-cola]

When using "+PDP: DEACT" I noticed that exactly after 1 hour (60 minutes) of normal exchange of messages SIM7000E reports "+PDP: DEACT" and no further communication is possible.

Here's a trace from serial port:

==========> mqtt.readSubscription
	---> AT+CIPSTATUS
	<--- 
	---> AT+CIPSTATUS
	<--- 
==========> mqtt.connected
=> No connection detected
=> Connecting to MQTT... 
	---> AT+CIPSHUT
	<--- +PDP: DEACT
Connection failed
	---> AT+CIPSTATUS
	<--- OK
	<--- STATE: PDP DEACT
	---> AT+CIPCLOSE
	<--- ERROR

This issue has been documented also with other SIM modules (i.e. SIM800L +PDP: DEACT).

I might conclude that this issue is not caused by a bug in Adafruit_MQTT or Adafruit_FONA, but is probably an issue of SIM module or how mobile cell towers work in general.

As far as I can tell the best/fastest way out of this situation is to reset the modem (via PWRKEY pin) and then re-initializing the system whenever mqtt.connected() fails. I'm still testing this solution...

[botletics]

Check to see if you have data left in your SIM card.

[knee-cola]

I still have plenty megabytes left on my mobile dats plan subscription if that's what you mean.

What's indicative is that this happens exactly after 60 minutes after a connection has been established

Could it's be a way the mobile operator forces us to reconnect in order to assign us a new IP address (ADSL routers usually do that every 24h)?

[botletics]

Oh hmmm, I'm not sure. Have you tried a different MQTT broker to test?

[knee-cola]

I have not tried it (I'm using latest Mosquitto server). I think this is not due to the server. The problem is on lower network carrier level.

After some research I found that PDP stands for Packet data Protocol, which is even lower level than TCP.

Then I had a look at source code of Adafruit_MQTT and Adafruit_FONA libraries to find out what happens when a call to mqtt.connect() is made. Here's a pseudo code diagram:

mqtt.connect => connectServer => fona.TCPconnect() => sendCheckReply("AT+CIPSHUT")

The problem here is that sendCheckReply expects SHUT OK response, but it gets +PDP: DEACT every time.

Based on the diagram found on page 25 in SIM800+ TCPIP Application Note at this point the GPS/LTE is already in initial state meaning there's no need for another CIPSHUT command. Instead the connection should be restarted.

The problem here is that Adafruit_FONA does not support a "+PDP: DEACT" reply from SIM module and as a result doesn't handle it at all.

Maybe the the following change in Adafruit_FONA::TCPconnect would fix this problem:

  // close all old connections
  // >>> PENDING REMOVAL <<< if (! sendCheckReply(F("AT+CIPSHUT"), F("SHUT OK"), 20000) ) return false;
  if (! sendCheckReply(F("AT+CIPSHUT"), F("SHUT OK"), 20000)
      && ! sendCheckReply(F("AT+CIPSHUT"), F("+PDP: DEACT"), 20000) ) return false;

EDIT: I have tested the above code but it did not help.

Then I tried to perform a "soft reset" by:

• executing AT+CGDCONT=1,1 command (Adafruit_fona executes this command in setFunctionality without the second "1" in param list)
• calling fona.setNetworkSettings

This also didn't work.

I tested my solution by connecting to io.adafruit.com - the same error happens.

The only thing that works is to physically reset the modem via PWR or RESET.

I'm suspecting this might be (a) a firmware bug or (b) a network thing performed by cell tower

[pmethods]

Good thread.

Over the years, with different embedded solutions... especially those that have multiple onboard MCU's performing different activities...

I have often had to implement some sort of Rest Heartbeat.

This was always true (for me) with the original Bluetooth dongles. In that particular case I would run an N-Channel fet to the reset line and hard-cycle their power on a 10 second timer.

I am not saying this is elegant, but I am giving affirmation that if you are RUSHING to get something to MVP it is an acceptable practice to repeatedly cycle the power of next assembly.

Later, after the storms have passed... you can go back and Root Cause the issue.

... I am not saying Power Cycle that thing - but I do believe you are on the right track thinking that you need to refresh or update on some sort of cycle. Every time in my career that I tried to avoid this (with these sorts of AT command modules) I lost hours/days that were in the critical path.

Good luck and thanks for sharing your troubleshooting

-Schindler

[shutterspark]

@knee-cola I see you are able to succesfully connect to mosquitto server. Would you be willing to share your code showing how you were able to accomplish this? I have been posting data to adafruit.io with no issues, however I am transitioning to mosquitto and cannot for the life of me get the code working to connect to the server

[knee-cola]

@shutterspark I've created a gist containing a basic example here: arduino-mosquitto-basic-example.ino.

The solution however uses Ethernet shield instead of SIM7000 and PubSubClient.h instead of Adafruit_MQTT.h, but that shouldn't make any difference.

P.S. Make sure to test your Mosquitto server connectivity by connection manually via mosquitto_sub and mosquitto_pub from a remote machine. If that works then the client should work too.

[shutterspark]

@knee-cola Thank you! I actually got it working yesterday using "Adafruit_MQTT_FONA.h" with the sim7000G, pushing data to mosquitto running on cent OS. Now I am in the market to get SSL certs loaded so i can send to port 8883. I have been combing through the forums for sim7000 and this seems to be a hot topic.

[jaka87]

I have similar issue. After 1-10days connection is dropped on sim7000E and module doesn't reconnect. In my network provider log there is "PDP Context deleted" I do understand that connection may drop from time (although my signal quality is quite high so there shouldn't be disconnects so often) and i have checkups in the code for connection with server and GPRS connection but how restart network connection when checkup finds ther is no connection? I tried using AT+CFUN=0 and then AT+CFUN=1 but it didn't work Restarting the module by pulling PWRKEY works but i would ideally like to avoid that.

Here is the log from my module when this happen...

22 01 01 36 37 411   b'\t---> AT\r\n'
22 01 01 36 37 431   b'\t<--- OK\r\n'
22 01 01 36 37 445   b'Modem active\r\n'
22 01 01 36 37 476   b'\t---> AT+CSQ\r\n'
22 01 01 36 37 514   b'\t<--- +CSQ: 99,99\r\n'
22 01 01 36 37 844   b'\t---> AT+CBC\r\n'
22 01 01 36 37 909   b'\t<--- +CBC: 0,67,3875\r\n'
22 01 01 36 37 952   b'\t---> AT+CIPSTATUS\r\n'
22 01 01 36 37 978   b'\t<--- ERROR\r\n'
22 01 01 36 37 992   b'UDP STATUS 0\r\n'
22 01 01 36 38 023   b'\t---> AT+CGATT?\r\n'
22 01 01 36 38 045   b'\t<--- ERROR\r\n'
22 01 01 36 38 090   b'\t---> AT+CGREG?\r\n'
22 01 01 36 38 125   b'\t<--- +CGREG: 0,0\r\n'
22 01 01 36 38 159   b'Network status 0: Not registered\r\n'
22 01 01 36 38 207   b'Failed to connect to cell network, retrying...\r\n'
22 01 01 36 40 130   b'\t---> AT+CGREG?\r\n'
22 01 01 36 40 166   b'\t<--- +CGREG: 0,0\r\n'
22 01 01 36 40 200   b'Network status 0: Not registered\r\n'
22 01 01 36 40 248   b'Failed to connect to cell network, retrying...\r\n'
22 01 01 36 42 170   b'\t---> AT+CGREG?\r\n'
22 01 01 36 42 206   b'\t<--- +CGREG: 0,0\r\n'
22 01 01 36 42 241   b'Network status 0: Not registered\r\n'
22 01 01 36 42 289   b'Failed to connect to cell network, retrying...\r\n'
22 01 01 36 44 211   b'\t---> AT+CGREG?\r\n'
22 01 01 36 44 248   b'\t<--- +CGREG: 0,0\r\n'
22 01 01 36 44 282   b'Network status 0: Not registered\r\n'
22 01 01 36 44 330   b'Failed to connect to cell network, retrying...\r\n'
22 01 01 36 46 253   b'\t---> AT+CGREG?\r\n'
22 01 01 36 46 288   b'\t<--- +CGREG: 0,0\r\n'
22 01 01 36 46 323   b'Network status 0: Not registered\r\n'
22 01 01 36 46 371   b'Failed to connect to cell network, retrying...\r\n'
22 01 01 36 48 292   b'\t---> AT+CGREG?\r\n'
22 01 01 36 48 329   b'\t<--- +CGREG: 0,0\r\n'

[botletics]

What is your AT+COPS setting?

[jaka87]

i believe it is set as automatic (0)..

+COPS: 0,0,"A1 SI A1 SI",9 I will try to run AT+COPS? before restarting the module to see if the output will be the same when the error happens

[botletics]

Perhaps you could use AT&F0 to factory reset the module, then use AT+CFUN=1 and see if it resets.

[jaka87]

I have done some testing on multiple locations and it seems it loses signal every few days on all locations even the ones with excellent signal. Im still not sure if this is hardware, software or network issue.

Here is a sample from my sim card

[jaka87]

I also spoke with the network provider that confirm that they did in fact had some network trouble at that time. They did also comment that it appear that I tried to establish 4 different connections and they believe that this is the cause of the trouble...

Im not sure how exactly could this happen since i have AT+CIPMUX=0 Any idea ?

[jaka87]

It seems the problem is that I am executing AT+CIPMUX=0 command to late when connection is already established. Small change in code seem to fix this issue for now.

[theMASTERMINDpK]

I'm also having the same problem. Even my connection is disconnected in 20 minutes instead of 60. One thing is confirmed it's not due to server. It's mobile operator