Broken State on GE865-Quad

7 thoughts on “Broken State on GE865-Quad

  1. We have the module connected with one serial port, so we communicate with the module and get indications on the same port. We have configured it to send an echo of the command.

    So it can happen, when sending a command, the echo might be interrupted by a +CIEV or another indication. The echo can be interrupted multiple time by several indications, and thus is split over several lines, which makes it hard to detect the echo.

    Is there any way, to configure the module not to interrupt echo of commands with indications?

    As a specific case, while sending an AT+CMGS command and waiting for the echo and the ‘>’ character, we got several indications. The echo for the command never came, but read the ‘>’ character. So we tried to send the SMS anyway, but didn’t get any echo for this command. After this, the module was in some kind of broken state. After lot of empty reads, we started sending new commands to the module, and could read back the echo of the individual commands, but no answer was coming. Only a restart did help.

    For the time being, I have disabled most indications.

    What can be done? Thank you very much.

      1. I added some debug prints into our kernel module, and attached it as a file.

         

        Two problematic cases for now

         

        An
        AT+CMGR is written and is not echoed, but interrupted by several
        indications, and then the answer to the command is given. But no echo.

         

         An AT+CMGS fails, no ‘>’ is given and afterwards registration is lost.

        1. Looks like the module did reboot at some time, hence the need of PIN and registration. Is power source strong enough?

           

           

          Are you using flow control? Can you replicate these with manual commands in a terminal?

          1. Power source should be strong enough. It’s hard to replicate this manually because problems occur usually under load.

            Especially the CMGS and CMGR commands with lots of data seem prone to lose their echo. And always there are indications between writing the command and receiving the answer.

            I’ve not yet seen a case where the echo is lost, without getting an indication before the answer.

             

            Can there be other reasons for the modem to reboot besides low power?

             

             

            We have following settings in the modem:

             

            FIRMWARE              : 10.00.003

             

            DTE_SPEED             : AUTO
            DTE_FORMAT            : AUTO
            GSM_DATA_MODE         : Not Transparent
            AUTOBAUD              : +IPR0=YES
            COMMAND_ECHO          : E1=YES
            RESULT_MESSAGES       : Q0=YES
            VERBOSE_MESSAGES      : V1=YES
            EXTENDED_MESSAGES     : X1=YES
            LINE_SPEED            : F0=autodetect
            CONSTANT_DTE_SPEED    : YES
            FLOW_CONTROL_OPTIONS  : &K3=HW bidirect.
            ERROR_CORRECTION_MODE : RLP
            CTS_C106_OPTIONS      : &B2=OFF while disc.
            DSR_C107_OPTIONS      : &S3=PHONE ready->ON
            DTR_C108_OPTIONS      : &D0=ignored
            DCD_C109_OPTIONS      : &C1=follows carrier
            RI_C125_OPTIONS       : R1=OFF dur. off-hk
            C108/1_OPTIONS        : &D4=NO
            POWER_SAVING_ON_DTR   : +CFUN:1=NO
            DEFAULT_PROFILE       : &Y0=user profile 1

             

             

          2. Other things to check, commands issuing timing:

            – wait for full response?

             – 20 ms at least?

            – fix the baudrate

            The chain Command -> Response shall always be respected and a new command must not be
            issued before the module has terminated all the sending of its response result code (whatever it
            may be).
            This applies especially to applications that “sense” the OK text and therefore may send the next
            command before the complete code <CR><LF>OK<CR><LF> is sent by the module.
            It is advisable anyway to wait for at least 20ms between the end of the reception of the response
            and the issue of the next AT command.
            If the response codes are disabled and therefore the module does not report any response to the
            command, then at least the 20ms pause time shall be respected.
            During command mode, due to hardware limitations, under severe CPU load the serial port can
            loose some characters if placed in autobauding at high speeds. Therefore if you encounter this
            problem fix the baud rate with +IPR command.

             

          3. We always wait for full response, and had at least 20 ms after response before sending the next command.

             

            We now fixed the baudrate to 9600, and things really improved, thank you very much. Compared to before, it now is a rare occurence. But it still happens that the echo is lost, or only partially transmitted (see first attached example). Most time it happens when indications are involved, but not always (see second example).