Home/Support/Support Forum/Remote AT command responses: How do I tell if it worked?

Remote AT command responses: How do I tell if it worked?

0 votes
Hi everyone,

I have remote AT commands working just fine in XCTU, but when I call them on the Arduino, I sometimes get false confirmations on successful remote AT commands.

I know they're false because I'm controlling the D3 pin on my Xbee remotely, and I can monitor the voltage.

To control the D3 pin, I need to send the command until the remote Xbee wakes from its sleep cycle. Each time, I look for the response:

if (xbee.getResponse().getApiId() == REMOTE_AT_COMMAND_RESPONSE) {

Then, I look for either:

if (remoteAtResponse.getStatus() == 0){}

and/ or

if (remoteAtResponse.isOk() == true) {}

As I understand the documentation, either one of these conditions are supposed to indicate that the remote AT command was sent and successfully received. This may be where I am wrong, because both of them are prone to returning a false positive on the very first time I look for the response. I know this is in error, because again, I'm monitoring the D3 pin on the remote Xbee. In addition, it should be highly unlikely to catch the remote xbee awake on the first try, every try.

If I combine the above conditionals:

if (remoteAtResponse.getStatus() == 0 && remoteAtResponse.isOk() == true){}

I get somewhat improved results. But I still frequently see both conditions satisfied erroneously.
asked Nov 30, 2016 in XBee Programmable Development by D_MK New to the Community (2 points)

Please log in or register to answer this question.

1 Answer

0 votes
In order for us to assist you in this, I will need to see the actual API frame you are sending and receiving back. Can you please provide that data along with which XBee module and related firmware you are working with?
answered Nov 30, 2016 by mvut Veteran of the Digi Community (13,488 points)
The answer turned out to be that after xbee.readPacket();, I was not using

if (xbee.getResponse().isAvailable()) {... }

Apparently calling this before checking the ID consumes the frame and populates the various frame parameters.

In my opinion, the API library has far too many pieces. There should be fewer functions and more automation.