How to handle URC and command echo correctly?

20 thoughts on “How to handle URC and command echo correctly?

  1. Hi,

     

     I’m using IP Easy in Command Mode and have come to some troubles when URC of SRING interfere with next command echo.

     

    For example I receive SRING and issue AT#SRECV. The command echo is interfered:

     

    <CR><LF>SRING: 1<CR><LF> 

    AT

    <CR><LF>SRING: 1#SREC=1,1500<CR><CR><LF> 

     

     

    I respect the 20ms after each command, but this still happens. What is the best way to avoid this or to work around this issue?

     

    Module: GL865-QUAD

    FW: 10.00.146 

     

    best regards,

    Gregor Bader 

    1. Are you sure is the echo from the module and not the one possible put out by the terminal software? How do you communicate with the module?

      1. I’m absolutely sure.

        I use MCU to communicate with module.

         

        The data is directly taken from my receive buffer.

         

        best regards,

        Gregor Bader 

          1. My Intention for using command echo was, to be able to clearly separate URC’s from command output by sensing command echo and passing every line to the command handler until end of command.

            Without command echo I don’t know if command was correctly received by module and I don’t know when the command started execution.

             

            This is a problem when URC’s can’t be clearly separated from command outputs.

            e.g. "NO CARRIER" which can be a URC in IP Easy command mode but also a result code.

          2. You should assume the command was received and will be executed, and be prepared for a recovery procedure.

            The URC body should not be interleaved with other module output, do you observe this?

          3. You should assume the command was received and will be executed, and be prepared for a recovery procedure.

            What do you understand by a "recovery procedure" ? Without command echo you have to wait for the command timeout to occur to detect any failure, which can be several seconds.

             

            The URC body should not be interleaved with other module output, do you observe this?

            I observe what I have described in first post. How is "URC body" defined? Is it: <CR><LF>URC<CR><LF> ?? 

             

          4. Corect about the URC.

             

            Most commands return immediately and those that aren’t have the timings published, in any case you should not send anything until the answer is received or the timeout is passed. If it timeout occurs with still no other answer, for example an error, proceed with the recovery, checking if the module is still on and alive, it answers to the following commands, if not re-start it – but such incidents should be rare.

            If you find this let ‘s call it "lack of application responsiveness" inacceptable you should implement CMUX.

             

          5. So, when I’m correct that <CR><LF> is part of the URC body, and you say that the URC body should not be interleaved, then I have found a bug.

    1. Start a TCP connection in command mode (e.g. any Web Server you know).
    2. Start a download of a file (with a dummy HTTP request, so you have a lot of TCP receiving)
    3. Listen for SRING URC and send AT#SRECV=1,1500 to receive data

    So is it a bug or not?

      1. RX:

        <CR><LF>SRING: 1<CR><LF>

         

        TX:

        AT#SRECV=1,1500<CR>

         

        RX:

        AT<CR><LF>SRING: 1#SRECV=1,1500<CR><CR><LF>

         

        Do you need more? 

  2. Andrea already explained that buffering only occurs after more than an AT is received.

    For such fast data transfer the command mode might not be appropriate, even without this problem the buffers might fill; if you are really prepared to consume all that fast data use the online mode or command mode with srMode 2, appropriate sringLen and a larger sringTo.

     

    Also try using a fixed baud rate instead of auto bauding:

     

    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 are going in circles!

     

    I expect following output from module when you say, that the URC body should not be interrupted:

    AT<CR><LF>SRING: 1<CR><LF>#SRECV=1,1500<CR>

     It is absolutely clear to me, that command echo might be interrupted. But not URC!

    1. It depends of your applications needs. What I usually do is to use a loop looking for the specific terminators, which depend of ATV set, S3 and S4 registers, with a fail safe timeout exit based on the maximum commands timeout or shorter if I am prepared/need to perform a hard reset.

      1. Hi Cosmin!

        I tried to use this approach but in some cases the “termination character” repeat a lot of time for exemple in the command AT+CMGL=ALL when the modem has a lot of message in the buffer and I am using a ARM processor to control the modem and manager the TCPs connections using IP EASY and I have cases that there are 6 active connections in same time that can pass any type of data and I think that it can be ¬†confused with the termination character approach.

        Is not possible to use RTS and CTS pins(or others) to inform that there is data in the buffer of the modem waiting to be read and the termination of the transmission?

        Thank you very much for your answer!