********************************************************************************
                            XBee Tips and Behavior
********************************************************************************

 * If a coordinator leaves a network, a router will not be able to reassociate
   to any network, even if the original coordinator forms a network with the
   same PAN ID.  A router node can be forced to reassociate by issuing a Network
   Reset 0 command (ATNR 0).

 * ZigBee coordinators currently allow only 8 devices to directly join.  The
   connections are permanent and in order to allow different nodes to
   join a network reset "NR 0" command must be issued at the coordinator.
   Router nodes are required in order to connect more than 8 nodes to a
   network.

 * The Rabbit is currently unable to wake up from sleep on IO input to the XBee
   module. Sleeps can only be terminated by received RF messages or a timeout.

 * The macros ZB_JOINING() and ZB_ND_RUNNING() call zb_tick() but do not
   present the return code to the application for processing.

 * A wake up message from End Device sleep will be received during
   xbee_init() but not immediately presented to the application.

 * Changing network and sleep mode parameters can cause a network reset. Network
   resets place the XBee module into an indeterminate state. While the Rabbit
   library attempts to detect this, the exact timing and duration is impossible
   to predict. Changing compiled-in library parameters may cause errors on the
   first run, following runs should be fine.

 * Sending too many broadcast messages will fill buffers on the XBee module,
   causing timeouts until it can finish processing and flush the buffers.

 * Each broadcast message is buffered and retransmitted for 4 seconds. There is
   finite buffer room, and larger broadcasts will cause the radio to run out of
   space sooner. A separate buffer tracks the last 8 broadcasts, storing each
   entry for 8 seconds.

 * Broadcast messages are received by all nodes on the network and transmitted
   to the Rabbit library. If they aren抰 properly addressed towards that node
   (endpoint/cluster) they will fall through to the general message handler or
   returned from zb_tick().

 * If profile checking is enabled, every node must have the endpoint definition
   of nodes it wants to communicate with. If a given node doesn抰 implement
   functionality of that endpoint it can leave cluster functions undefined, but
   the profile number must be included.

 * Network Discovery is performed once at program startup. For a coordinator
   this will often mean that no nodes will be detected as endpoints and routers
   have not had the chance to join. Once routers and endpoints have joined, the
   coordinator application can either initiate ND again using AT commands or
   restart to get new node information.

 * Certain radio values are programmed into the rabbit library as constants or
   read in during xbee_init(). NT and ST should not be modified by the
   application at runtime.

****************************
	Sleep mode on RCM4510W
****************************

 * Sleep mode is currently delayed at start time by at least 2 seconds of
   full power execution. Messages may arrive in this time and must be processed
   immediately or be lost. Any serial communication or RF activity during this 2
   second period will also reset the timer resulting in greater than 2 seconds
   till sleep.

 * When the Rabbit wakes up, full initialization and network discovery will be
   performed taking at least another 6 seconds. Short sleeps won抰 be efficient.

 * When an End Device wakes up from sleep mode the wake up message will begin
   processing inside of xbee_init(). Ensure that all data is initialized prior
   to xbee_init() for message processing.

*********************************************************************
	Changes to support ZNet 2.5 and ZB Pro firmware on XBee modules
*********************************************************************

The XBee_API.lib library in Dynamic C releases made before DC 10.44 worked with
ZNet 2.5 firmware on XBee Series 2 modules.  Although similar to ZigBee, the
ZNet 2.5 protocol is not ZigBee-compatible.  With the release of ZB firmware,
XBee Series 2 modules are ZigBee 2007 (aka ZigBee Pro) compliant.

