Go Down

Topic: XBee Arduino Library for API mode (Read 15460 times) previous topic - next topic



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.



It would be nice to have a setFrameData(pos, byte) to parallel the getFrameData(pos) call.


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]



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.


The sensor xbee is connected to only vcc, gnd and d0. There is no serial i/o connection (din/dout.) The d0 input is fed by a voltage divider to bring it down to a max of 1V.


Your sensor circuit is correct.  You can go up to 1.2V to get the full 10-bit range.  I found that if you go over 1.2V, all the inputs read 1024.  So looks like you have everything at this point, right?


Nov 13, 2009, 09:06 pm Last Edit: Nov 14, 2009, 01:12 am by maxmike Reason: 1
Yes, fantastic - I even solved my x-ctu problems (see under xbee issues thread).
Did you update your library so I can download new version? Then I'll have another go at it.

Forgot to mention - my problems were solved thanks to another posting of yours.

I'm getting a compiler error on Arduino v15 in the second statement:

RemoteAtCommandRequest remoteAtRequest = RemoteAtCommandRequest(remoteAddress, irCmd, irValue, sizeof(irValue));

error: expected constructor, destructor, or type conversion before '.' token

Tried casting but that didn't work either.



You just need to move remoteAtRequest.setApplyChanges(false); inside a function, like setup or loop.

I release version 0.2.1 with a bug fix for apply changes, but I found that the example still works with the bug.  This means you don't need apply changes to enable i/o on a remote.  Here's what I receive at the coordinator after running the exmaple:

03:43:59.504 PM
Received Response apiId=ZNET_IO_SAMPLE_RESPONSE (0x92),length=20,checksum=0xe6,error=false,packetBytes=0x7e 0x00 0x14 0x92 0x00 0x7d 0x33 0xa2 0x00 0x40 0x0a 0x3e 0x02 0xaa 0x74 0x01 0x01 0x04 0x00 0x01 0x04 0x00 0x02 0x1d 0xe6,remoteAddress64=0x00 0x13 0xa2 0x00 0x40 0x0a 0x3e 0x02,remoteAddress16=0xaa 0x74,option=PACKET_ACKNOWLEDGED,digitalChannelMask1=00000100,digitalChannelMask2=00000000,analogChannelMask=00000001,dioMsb=00000100,dioLsb=00000000,D10=high,analog0=541

Remember to issue the WR command if you want to save the config to memory; otherwise it will be lost when you power off the xbee.



Nov 15, 2009, 08:21 pm Last Edit: Nov 16, 2009, 01:50 am by maxmike Reason: 1
Hi Andrew,

Looks like my problem is that I'm using an Xbee as a Zigbee when it should be a Znet 2.5 - Digi is driving me nuts. I also didn't pay attention to something you mentioned earlier because I didn't know the difference between Zigbee and Znet. This explains the error return from your calls. I am trying to write this (coordinator) file now:

Code: [Select]

Note it's called Zigbee, but drop down in X-CTU calls it Znet 2.5. It just will not do the write - keeps coming back with an error for EE. Changing EE and E0 produces an error for BD, etc.
Probably time to talk to the X-CTU boys...



ZNet is Zigbee.  ZNet 2.5 is based on Embernet 2.5.  Digi also provides ZB Pro, based on embernet 3.x.

Release notes for znet: http://ftp1.digi.com/support/firmware/93009374_C.txt

Release notes for zb pro:

I can't seem to find any info on the version 1320 firmware.  The ZB Pro firmware is 2.x.6.4 but that is selected by choosing xb24-zb on the modem menu.

You're on the right track now by installing the 114x ZNet firmware.  What are you using to flash the firmware?  Have you tried a reset before the write?



Nov 16, 2009, 10:31 pm Last Edit: Nov 17, 2009, 12:49 am by maxmike Reason: 1
Hi Andrew,
I'm using a modified development board that I wire-wrapped; it has 3.3V ttl/RS232 level converter, led's and grounds, etc. Works well. I am keeping the wire-wrap between pins 9 and 10 on the Xbee on that board. I must say X-CTU presents a steep learning curve for a simple program, but...
NOW your libraries seem to work!!!!!!!! Got RemoteAtCommand.pde to work, anyway - proceeding with rest. I'll download your new version first. Thanks for doing that.

Yup, sampling works as well - good stuff!


ok, good to hear it's working for you


Hi Rappa/MaxMike,

I am also trying to setup two Xbee series 2 radio's for communication in API mode. I want to add more Xbee's later, but for now one coordinator and one router/end device is what I am shooting for. However, I am at the point where MaxMike was at reply 9:

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.

I tried resetting the board just before hitting write, but it remains hanging on the "setting AT parameters". It this a timing thing where I should release the reset at just the right moment?

I have the xbee on top of an libelium xbee shield, which in turn is on top of an unchipped arduino duemilanove, connected to a windows laptop by USB. It seems after all the resets, write's etc there is a firmware for coordinator in API mode, but it is not retaining the NI and PAN ID. Also, is it correct that you cannot set the channel yourself?

I must be missing something, but I don't what and it is driving me crazy :-)

Any thoughts, hints or tips?


My problem disappeared as soon as I toggled off the "always update firmware" when writing...

Go Up