This is a question about the AT#SGACTCFG command.We are operating a mobile device based on Telit GE865 QUAD. Firmware version is 10.00.005.
At startup, AT#SGACTCFG=1,10 is sent to the modem (among others of course).
Then, periodically, a connexion is made to a http server using the following instruction:AT#SD=1,0,80,"ourserver.com"(and then we send the http request and get the answer from the ourserver.com)
This works very well most of the times, but sometimes, after some days, it stops working.What I mean is that the modem fails to establish a connexion with "ourserver.com".When restarting the unit, the connexion works ok again immediately (so we understand it is not an issue linked to the GPRS network)
When reading the "at command reference quid r 17",we can see that the AT#SGACTCFG provides a parameter for the maximum number of activation attempts.The question is: what happens when this limit is reached?What are we supposed to do to tell the modem it has to try again when the limit of 15 attempts is reached?
Thank you for your help,Philippe
AT#SGACTCFG is used to enable automatic PDP context activation/reactivation i.e at power on after every GPRS attach or after a NW PDP deactivation.
In your case AT#SD fails, what I don’t know is if PDP is still active or not. You can check this with AT#SGACT? or AT#CGPADDR=1
In case the <retry> limit is reached, the module will not do any further attempt to activate the context automatically. It can be done manually with AT#SGACT=1,1
Hello Andrea (and everyone reading this),
Thank you for your answer. Please have a look at the way we’ve been connecting to our server, for years, with no problem:
*****************At module startup: AT+CGDCONT=1,"IP","apn","0.0.0.0",0,0AT+CGQREQ=1,0,0,3,0,0AT#SGACTCFG=1,10
When a connection is wanted:AT#SD=1,0,80,"domain.com"wait for CONNECT, send and receive data.*****************
The situation is that some of our units are now running for weeks, months without any reboot. (which was not the case before)And we begin to face the issue which is the subject of this post on these units.So it could be that the automated activation of the context has reached its limit of 10 tries?
I understand your suggestion of checking the status of the context before using it with at#SD.What is not clear to me is the idea of having an automated activation of a context BUT that has to be "manually" checked before every connection.Which is interest of #SGACTCFG in this case?
you are right, it was mainly for me to understand if the socket is not open because PDP is not active (module not registered, not attached) or failing because TCP/IP handshake.
Basically if the context has reached its limit of 10 consecutive tries (by default every 180s) it stops till the module attaches again to GPRS. When context is activated the number of retries are cleared.
Do you know what kind of error you receive when AT#SD fails?
We started a test to know which is the error return by #SD.
I’ll let you know when we have the results. (it could take a few days or weeks..)
Thank you again, have a nice week end.
I’m back with the test results!The test is to have a unit trying to connect to our http server every 12 hours and try to understand why after some time it stops working.
The connexion test is made this way:1- check GPRS attachment (+CGREG?)2- if CGREG reports ok, try to connect (AT#SD=1,0,80,”domain.com”)
The connexion worked fine from 2014-09-25 until 2014-10-05 (21 successful connexions exactly).Then, we had a first answer: CME ERROR: context not opened. Since, AT+CGREG? command reports there is no GPRS registration (and thus AT#SD command is not sent to the modem).
What do we do wrong?
What exactly GPRS registration status anser is given to AT+CGREG?
It would be also interesting to activate GPRS events monitoring +CGEREP and also gather cell info with AT#SERVINFO and AT#MONI.
Does a modem reset restore the normal situation?
Sorry we dont have the exact answer from +CGREG?. (this call is embedded).
What we know is that this answer does not contain +CGREG: 0,1 or +CGREG: 0,5.
Yes a modem reset makes connexion ok again.
Of course this would be a solution: reboot when we are not attached to GPRS anymore.
But we suspect something related with the automatic activation of the context, and thus hope there is a better solution (eg reactivate the context when the limit of 10 automatic retries is reached).
Thank you for your help,
Maybe a better solution is to completely de-register from the network with AT+COPS=2 then re-register..
Nevertheless the other tests would help finding the cause.
I also sent download links for 10.00.xx8 and 10.01.xx0 firmware, try them.
Thank you for the links, Cosmin.
Do you know which is the effect of +COPS=2 on the existing automatic context activation created by #SGACTCFG?
Sorry to ask so many question but since the issue occurs after some many days I’m trying to save some time…
Because this also implies GPRS re-attach as per Andrea words the counter is cleared.
I’m sorry Cosmin but I feel lost.
We do this once, at module startup:
AT+CGDCONT=1,"IP","apn","0.0.0.0",0,0 (for context creation)AT+CGQREQ=1,0,0,3,0,0 (for demanded signal quality)
AT#SGACTCFG=1,10 (for automatic context activation)
AT#SD=…(for opening tcp connexion).
You are telling to re-attach (when at#sd fails), but I simply don’t understand what it means.
Among the 3 commands here above, which is the one that attaches the modem to the GPRS?
None of them. Manual GPRS attach/detach is made with AT+CGATT or can be automatically performed after startup/registration with AT#AUTOATT.
Ok, now I understand!
We will run a new test with GPRS detach and reattach when the issue occur.
I’ll let you know the result of it.
Thank you again,
Hit enter to search or ESC to close
Knowledge Base & Download Zone