RAK3172 RUI 4.0.6 AT_COMMAND_NOT_FOUND

WisBlock
1

RAK3172
RUI V4.0.6
AT_COMMAND_NOT_FOUND

This is coming almost all the time in RUI 4.0.6
There has been mentioned that a 10 ms delay should be inserted before issuing an AT Command. This always happen when you get a message from the RAK3172.
before the AT command.
This is obviously a bug. inserting a 10 ms delay is a work around
This issue did not exist in older versions of the RUI.
I noticed that each RAK3172 module is different, some modules don’t need 10 ms 4 ms is enough.
Please fix this bug, it’s annoying.

Thank you
Frank.

2

If you get this, then most likely there is still something in the TX buffer of your host MCU that is sent out together with your command.
I have seen as well that glitches on the TX at the host MCU are causing this message on the next AT command.

Waiting before sending the next command is a bad practice. You should always read the whole response from the RAK3172 before you send the next command.

Commands are either finished after the RAK3172 has sent it’s “OK” or an error message like “AT_PARAM_ERROR”.

3

Hello Bernd,

Your interpretation of this issue is not correct.
I’m telling you what I see on the oscilloscope.
I can see the message come from the RAK3172 +EVT:TXP2P DONE
Than a few milliseconds later the MCU sends AT+PRECV=65534
Then a few milliseconds later RAK3172 responds AT_COMMAND_NOT_FOUND.

This definitely a bug.

Thank you.
Frank

4

I don’t know what you see in your oscilloscope, but I can’t see your problem.

This is with manual AT commands sent from terminal to RAK3172:

image
image701×312 6.58 KB

And this is an ESP32 as host MCU sending AT commands to a RAK3172 over UART
Lines with >> are the commands sent to the RAK3172
Lines with <<` are the response from the RAK3172

image
image678×847 24.6 KB

Again, after sending AT commands to the device, do not rely on delays. Wait for the response, check the response, then send the next command.

5

Hi Bernd,

This has been reported here in the Forum.
It seems like the problem is not consistent, some modules have it, some don’t.
But it is areal.
You need to see the timing on the scope. If there is sufficient delay already in the firmware,
then most likely the problem won’t show up.

Thank you
Frank.

6

So let me retry

You are sending an AT command
You are waiting 10ms
Then you are sending the next AT command
Then you get AT_COMMAND_NOT_FOUND

Is that correct?

7

Hi Bernd,

If the 10ms is not added then I see the AT_COMMAND_NOT_FOUND
If it is added then its OK.

Cheers,
Frank.

8

Tried to explain in my second post here, but seem to fail.

image
image756×71 5.74 KB

Working AT command flow:

  • MCU sends an AT command ==> RAK3172 starts processing the command

  • RAK3172 DOES NOT ACCEPT NEW COMMANDS WHILE PROCESSING THE COMMAND

  • RAK3172 finished processing ==> Send response back to host MCU
  • MCU gets response and knows it can send the next command

Unless you use AT commands properly, you will get errors.

10ms delay “might” work most times, but it is not the correct way to communicate with the RAK3172.