You will need to make the following changes to your program to support various
changes made to XBee_API.lib to support this new firmware variant.

 * zigbee_init() was renamed to a more generic xbee_init().  The old name will
	still work, but you should switch to using the new name.

 * Various directories called "ZigBee" were renamed to "XBee":
 		Samples/ZigBee -> Samples/XBee
		Samples/RCM4500W/ZigBee -> Samples/RCM4500W/XBee

 * SleepMode.c and SleepMode2.c were moved from Samples/ZigBee to
 	Samples/RCM4500W/XBee.

 * ModemFWLoad.c was moved from Samples/RCM4500W to Samples/XBee.

 * API_Test.c was moved from Samples/RCM4500W to Samples/RCM4500W/XBee.

 * Libraries used for firmware updates were moved from
 	Lib/Rabbit4000/RCM4xxx/RCM45xxW_XBee_firmware to
 	Lib/Rabbit4000/XBee/XBee_Firmware.

 * Functions registered to clusters in the endpoint table are now passed the
   length of the RF payload as the second parameter.  Updating your functions
   to take advantage of this information is optional; they will continue to
   work with a single parameter in their declaration.

 * Instead of defining ZIGBEE_COORDINATOR, ZIGBEE_ROUTER or ZIGBEE_ENDDEV to
	select the role of your device on the network, your program should define
	XBEE_ROLE to one of NODE_TYPE_COORD, NODE_TYPE_ROUTER or NODE_TYPE_ENDDEV.

 * Your program can make use of the compile-time macros XBEE_IS_COORD,
	XBEE_IS_ROUTER, and XBEE_IS_ENDDEV to conditionally compile code based on
	the XBee module's role.

 * Your program can make use of the run-time macros XBEE_IS_ZNET and
	XBEE_IS_ZBPRO to behave differently based on what firmware is installed
	on the XBee module.  Since this information is only available at run-time,
	you cannot use the macros with the C preprocessor (i.e., in #if statements).

 * The RF Data payload for ZNet 2.5 is 72 bytes, and for ZB Pro is 80 bytes.
	To design a program to properly work with both types of firmware, use the
	compile-time macro XBEE_MAX_RFPAYLOAD (currently set to 80) to allocate
	buffers and the run-time macro XBEE_RFPAYLOAD_SIZE (set to 72 or 80 based
	on the XBee module's firmware) for limiting assembled packet size.

	Note that the 2x21 ZB firmware has a known bug that limits its RF payload
	to 72 bytes.  The XBee_API.lib library has been updated to work around that
	bug.

 * The macro ZB_COMPAT_FWVER was replaced with XBEE_MIN_VER_ZNET, and
 	XBEE_MIN_VER_ZBPRO.  Each macro represents the lower byte of an XBee
 	firmware version number.

	MIN_VER is the minimum version required to work correctly with XBee_API.lib.
	If you use a newer version than MIN_VER, and the macro XBEE_VERBOSE is
	defined, you'll get a warning on stdout that you're using an untested XBee
	firmware version.

	VER_ZNET is for ZNet 2.5 firmware and VER_ZBPRO is for ZB Pro firmware.

 * Dynamic C 10.46 corrected a long-standing bug where the
   zb_MakeEndpointClusterAddr function used the destination end point (instead
   of the source end point) when searching the end point table to set the
   profile ID.

   If you are upgrading and your application made use of profile IDs, make sure
   it is still sending frames with the expected ID.

***********************************************
	Known Problems with XBee firmware & X-CTU
***********************************************

Note: All problems listed below were resolved in the firmware and X-CTU
      versions shipped with Dynamic C 10.46 and later.

Versions: All ZB End Device firmwares before 2x40 release.
Problem: Changes to the SN register (number of sleep cycles before waking)
	only take effect on the NEXT sleep cycle.
Solution: Fixed in 2x40 release.

Versions: All End Device ZB firmware before 2934 release.
Problem: Firmware does not support ND (Node Discovery) and DN (Destination Node
	Lookup) commands.
Solution: Fixed in 2940 release.

Versions: All ZB Coordinator firmware before 2x40 release.
Problem: Performing an all-node network reset (ATNR1) can lock up the
	coordinator, requiring a reset.
Solution: Fixed in 2x40 release.

Versions: All ZB firmwares before 2x40 release, all non-end device ZB firmwares.
Problem: Firmware does not support IS (Input Sample), IR (I/O Sample Rate),
	and %V (Supply Voltage) commands.
Solution: Commands added back in 2940 release for end devices only.

Versions: All ZB End Device firmwares up to (and including) 2x21 release.
Problem: XBee should transmit frames with up to 80-byte RF payload, but only
	accepts a maximum of 72 bytes.  Able to receive packets with 80-byte payload.
Solution: xbee_api.lib uses hard-coded limit of 72 bytes for 2x21 XBee modules.
	Fixed in 2x40 release.

Versions: All ZB End Device firmware before 2x40 release.
Problem: End Device claims to be a router during node discovery.
Solution: Fixed in 2x40 release.

Versions: All ZB firmware before 2x40 release.
Problem: ZB_XMIT_STATUS() could return and invalid status, 0x66.
Solution: Fixed in 2x40 release.

Versions: X-CTU 5.1.0.0 (version shipped with Dynamic C 10.40 to 10.44)
Problem: Can't set 64-bit Extended PAN ID and can't read 64-bit Operating
	PAN ID.
Solution: Download X-CTU 5.2.0.0 or later, from
	<http://www.digi.com/support/productdetl.jsp?pid=3352&osvid=57&tp=4&s=316>