************************************************************************** Firmware Revision History - XBee/XBee-PRO ZB Radio Modems ************************************************************************** ** XBee-ZB Firmware Overview ** The XBee ZB firmware is based off the EmberZNet 3.x.x ZigBee-PRO stack. XBee-ZNet 2.5 modules can be upgraded to support XBee-ZB functionality through a firmware upgrade. While the AT commands and API frames are nearly identical between ZNet 2.5 and ZB firmware, XBee-ZNet 2.5 and XBee-ZB are not over-the-air compatible. ** XBee-ZB 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 ZB firmware: • “0" - Coordinator, AT Command Mode (AP=0) • “1" - Coordinator, API Mode (AP=1,2) • “2" - Router AT Command Mode (AP=0) • “3" - Router API Mode (AP=1,2) • “8” – End Device, AT Command Mode (AP=0) • “9” – End Device, API Mode (AP=1,2) Digi has developed an assortment of sensor adapter products that use the ZB firmware. (See www.digi.com for details.) Adapter firmware versions include the following variants: • “4" - Router/End Device Sensor Adapter • “5" - End Device Power Harvester Adapter • “6" - Router/End Device Analog IO Adapter • “7" - Router/End Device Digital IO Adapter All releases will have an even number for C. All internal development will have an odd number for C. Field D is always present, even when D is 0. ** Released Versions ** Released ZigBee 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. ************************************************************************** * Version 2x64 Release Notes * ************************************************************************** Release Date: May 18th, 2009 ZigBee Stack: EmberZNet 3.3.1 ZigBee-PRO stack FEATURES - IO sampling supported on all targets (IS, IR, IC, etc). - DB command and RSSI PWM are updated when an APS acknowledgment is received. - Network watchdog feature allows routers to leave the network if they have no communication with the coordinator for a certain period of time. If a router does not receive an ACK or data from the coordinator within (3 * NW) time, the router will leave the network. The NW command (network watchdog timeout) is measured in minute units, up to 0x64FF (17.95 days). - Received Device Announce ZDO frames are sent out the UART of API devices as API explicit receive indicator frames (0x91) if AO=1. - API targets can send fragmented messages. - Router target can be set as an end device by setting SM > 0. Changing from router to end device, or vice-versa requires the device leave the network and join as the new device type. - New API frame (0xA3) indicates when a many-to-one route request is received. - Remote API commands return a failure status code in a remote command response frame if the remote command transmission fails (status = 0x04, REMOTE_COMMAND_TX_FAILED). - Minimum LT time changed from 200ms to 100ms (0x0A). - Adaptive polling enhancement in end device firmware improves data throughput. - Support for new API transmit options bits: - 0x20 enables APS encryption - 0x40 enables the extended (end device) transmission timeout NEW AT COMMANDS - NW: Router network watchdog timeout. Default=0 (disabled) - SB: Number of UART stop bits. Default=0 (one stop bit) BUG FIXES 1. Broadcast radius field was not getting set correctly in broadcast transmissions. 2. Changed many-to-one broadcast type to LOW_RAM Concentrator. This ensures concentrator will have a route to send the ACK back to remote devices. 3. Routers do not enable route discovery when sending data to a concentrator (a device with AR < 0xFF). 4. Route discovery is disabled on devices with AR < 0xFF (concentrator devices). These devices must use source routing to send data to remote devices. (Set AR to 0xFF (default) to enable route discovery.) 5. Devices no longer send an APS acknowledgment if they cannot send the data out the UART (i.e. in the case where RTS flow control causes the UART transmit buffer to fill). 6. DIO change detection events would only send samples of IO lines enabled in the IC bitmask. Now, DIO change events send samples of all enabled IO lines. 7. Sending a remote IS command could cause an occassional module reset. 8. Fixed rejoining bug (when NJ < 0xFF) where an end device could power cycle and leave the network if its parent could not be found. It would not be able to rejoin the network if joining was disabled. 9. DN command returned ERROR status even if a valid response was received. 10. DB command (RSSI) on XBee-PRO did not account for signal strength gain in LNA. It now reports the signal strength detected at the antenna. 11. NC command (number of children) could return invalid values due to stack bug. Fixed in this release. 12. Joining problem fixed where a trust center could not allow devices to join more than 1 hop away. 13. CTS would not de-assert properly at the end of RS-485 transmissions. 14. If CTS flow control is enabled, CTS now de-asserts when initializing the UART. 15. Fixed short window where an RTS interrupt could be missed, potentially causing RTS flow control bug. 16. XBee-PRO end device could leave network regularly in 2x41 if SN set >3. 17. Sending data rapidly to many remotes could cause corruption in the sender's address table, causing a data packet to be sent to the wrong 64-bit address. This caused the remote device to change its 16-bit address. The transmit status frame ID value could also be incorrect. KNOWN ISSUES 1. Sending a broadcast transmission that has too many payload bytes will not return a transmit status. 2. The offset field in the ZDO routing table discovery request does not work. Devices always return their first routing table entries, regardless of the routing table offset field in the request. This will be fixed in a later stack version. 3. If a coordinator performs several over-the-air firmware updates, it may stop sending MAC layer acknowledgments. The firmware update process will complete correctly, but may become slower. To work around this, the application should reset the coordinator (FR command or power cycle) when the over-the-air firmware updates are complete. 4. In networks where a device is sending or receiving many transmissions simultaneously, the device may experience a rare reset condition. Applications should limit the number of simultaneous transmissions to 1 to work around this issue. ************************************************************************** * Version 2x41 Release Notes * ************************************************************************** Release Date: September 2nd, 2008 ZigBee Stack: EmberZNet 3.2.0 ZigBee-PRO stack FEATURES - Added SI (sleep immediately) command to put cyclic sleep XBee to sleep immediately, instead of waiting for ST to expire. - Poll timeout implemented on parent router / coordinator. If an end device child does not poll within this timeout, it is removed from the child table. The timeout is (3 * SP * SN) tenths of a second (since SP is measured in tenths of a second). - API targets support source routing. Two new API frames created to support source routing: * 0x21 - Create Source Route * 0xA2 - Source Route Record Indicator - End devices support IO sampling, network discovery command (ATND). - End devices can receive broadcast messages on stack profile 0 (ATZS). BUG FIXES (fixed since last release) - API devices could only transmit up to 72 bytes. Can now transmit more (see NP command). - Broadcast transmissions were not received relialbly by end devices when operating on stack profile 0 (stack fix). - Fixed memory leak during over-the-air firmware updates. - Fixed API memory leak where corrupt API frames caused occasional buffer loss. - API end device, when disassociated from network, did not return correct frame ID in tx-status. - API end device issued tx-status messages with 16-bit address set to 0xFFFD instead of the real 16-bit address. - NR1 caused immediate router leaves. Now, routers that receive NR1 wait 6 seconds before leaving. - Changing SN did not change sleep time (SP*SN) immediately. - Fixed bug in NH (router unicast timeout). - Sending multiple API broadcasts with different APP ID values yielded tx-status messages with the same APP ID value (last APP ID). - API router with RTS enabled, de-asserted since powerup would not respond to network discovery. - Commissioning button 2-button press caused joining to be disabled after 1 minute, even on devices where NJ=0xFF. - Fixed bug where transmitting a large block of data to a remote resulted in data loss on the remote. - Loopback cluster ID (0x0012) only supported within Digi Profile ID (0xC105). ************************************************************************** * Version 2x21 Release Notes * ************************************************************************** Release Date: June 13th, 2008 ZigBee Stack: EmberZNet 3.1.1 FEATURES - Added the ID command to improve compatibility with other XBee variations. ATID can set / read the ZigBee extended PAN ID. This replaces the EI command in 2x20. KNOWN ISSUES - IO sampling not yet supported on end devices. - End devices cannot initiate a network discovery command (ATND). - End devices do not receive broadcast messages on stack profile 0 (ATZS). - Incompatible with 2x20 if EI is set (in 2x20) to a non-default value (EI > 0). BUG FIXES (fixed since last release) - The EI command (now ID) set the extended PAN ID in little endian byte order in 2x20. - Certain conditions would cause end devices and routers to stop attempting to join a network. - Sending multiple serial API transmit frames could cause frames to not be processed. - Fixed problems with ATNR0 command. * Issuing ATNR0 reset the entire network. * End devices did not support the NR1 command. - Improved sleep current on XBee-PRO modules. OTHER CHANGES (since last release) - KY now sets the link key on all devices. - Added the NK command to set the network key on the coordinator. - SC defaults to enable 12 channels (0x1FFE) instead of 14. - JN default set to 0 to help prevent excess broadcasting. ************************************************************************** * Version 2x20 Release Notes * ************************************************************************** Release Date: April 8th, 2008 ZigBee Stack: EmberZNet 3.1.1 FEATURES - Functionality similar to ZNet 2.5 firmware. - AT and API versions. - Remote configuration command support. - Over-the-air firmware updates supported. - Supports interoperability with other ZigBee products. * API Data transmissions allow flexibility in specifying endpoints, cluster ID, and profile ID values. * API receive frame (0x91) indicates endpoints, cluster ID, and profile ID of each received RF packet. * The stack profile is configurable (ZS command). * Many ZDO commands can be issued to devices on the network. ************************************************************************** Known Issues ************************************************************************** The following are known issues in the ZB hardware / software. ****** Simulated EEPROM Erases ****** The Ember ZigBee stack occasionally writes information to non-volatile memory. These writes may require performing a flash page erase which can block up to 20ms (worst case). The EM250 has a 4-byte FIFO to collect incoming serial data. However, if serial uart interrupts are disabled for 20ms, it is possible for incoming serial data to be dropped once the 4-byte FIFO filles. ZB firmware de-asserts CTS about 40 microseconds before an erase operation begins. The application should observe CTS flow control as quickly as possible to prevent data loss. Note that PCs often make use of a FIFO buffer where serial data can be buffered prior to transmission to the serial port. If FIFO buffers are used, PC applications will not be immediately responsive to CTS and may experience rare data loss.