Is there any delay after the execution of an AT command?

Firmware
1

Hi there,

The uBlox documentation of the cellular module states:

The DTE should wait some time (the recommended value is at least 20 ms) after the reception of an AT command final result code or URC before issuing a new AT command to give the DCE the opportunity to transmit the buffered URCs. Otherwise the collision of the URCs with the subsequent AT command is still possible.

Is there any delay implemented into Cellular.command() or in any other place?

If not, where should I place this delay, at the end of the callback function that I specify in the Cellular.command() call or right after the Cellular.command() call?

The first option seems like a good one since it provides a way to write reusable code but my concern is that the cellular module won't consider a command as being finished until the callback function exits.

Any help would be greatly appreciated.

Thank you!

2

@BDub do you know if the Cellular.command() API includes the prescribed 20ms delay?

3

By default, Cellular.command() will prescribe a 10 second timeout value for any AT command you give it. Typically it will block until a result of some kind is returned, be it RESP_OK or RESP_ERROR, etc… So if you chain a bunch of these together in your app, it should be fine. Many AT commands can be aborted as well, so if you issue a new command during the processing of the first one it will typically respond with RESP_ABORTED. This will be seen if you don’t add the proper timeout to the first Cellular.command() and stick with the default of 10s. The AT command manual will give you recommended response times for various commands, and in some cases it won’t and you’ll need to empirically determine it.

The only other thing to worry about is when you use Multi-threaded mode, it’s possible for your app’s Cellular.command() calls and background system AT commands to run into each other. Fortunately there is a mutex on functions that may be called concurrently within the the modem parser that are designed to lock the process, making them thread-safe.

When we enable the low power mode on the Electron, it will build in a 20ms time to all AT commands for another reason… the modem will not be ready to receive the AT command for up to 20ms upon low power wake up.

1 Like
4

So if I want to add my own delay between commands I should do it after the Cellular.command() call and not inside the callback function, right?

5

Reference:
https://docs.particle.io/reference/firmware/electron/#command-

I would code things to check for responses before proceeding to the next command like this:

int sendMyATCommands() {
    int ret = RESP_OK;
    ret = Cellular.command(20000, "AT\r\n"); // wait up to 20 seconds
    if (ret != RESP_OK) return 1;
    ret = Cellular.command(30000, "AT\r\n"); // wait up to 30 seconds
    if (ret != RESP_OK) return 2;
    ret = Cellular.command(40000, "AT\r\n"); // wait up to 40 seconds
    if (ret == RESP_OK) return 0;
}

That way you can control how long you are waiting for a response, and deal with each response. In this case AT should reply OK immediately… so it’s not going to take 20, 30, 40 seconds… but some commands do. Instead of just returning an error, you could try again, or do other things as well depending on the response.