I have released a new version of my XBee Arduino Library. This release introduces support for the following packets: AT Command, Remote AT and I/O samples, for both series 1 and 2 radios. You can download it here GitHub - andrewrapp/xbee-arduino: Arduino library for communicating with XBee radios in API mode
Andrew
Andrew,
I am trying to use the Xbee-Arduino API library but there is trouble. The
coordinator is on an Arduino, the remote end-device is a simple board with just power, an idle sensor connector (for now) and the xbee.
The X-CTU program confirms I have a network - it lets me see the remote, and coordinator is flashing 2/sec, the end device 4/sec.
BUT, I cannot get any reply back using RemoteAtCommand test script.
Both chips are set with API firmware.
I am going to feed the hardware comm pins into the softserial pins and write some code to see what your lib is sending.
Is there some setting on the end device I might have forgotten?
Mike,
Can you tell me what type of XBees (series1/freescale or series2/ember) and what firmware you are using? You need at least 10c8 for series 1 to do remote at. If you can send me the code I can test it on my end.
Andrew
Hi Andrew,
That's the problem - I was using your scripts verbatim (RemoteAtCommand.pde) Well, not quite - I did change hardware address of end device target.
I'm using Series 2 coord is 1020, end device is 1032.
I tried something simple: connected serial tx to hyperterminal tx and rx to rx; got these two strings :
~}1}3¢@<?? þIR}3?r
and
~}3¢@<?? þD02
The first character is 0x7e in both cases, so I must be getting response from end device. Now I'll see if I can clean this up somehow.
Mike,
Version 1020 is ZNet coordinator AT (Transparent Mode) firmware. Since this is AT firmware, you can't be in API mode, and that would explain the problem. You need to load ZNet or ZB Pro API firmware, then set AP=2.
Andrew
Sorry, Andrew - I had an old version(s) # written down:
I'm using 1120 (C) and 1320(E)
As I said, I'm getting strings back, but I have to get rid of nss prints in
your code and clean up the strings so I can tell what they are. I will feed the serial rx/tx to nss rx/tx.
Mike,
Can you post your configuration for coord. and remote? You can use X-CTU -- hit the save button in the modem config tab and it will save as a text file
Andrew
Andrew,
I will do that asap. I think I found something of interest in the meantime; these are the strings you send to end device:
for IR command:
7E 7D 31 17 01 7D 33 A2 40 3C 88 88 20 FE 01 49 52 7D 33 88 72
(I changed sampling time to 5 sec.)
for A0 command:
7E 10 17 01 80 7D 33 A2 60 3C 88 88 20 FE 01 44 30 02 32
I think you will notice the byte counts are excessively large.
Also notice the address of the end device are different, they also seem incorrect (should be 0x0013a200, 0x403C8888.)
I'm going to try to verify these strings in case I did something wrong again.
The library must escape certain bytes. See the #2 item on my FAQ GitHub - andrewrapp/xbee-api: Java library for communicating with XBee radios Anytime you see a 7D, it's an escape sequence and you need to XOR 0x20 the next byte to get the original value.
Andrew,
I can see one problem - X-CTU did not write AP=2 as I thought it had.
I am having one hell of a time with it. I do a read, then show defaults, then set the value, then on write it fails during setting AT parameters,
then shows all errors. A subsequent restore sends it into a loop that requires it to be killed. I had to turn off the end device because it doesn't match new parameters and I get a complaint about network formation. Need to find a way of managing X-CTU.
Try holding the reset pin to GND, then release just before you hit the write button. Of course, on the "pc setting" tab you should not have the "use escape chars..." checkbox checked. After successful AP=2 write, check this checkbox.
Your help so far has been very valuable. Your last comment was right on and worked for the corrdinator. With the end device I have similar problems but I cannot seem to fix them this time. I hope I'm not imposing too much; here is its .pro file:
XB24-B_ZigBee_1320.mxi
80
0
251
1320
0
[A]ID=234
[A]SC=1FFE
[A]SD=3
[A]JN=1
[A]NJ=FF
[A]NI=
[A]DD=0
[A]AR=FF
[A]PL=4
[A]PM=1
[A]BD=3
[A]NB=0
[A]D7=1
[A]D6=0
[A]AP=2
[A]AO=0
[A]SM=2
[A]ST=1388
[A]SP=20
[A]SN=1
[A]D0=2
[A]D1=0
[A]D2=0
[A]D3=0
[A]D4=0
[A]D5=1
[A]P0=1
[A]P1=0
[A]P2=0
[A]RP=28
[A]PR=1FFF
Hm, it was failing during NVR write, so I installed a brand new chip and although there were some hiccups it finally did write correctly.
Now to try your very promising library.... and thanks for your help.
Two things Andrew :
does your Xbee serial port interfere with nss port somehow?
I get this now:
?Command returned error code: 2
Sending command to the \bee
Command [D0] was successful!
and the lines clear up if I remove your xbee comms.
I'm wondering if I get the error code 2 (invalid cmd) because
D0 should be sent prior to IR. I'll check this.
There should be no possibility of interference. Do you have the NSS serial device sharing a common ground with the Arduino and XBee? If not you will get spurious output.
There is a common ground on both boards. I have a question on the library's string for a RemoteAtCommandRequest; it issues this:
7E 00 7D 31 17 01 00 7D 33 A2 00 40 3C 88 88 20 FE 01 49 52 7D 33 88 72 (15)
The byte at position 15 is 01, but the manual says it should be 00 or 02.
Also, the two immediately preceding bytes should be FF and FE; they represent the 16-bit address of target which I assume is unknown.
Mike,
Yep, that's a bug. Thanks for finding it. For the time being you can call request.setApplyChanges(false). This will set the byte to 0 and will be legal. You can follow this with an AC (apply changes) command.
Andrew
Andrew,
It would be nice to have a setFrameData(pos, byte) to parallel the getFrameData(pos) call.
Mike
I can't get anything but FFFE for the 16-bit address (see below). Can you send me the code you are using to produce that?
As for setFrameData(pos, byte), it's not really possible since there is no backing array. getFrameData pulls from the object variables. You can simply call request.setXXX to change anything:
void setRemoteAddress16(uint16_t remoteAddress16);
void setRemoteAddress64(XBeeAddress64 &remoteAddress64);
void setApplyChanges(bool applyChanges);
You really shouldn't have to worry about what byte goes in what position -- that's what the library is for.
I plan to add a GenericRequest class that will allow you to have full control over the packet. This is intended for support any packet that the library doesn't support directly.
print(): byte is [0x7e]
print(): byte is [0x00]
print(): byte is [0x10]
print(): byte is [0x17]
print(): byte is [0x01]
print(): byte is [0x00]
print(): byte is [0x7d]
print(): byte is [0x33]
print(): byte is [0xa2]
print(): byte is [0x00]
print(): byte is [0x40]
print(): byte is [0x0a]
print(): byte is [0x3e]
print(): byte is [0x02]
print(): byte is [0xff]
print(): byte is [0xfe]
print(): byte is [0x02]
print(): byte is [0x44]
print(): byte is [0x30]
print(): byte is [0x02]
print(): byte is [0x33]
Hi,
Delay - had to deal with government(takes time.)
How did you print those hexes out?
I must have made some kind of error last time. When I display your command using getFrameData() I see FF FE as well, but things are not escaped (yet) - I guess that happens at send() time.
Anyway, I have no working end device - am trying to track down the needed connections for a sensor without serial i/o. Manual is ambiguous.
Might have fried sensor xbee?
I tossed the code in eclipse and put some debug in the send function.
What do you mean by connecting a sensor without serial i/o? Most XBee pins can support either digital input or analog input. With series 2 you can't measure more than 1.2V for some odd reason.