************************************************************************** Firmware Revision History ************************************************************************** XBee/XBee-PRO ZNet 2.5 radio modems XBee-ZNet 2.5 Firmware Overview The XBee ZNet 2.5 firmware is based off the EmberZNet 2.5.x stack. XBee-ZNet 2.5 Firmware Versions XBee version numbers will have 4 significant digits. A version number is reported by issuing an ATVR command. The response returns 3 or 4 numbers. All numbers are hexadecimal and can have a range from 0-0xF. A version is reported as "ABCD". Digits ABC are the main release number and D is the revision number from the main release. "B" is a variant designator. The following variants exist in ZNet 2.5 firmware: Module Firmware * “0" - Coordinator, AT Command Mode (AP=0) * “1" - Coordinator, API Mode (AP=1,2) * “2" – Router / End Device AT Command Mode (AP=0) * “3" - Router / End Device API Mode (AP=1,2) Digi Adapter Firmware * “4" – Sensor Adapter * “5” – RS-232 Power Harvesting Adapter * “6” – Analog I/O Adapter * “7” – Digital I/O Adapter All public releases will have an even number for C. All internal development including beta releases will have an odd number for C. Field D is always present, even when D is 0. Released Versions Released ZNet 2.5 firmware versions are available from the X-CTU program for general download. To download released versions: 1. Go to the ‘Modem Configuration’ page in X-CTU. 2. Click on ‘Download New Versions’ and select ‘Web’. 3. You may need to disable your firewall in order to download new versions. ************************************************************************** Firmware Versions ************************************************************************** Version 1x47 Released August 7th, 2008 Based on EmberZNet 2.5.4 Bug Fixes (existed in 1x46) - IO line was set incorrectly on XBee-PRO module during module power up that could potentially cause inaccurate power compensation. Known Issues - See “Known Issues” section near the end of the document. Version 1x46 Released July 17th, 2008 Based on EmberZNet 2.5.4 Features - Improvements made to simplify and speed up serial drivers. - Added NC command to return the number of remaining end devices that can join a coordinator or router. Known Issues - See “Known Issues” section near the end of the document. Bug Fixes (existed in 1x41) - Certain combinations of IR and ST caused end devices to transmit IO samples continuously and not enter sleep mode after ST time. - DD value was not being reset correctly with ATRE. - XBee-PRO sleep current was high due to an incorrect internal IO setting (about 8mA) [requires hardware manufactured in June 2008 or later]. - Rare condition existed where remote commands could be sent to wrong 64-bit address causing end device announce on remote. - XBee Sensor distance sensor read bug fixed. Other Changes - Changed end device transmission timeout. In earlier versions, a device, when transmitting to an end device, would set the unicast timeout to (2.5 * SP) ms. However, this timeout was per network transmission. For a given transmission, there are 3 network retries. Thus, including the original transmission (before 3 retries) the maximum transmission timeout to a remote end device was (4 * 2.5 * SP). In 1x45, the 2.5 multiplier is removed, which changes the maximum transmission timeout to a remote end device to (4 * SP). This timeout reduction improves network efficiency when transmitting to end devices. Version 1142 Released April 16th, 2008 Based on EmberZNet 2.5.4 Bug Fixes (existed in 1141) - Sending multiple API transmission requests at a time caused API packet corruption Version 1x41 Released December 21st, 2007 Based on EmberZNet 2.5.4 Features - Commissioning push button functionality supported on module pin 20 (ATD0). Supports the following: o Single press (joined) – Device transmits broadcast node identification command. o Single press (unjoined) – Assoc LED blinks a numeric code * Number of blinks = (AI – 0x20). o Double press – Enables joining on the network for 1 minute. o Four press – Equivalent to ATRE + ATNR0. Command registers are reset to defaults, and the module leaves the network and attempts to join a new network. NOTE – a 4-button press does not issue an ATWR, so the restored defaults are not written to non-volatile memory. - IO sampling support and change detection. - Network layer 128-bit AES security support. Bug Fixes (existed in 1x2x) - End devices didn’t start polling their parent when coming up from a power cycle until an AT command was executed. - End devices running with SM=4 woke on Sleep_Req pin change - Sending serial data to a device when not joined could cause a transmission lockup until reset occurred. - Software reset could occur if ID or SC change occurred while the module was scanning to join a network. - RSSI PWM was not supported in API firmware. Version 1x21 Released August 6th, 2007 Based on EmberZNet 2.5.3 Bug Fixes (found in 1x20) - SM4 doesn’t wake on Sleep_RQ pin change Version 1x20 Released June 29th, 2007 Based on EmberZNet 2.5.3 Features - AT and API firmware versions - Coordinator and router/end device targets - Sleep modes - Explicit transmit and receive frames can expose endpoint and cluster ID addressing fields. - RTS and CTS flow control support. - Local analog and digital IO read capability. ************************************************************************** Known Issues ************************************************************************** The following are known issues in the ZNet hardware / software that may cause undesired behaviors. Digi recommends updating XBee ZNet 2.5 firmware to XBee ZB firmware (based on the EmberZNet 3.x.x stack) if any of these known issues may be problematic. ****** Channel Crosstalk ****** The EM250 suffers from a crosstalk issue where data received on a channel that is 12 channels above or below the current channel appears to be received on the current channel. RF data is detected on the erroneous channel only if the signal level of the received RF data is around - 30dBm (XBee devices separated by a few feet). For example, RF traffic on channel 0x0B could be seen on channels 0x0B and 0x17 if its detected signal level is around -30dBm. This could result in routers or end devices that join a PAN, but reporting an incorrect channel. The problem can be avoided by setting the SC (scan channels) bitmask to only include 12 continuous channels. If SC is left at its default value (0x1FFE), the crosstalk issue will never occur. ****** End Device Child Tables ****** When an end device joins a parent router or coordinator, the end device’s address is added to the child table of the parent. The child table supports a finite number of end devices (8). Once the child table is full on a router or coordinator, no more end devices can join that router or coordinator. End device entries in the child table do not time out. ZNet 2.5 Workaround: The NC command returns the number of remaining end devices that can join a router or coordinator. The NR0 command can be used to force the coordinator or router leave the current network, clear its child table, and attempt to form / join a new network. The NJ command determines when new devices can join a router or coordinator. Note: ZB firmware supports child table entry timeouts. If a parent router or coordinator has not heard from one of its children after a settable timeout, the child is removed from the end device table, allowing a new end device to join. Applications that require this functionality should upgrade to ZB firmware. ZNet 2.5 modules can be upgraded to ZB firmware using the X-CTU. Contact Digi support for details. ****** Neighbor Table Corruption ****** Coordinator devices can rarely exhibit corrupt data in their neighbor tables that makes the coordinator unresponsive in a network. When this corruption occurs, routers and end devices cannot send data to the coordinator. Applications should reset the coordinator (software or hardware) if data is not received for a prolonged period of time. ****** Mobile End Devices ****** Networks with mobile end devices (end devices that can move in and out of range of their parent) are not supported well in ZNet 2.5. These applications should upgrade to ZB firmware. ****** Power Up Transmissions ****** After power cycling a router, the router’s neighbor table is cleared and the router will not receive data from other devices in the network until it has first identified its neighbors. This process can take several seconds. Applications should avoid transmitting for several seconds after power cycling or resetting a device.