Bug #790

XBee/Wireless Initialization

Added by John Sexton over 7 years ago. Updated over 6 years ago.

Start date:
Due date:
% Done:



XBee and Wireless Init functions seem to conflict. dragonfly_init() appears to call xbee_init() [found in serial.c in libdragonfly], while wl_init() appears to call xbee_lib_init() [found in xbee.c in libwireless]. The two functions appear to be arguing over what to assign a few registers.

We found that to get the XBees to work, xbee_init() needs to be called again after drangonfly_init(), but before wl_basic_init_default() [which basically just calls wl_init()].

We also are not confident that calls to wl_set_channel() are working correctly, or if the channel is getting re-initialized by calls to xbee_init()/xbee_lib_init().

Related issues

Blocks Colony - Enhancement #798: get all the library inti's and functions to behave Assigned 10/21/2009


#1 Updated by David Schultz over 7 years ago

xbee_init() turns on the transmitter and receiver on the xbee and resets the baud rate.
xbee_lib_init() cycles the xbee to API mode to communicate with the wireless library and enables the interrupt that gets data from the xbee. They are not arguing as far as I am aware of, since there's only one register overlap and they are just turning on different bits in the register. I don't think the order of these two calls matters, but they both need to be called before doing higher level wireless functions in wl_init or wl_basic_init_default(). I'm not sure what the problem is with dragonfly_init, but maybe reordering the call to the end of dragonfly_init would work.

The channel is not set by any of the init functions, but left at the default value of 0x0C. The set_channel() call looks right, though I haven't tested it.

#2 Updated by David Schultz about 7 years ago

  • Category set to Wireless

#3 Updated by Alex Zirbel over 6 years ago

  • Priority changed from High to Normal

Also available in: Atom PDF