GE 865 Quad command timing

17 thoughts on “GE 865 Quad command timing

  1. Hi,


    I’m currently developing an application using the GE865 Quad to upload data to a server via TCP.


    Very often the GE865 responds to the AT#SGACT=1,1 command with an error. So I added a delay between the network registration acknowledge (AT+CREG: 0,1) and the SGACT command. This improves the situation a lot but sometimes I still get an error.


    I can observe the same behaviour with the AT+CGDCONT command.


    Is there a minimum delay time between commands?


    Thank you in advance.


    Best regards,


    1. The advise is to wait at least 20 ms after the last module response, if any, but I suspect you are refering to much larger delays?

      1. Hi,


        yes it’s right I added a 2 seconds delay before enabling GPRS via AT#SGACT=1,1.


        First I tried 1 second but I still got a lot of errors. 

        1. Oh after the network registration follows the GPRS attach etc. so the inner network work might still be in progrees and really not yet prepared for a socket opening.

          So monitor AT+CGATT too, and even after that some delay might be needed, depending of network, APN, firewals+gateways etc.


          1. Do you mean to activate the GPRS context or to open a socket connection?

            For the former: Good signal and GPRS service attached are mandatory but these won’t warrant the APN is fit ot serve you, obtaining an IP will be the confirmation.

            For the latter: so you have an IP, the APN should be OK but something wrong can still come from the rest of the network. You can test with a ping or DNS query however only the real succesful socket connection is the ultimate confirmation of the network state.  


          2. So trying to activate GPRS until an IP is received is the right way to come around setting hard coded delay times?


            To get a socket connection is up to now no  problem as long as the GPRS activation was successful.


            In your opinion what should be the maximum time between network registration and successful GPRS activation?


          3. There are other checks to be done after network registration as I shown. I don’t think after GPRS attach a fixed interval can be suggested, simply by experience, location, operator etc.

          4. Yes. After confirming with AT#SGACT? the context is really inactive try at intervals to activate, the answer will be either an IP or an error so the state should be defined.


  2. we have the same problems, with #SGACT=1,1 or #GPRS=1 commands.

    module often responds with "+CME ERROR: activation failed" when we are trying to open a GPRS context, sometimes there is IP address in response, but sometimes ERROR :/

    We’ve done some timeouts of 2 or 5 sec. (random values), checking +CGATT, +CREG and +CGREG of course and sending #SGACT in a loop and when ERROR occurs, module sends #SGACT=1,0, then wait a few seconds, send #SGACT=1,1 and… sometimes ERROR ocurrs once again (!), so this is not a 100% succesful solution, I think that there is something wrong in your modules software, other modules from your competitors doesn’t have a problem with this..

  3. I had (and still have) this with a few previous SW versions, e.g. for GL865 with .154 .156 .157 and now with the newest .158, nothing’s changed in this issue

    1. Hi Emil,


      I think you send us an email few weeks ago on the same topic.

      ID : 187544 – #GPRS=1 -> "activation failed"

      We sent some suggestion but never received an answer back.

      It would be useful to continue on the same ID, not opening different threads for the same issue.

      We will probably need a trace to investigate further. Please email us back on [Request ID: ##187544##], thanks.

  4. yes, but now when I saw the same issue on forum I decide to share my experiance in this case with other users. Ok Andrea, I sent you an e-mail

  5. just to update this thread after the test we performed with Emil.

    The issue he faced was related to consecutive PDP context activation and deactivation is a short period of time.

    Even if the AT#SGACT=1,0 returns the OK, the deactivation works in background and in case of slow reaction of the network it can take more time.

    In that specific case, the PDP activation request was sent when deactivation was not completed (module sent deactivation request twice before network answer).


    I recommend to verify the context status with AT#SGACT? in order to be sure that context has been deactivated, before requesting a new activation.