Can't start API mode, what am I doing wrong?


I don’t understand why API mode doesn’t work.

First of all, I’ve got this frame:

7E 00 10 17 01 00 00 00 00 00 00 FF FF FF FE 02 44 35 30 41


7E 00 10 17 01 00 00 00 00 00 00 FF FF FF FE 02 44 35 31 40

This just switch off and on the led nº 5 (I’ve done this in order to test the API mode, I think the frame is OK).

I’ve set the following firmware:

Modem XBEE: XBP24.
Function set: XBEE PRO 802.15.4.
Version: 10Cd.

And I’ve checked (in PC settings tab) on the “enable api” button. Well, I’ve tried to update the firmware with this button checked and also unchecked (and after updated, I’ve checked it again of course). That’s to say, I’ve tried both possibilities but at the end I always have the “enable API” button checked on.

In the modem configurating tab, I’ve configured Api enabled (1).

Sometimes, if I try the “read button” nothing appears. And other times, the read button doesn’t work properly (it fails).

So, if I’m not mistaken, xbee will discard everything it receives unless it receives 7E (start delimiter).

I can use “assemble packet” in the terminal tab to write my frame and send it. Theoretically, if everything is OK, it will work, but nothing happens (The log just says …D50A), the led is still switched off (or on, depending on how I’ve configured it before in the modem configuration). So, api mode is not working.

If I enter “+++” it returns OK and I think in Api mode it shouldn’t be this way.

Please, some help? Why can’t I use Api mode properly???

Thank you a lot !!!

Yours sincerely,

EDIT: I’ve sent a ticket to support, Whenever I receive reply I’ll post it here. I think it may be faster.

Message was edited by: Samy

Message was edited by: Samy

The only thing I can see off the bat, is that your API packet is incorrect. In the first packet you are trying to send, D50. You have then hex values of x44 x35 x30. You need to change the x30 (decimal 0) to x00. So, setting the D5 parameter to 0, should be sometihng like x44 x35 x00.

Then, to set D5 to 1, instead of x44 x35 x31, this should be x44 x35 x01.

Hope this helps.

It doesn’t work :frowning:

I’ve tried this frame (changing what you told me):

7E 00 10 17 01 00 00 00 00 00 00 FF FF FF FE 02 44 35 00 71

But nothing happens. In the terminal tab I see something like “. . . . . . . . D50.q”.

I think the frame is OK… Can someone check it? Or the reason why it’s not working (if somebody has a clue)…

7E start delimiter
00 10 length
17 packet type
01 00 00 00 00 00 00
44 (D) in hex
35 (5) in hex
00 (0) in hex
71 checksum

Thank you a lot…!!



Thanks for your help.

Are you sure about that?

In command mode I can write

ATD5 0

And it works fine. I thought 0 and 1 were decimal. How do you know that? Because then, there may be a lot more commands like this…

I can test it tomorrow, I’ll try it. I hope it will work! But tell me where did you learn it so I won’t make the same mistake again :slight_smile:

Thank you a lot, I was really desperate !


If I understand the Documents correctly, then if the module is responding to a ‘+++’ with ‘OK’ the module is in AT command mode not API command mode.
Using the AT mode query the API mode register ‘AP’ and look up what the value means.

The 802.15.4 module can support both the AT command mode and the API on the module at the same time.

So, even if the module is placed in API mode (AP = 1 or 2), issuing the “+++” sequence to enter command mode will still be recognized by the radio.

When in API mode, all data payload sent to and received from the module will be in the API frame, but once the module recognizes the “+++” command mode sequence, standard AT commands can still be issued as long as the radio remains in command mode.

I didn’t know that. Thanks.

I tried this out on a couple of modules I had on my desk. Please see the attached document with my results.

Hello gworle!

I’ve checked it. I do the same but my led keeps alive. I’ve sent a ticket to the support as well. I think it may be something of the configuration…

BTW, in “pc settings”, “enable api” is on.

I attach 2 screenshot so that you can see it. I think we’ve done kind of the same.

Thanks a lot for your help,

Message was edited by: Samy

There are a couple of things that might be concerning here. The first and biggest concern, is that your packet, when sent, isn’t getting a response of any sort.

Are you using the same firmware version on both ends of the link? 10CD is the first firmware version which introduced the remote AT command. The remote device must have at least this version of firmware in order to support the remote AT command request.

Also, you mention that when you send the command, the LED doesn’t go off. The D5 line defaults as the Association Indication LED, which when enabled, will blink appoximately once per second. If you set the D5 paramter to 0, which is disabled, the IO line may be disabled, but there is still a pull up resistor on the line (given by the PR command). This pull up would keep the LED on solid anyway. You should probably be setting the remote command as either output low or output high (D5 = 4 or 5). This might get you where you need to go.

As the API packet is correct, and your screen schot appears correct. I can’t thikn of anything else off-hand that could be causing the problem.

Do you have more than one remote? If so, It might be possible that the device’s are all sending back their information at the same time and colliding. If this is just a simple point to point connection, try using the long 64 bit address of the remote radio, just to verify. It could at least be a temporary work around until we find the solution.

Thank you gworle!

Now it’s working!

Didn’t know why the firmware of my remote devide hadn’t been updated correctly! And later on when I realized of it, the problem was that I didn’t set the api mode correctly (because of my mouse… I switch from mode 1 to 0 without noticing it).

So, thank you for all your efforts, I’ve been able to find out where my problem was (firmware!).

Kind regards,