Can't get OK response from XBee upon "+++"

Question

I have been trying to set up two XBees to communicate since the last three days. X-CTU seems to be the perfect option to do so, however, it is a real menace when it comes to discovering XBees on serial ports.

I was able to detect one XBee by luck just once and the other one never showed up. I have even replaced both my XBees. I am trying to figure out the alternative, i.e. using a serial console to perform the operation. I haven't been able to receive an OK response from the device upon issuing +++.

Since I haven't had a good experience using a PC to communicate with ESP8266 devices earlier, I tried to figure out a workaround by using the second Serial port of an Arduino to send such configuration messages and read the response by printing it out on the default serial console.

It also appears that configuration messages can differ depending on the mode of the device. If it's in API mode, the frame has to be generated in a specific format (I use the X-CTU frame generator for this purpose).

Why am I not able to receive a response from the XBee upon issuing a +++?

The devices are Series 1 XBees and the exact part number is XB24-AWI-001. Any help is highly appreciated.

Answer 1

Have you considered the XBee being in API mode? Maybe should you consider to reflash the device in AT mode to start playing with it.

To test if it's in API mode, you can refer to the guide, chapter 9 for the API mode structure:

• http://eewiki.net/download/attachments/24313921/XBee_ZB_User_Guide.pdf?version=1&modificationDate=1380318639117&api=v2

Basically, a datagram in API mode starts with ~, and it's built as follows:

[0x7E|length(2B)|Command(1B)|Payload(length-1B)|Checksum(1B)]

As 0x7E is ~ on the ASCII table, you should try typing a bogus datagram in a serial terminal session like:

~ <C-d> AAAA

N.B.: The <C-d> characters means Control-d under unix., which is the EOF character.

Obviously such a message isn't likely to work, and you will receive a reply asking you to send that datagram again. That's because the EOF character being ASCII code 4, it means that the length of the datagram will be 4 bytes. So then you send four bogus bytes, the checksum will be A, which is very likely to be right, and the receiver will assume the transmission has been corrupted. So the datagram will be asked again, meaning you will receive a datagram to do that query.

Though I can only advice you to consider running it only in API mode (more reliable and a better API, but you cannot play around with it and understand what's going on by tapping on the line with a logic analyzer… though giving enough time, you'll start to read API datagrams like it's English ☺).

I wrote a page with a few resources to check on how to reflash the XBees:

• https://github.com/hackable-devices/polluxnzcity/wiki/Flash-zigbee

and here's other advices from another totally unrelated project:

• https://github.com/andrewrapp/xbee-api#documentation

And I also wrote a lib (aimed at beaglebones but you can tweak it for your use) that handles API mode 2 with XBees:

• https://github.com/hackable-devices/polluxnzcity/blob/master/PolluxGateway/include/xbee/xbee_communicator.h
• https://github.com/guyzmo/polluxnzcity/blob/master/PolluxGateway/src/xbee/xbee_communicator.C

but I bet with a little google search you can find more widely used libraries than those ones, and even some aimed to be run on Arduinos (N.B.: that lib was originally written for Arduinos, and then adapted to run for Beaglebone, so reversing the operation shouldn't be hard).