Some AT commands over BLE do not work

brolly759 · October 12, 2020, 1:54am

When running “at+get_config=lora:status” and “at+get_config=lora:channel” there is no return value in the notify over BLE.

Is it because of the amount of data that needs to be returned is too large? If so the AT commands / API needs to be broken out into individual components. 1 for set, 1 for get.

Nicholas · October 12, 2020, 2:14am

Dear Steve，

Which firmware are you using?

Best regards！

brolly759 · October 12, 2020, 2:16am

RAK4600 Version:3.4.0.14.beta2

brolly759 · October 12, 2020, 2:17am

I also tested RAK4600 Version:3.4.0.14 and same issue

Nicholas · October 12, 2020, 2:30am

Dear Steve，

Have you ever tried using serial port to send data?

Best regards！

brolly759 · October 12, 2020, 2:45am

Yes.
When I send the command over BLE, the response prints out over serial, not BLE.
If I send the command over serial, it prints over serial.

Using ONLY serial port for the LoRA specific data is not a good solution if you are trying to build a mobile app to configure a device.

Nicholas · October 12, 2020, 4:19am

Dear Steve，

Since the data sent is too long to be printed from BLE, you can try sending at+version！

Best regards!

brolly759 · October 12, 2020, 4:24am

Your responses… are VERY scary, are you the only one in support or bug fixes?

I already said that I think the response is too long for BLE as the most likely cause and that you should create AT commands for GET on each variable. For example, “at+set_config=lora:region:EU868” AND “at+get_config=lora:region” rather than 1 AT command to get everything possible

Nicholas · October 12, 2020, 4:29am

Dear Steve,

I don’t know why you’re so surprised！

But as you said, it’s much easier to get or set a command, and get a response that’s not printable because the response data is too long, rather than sending bytes out of range.

You can also implement this feature with RUI online compilation.

Best regards！

brolly759 · October 12, 2020, 4:34am

The online documentation discusses BLE AT commands as if its an alternative to serial commands and never mentions the limitations of what commands would NOT work over BLE. Also, I recommend the AT interface include a way to get individual parameters. Yes I could figure out a way to do it myself but that really should be a default function of the firmware.