XBP9B-DMWTB012

XBee®-PRO 900HP/XSC RF Modules S3 and S3B User Guide Revision history—90002173 Revision Date Description U July 2018 Added the 0x00, 0x80 and 0x89 frames for the 900HP. V June 2019 Added FCC publication 996369 related information. W January 2020 Added IFETEL certifications. X July 2021 Added safety instructions. Y September 2021 Updated Mexican certifications. Trademarks and copyright Digi, Digi International, and the Digi logo are trademarks or registered trademarks in the United States and other countries worldwide. All other trademarks mentioned in this document are the property of their respective owners. © 2020 Digi International Inc. All rights reserved. Disclaimers Information in this document is subject to change without notice and does not represent a commitment on the part of Digi International. Digi provides this document “as is,” without warranty of any kind, expressed or implied, including, but not limited to, the implied warranties of fitness or merchantability for a particular purpose. Digi may make improvements and/or changes in this manual or in the product(s) and/or the program(s) described in this manual at any time. Warranty To view product warranty information, go to the following website: www.digi.com/howtobuy/terms Customer support Gather support information: Before contacting Digi technical support for help, gather the following information:    Product name and model    Product serial number (s)    Firmware version    Operating system/browser (if applicable)    Logs (from time of reported issue)    Trace (if possible)    Description of issue    Steps to reproduce XBee®-PRO 900HP/XSC RF Modules 2 Contact Digi technical support: Digi offers multiple technical support plans and service packages. Contact us at +1 952.912.3444 or visit us at www.digi.com/support. Feedback To provide feedback on this document, email your comments to techcomm@digi.com Include the document title and part number (XBee®-PRO 900HP/XSC RF Modules, 90002173 Y) in the subject line of your email. XBee®-PRO 900HP/XSC RF Modules 3 Contents About the XBee-PRO 900HP RF Module User guide structure Safety instructions XBee modules 14 15 15 Technical specifications Performance specifications Power requirements General specifications Networking specifications Regulatory conformity summary Serial communication specifications UART pin assignments SPI pin assignments GPIO specifications Secondary processor specifications 18 18 19 19 19 20 20 20 20 21 Hardware Mechanical drawings Pin signals Design notes Power supply design Board layout Antenna performance Recommended pin connections Module operation for the programmable variant Programmable XBee SDK 24 25 26 27 27 27 28 29 31 Configure the XBee-PRO 900HP RF Module Software libraries Configure the device using XCTU Over-the-air firmware updates Distribute the new application Verify the new application Install the application XBee Multi Programmer XBee®-PRO 900HP/XSC RF Modules 33 33 33 33 34 34 35 4 Operation Basic operational design Serial interface UART data flow Serial data Configuration considerations Select the serial port Force UART operation Select the SPI port Serial port selection Serial receive buffer Serial transmit buffer UART flow control CTS flow control RTS flow control 37 37 37 38 38 38 39 39 40 40 40 40 40 40 SPI operation SPI communications SPI implementation SPI signals Full duplex operation Low power operation SPI and API mode SPI parameters 43 43 44 45 45 46 46 Modes Serial modes Transparent operating mode API operating mode Comparing Transparent and API modes Modes of operation Idle mode Transmit mode Receive mode Command mode Sleep mode 48 48 48 48 49 49 50 50 50 52 Sleep modes About sleep modes Asynchronous modes Synchronous modes Normal mode Asynchronous pin sleep mode Asynchronous cyclic sleep mode Asynchronous cyclic sleep with pin wake up mode Synchronous sleep support mode Synchronous cyclic sleep mode The sleep timer Indirect messaging and polling XBee®-PRO 900HP/XSC RF Modules 54 54 54 54 55 55 55 55 56 56 56 5 Indirect messaging Polling Sleeping routers Sleep coordinator sleep modes in the DigiMesh network Synchronization messages Become a sleep coordinator Select sleep parameters Start a sleeping synchronous network Add a new node to an existing network Change sleep parameters Rejoin nodes that lose sync Diagnostics Query sleep cycle Sleep status Missed sync messages command Sleep status API messages 56 57 57 57 58 60 62 62 63 64 65 65 65 66 66 66 Networking methods The MAC and PHY layers 64-bit addresses Make a unicast transmission Make a broadcast transmission Delivery methods Point to Point / Point to Multipoint (P2MP) Repeater/directed broadcast DigiMesh networking 68 68 69 69 69 69 70 71 AT commands Special commands AC (Apply Changes) FR (Force Reset) RE (Restore Defaults) WR (Write) MAC/PHY commands AF (Available Frequencies) CM (Channel Mask) MF (Minimum Frequency Count) HP (Preamble ID) ID (Network ID) MT (Broadcast Multi-Transmits) PL (TX Power Level) RR (Unicast Mac Retries) ED (Energy Detect) Diagnostic commands BC (Bytes Transmitted) DB (Last Packet RSSI) ER (Received Error Count) GD (Good Packets Received) EA (MAC ACK Failure Count) TR (Transmission Failure Count) UA (MAC Unicast Transmission Count) %H (MAC Unicast One Hop Time) XBee®-PRO 900HP/XSC RF Modules 77 77 77 77 77 78 78 78 79 79 80 80 80 81 81 81 81 81 82 82 82 83 83 83 6 %8 (MAC Broadcast One Hop Time) Network commands CE (Node Messaging Options) BH (Broadcast Hops) NH (Network Hops) NN (Network Delay Slots) MR (Mesh Unicast Retries) RN (Delay Slots) Addressing commands SH (Serial Number High) SL (Serial Number Low) DH (Destination Address High) DL (Destination Address Low) TO (Transmit Options) NI (Node Identifier) NT (Node Discover Time) NO (Node Discovery Options) CI (Cluster ID) DE (Destination Endpoint) SE (Source Endpoint) Addressing discovery/configuration commands AG (Aggregator Support) DN (Discover Node) ND (Network Discover) FN (Find Neighbors) Security commands EE (Security Enable) KY (AES Encryption Key) Serial interfacing commands BD (Baud Rate) NB (Parity) SB (Stop Bits) RO (Packetization Timeout) FT (Flow Control Threshold) AP (API Mode) AO (API Options) I/O settings commands CB (Commissioning Pushbutton) D0 (DIO0/AD0) D1 (DIO1/AD1) D2 (DIO2/AD2) D3 (DIO3/AD3) D4 (DIO4) D5 (DIO5/ASSOCIATED_INDICATOR) D6 (DIO6/RTS) D7 (DIO7/CTS) D8 (DIO8/SLEEP_REQUEST) D9 (DIO9/ON_SLEEP) P0 (DIO10/RSSI/PWM0 Configuration) P1 (DIO11/PWM1 Configuration) P2 (DIO12 Configuration) P3 (DIO13/DOUT) P4 (DIO14/DIN) PD (Pull Up/Down Direction) PR (Pull-up/Down Resistor Enable) XBee®-PRO 900HP/XSC RF Modules 83 83 84 84 84 85 85 85 86 86 86 86 86 87 87 88 88 89 89 89 89 89 90 90 91 91 92 92 92 92 93 93 94 94 94 95 95 95 95 96 96 97 97 98 98 99 99 100 100 101 101 101 102 102 102 7 M0 (PWM0 Duty Cycle) M1 (PWM1 Duty Cycle) LT (Associate LED Blink Time) RP (RSSI PWM Timer) I/O sampling commands AV (Analog Voltage Reference) IC (DIO Change Detection) IF (Sleep Sample Rate) IR (I/O Sample Rate) IS (Force Sample) TP (Board Temperature) %V (Voltage Supply Monitoring) Sleep commands SM (Sleep Mode) SO (Sleep Options) SN (Number of Sleep Periods) SP (Sleep Period) ST (Wake Time) WH (Wake Host Delay) Diagnostic - sleep status/timing commands SS (Sleep Status) OS (Operating Sleep Time) OW (Operating Wake Time) MS (Missed Sync Messages) SQ (Missed Sleep Sync Count) Command mode options CC (Command Character) CN (Exit Command Mode) CT (Command Mode Timeout) GT (Guard Times) Firmware commands VL (Version Long) VR (Firmware Version) HV (Hardware Version) HS (Hardware Series) DD (Device Type Identifier) NP (Maximum Packet Payload Bytes) CK (Configuration CRC) 103 103 104 104 104 104 105 105 106 106 106 107 107 107 107 108 108 109 109 109 109 110 110 111 111 111 111 111 112 112 112 112 112 112 113 113 113 113 Operate in API mode API mode overview API frame format API operation (AP parameter = 1) API operation-with escaped characters (AP parameter = 2) Data bytes that need to be escaped: Length Frame data API serial exchanges AT commands Transmit and Receive RF data Remote AT commands Device Registration Calculate and verify checksums Example XBee®-PRO 900HP/XSC RF Modules 116 116 116 116 117 117 117 118 118 119 119 120 120 120 8 Frame descriptions 64-bit Transmit Request - 0x00 Description Format Examples Local AT Command Request - 0x08 Description Format Examples Queue Local AT Command Request - 0x09 Description Examples Transmit Request - 0x10 Description Transmit options bit field Examples Explicit Addressing Command Request - 0x11 Description 64-bit addressing Reserved endpoints Reserved cluster IDs Reserved profile IDs Transmit options bit field Examples Remote AT Command Request - 0x17 Description Format Examples 64-bit Receive Packet - 0x80 Description Format Examples Local AT Command Response - 0x88 Description Examples Transmit Status - 0x89 Description Delivery status codes Examples Modem Status - 0x8A Description Examples Extended Transmit Status - 0x8B Description Route Information - 0x8D Description Format Examples Aggregate Addressing Update - 0x8E Description Examples Receive Packet - 0x90 Description Examples XBee®-PRO 900HP/XSC RF Modules 123 123 123 124 124 124 125 125 127 127 127 129 129 130 130 132 132 132 132 132 132 133 134 136 136 136 137 139 139 139 140 141 141 141 143 143 144 144 145 145 146 147 147 149 149 149 150 151 151 151 153 153 154 9 Explicit Receive Indicator - 0x91 Description Examples I/O Sample Indicator - 0x92 Description Examples Node Identification Indicator - 0x95 Description Examples Remote AT Command Response- 0x97 Description Examples 155 155 156 157 157 158 160 160 161 163 163 164 Advanced application features Remote configuration commands Send a remote command Apply changes on remote devices Remote command responses Network commissioning and diagnostics Configure devices Network link establishment and maintenance Place devices Device discovery Link reliability Commissioning pushbutton and associate LED I/O line monitoring I/O samples Queried sampling Periodic I/O sampling Detect digital I/O changes 167 167 167 167 167 167 168 169 169 170 172 175 175 175 177 178 General Purpose Flash Memory General Purpose Flash Memory Access General Purpose Flash Memory General Purpose Flash Memory commands PLATFORM_INFO_REQUEST (0x00) PLATFORM_INFO (0x80) ERASE (0x01) ERASE_RESPONSE (0x81) WRITE (0x02) and ERASE_THEN_WRITE (0x03) WRITE _RESPONSE (0x82) and ERASE_THEN_WRITE_RESPONSE (0x83) READ (0x04) READ_RESPONSE (0x84) FIRMWARE_VERIFY (0x05) and FIRMWARE_VERIFY_AND_INSTALL(0x06) FIRMWARE_VERIFY_RESPONSE (0x85) FIRMWARE_VERIFY _AND_INSTALL_RESPONSE (0x86) Work with flash memory 180 180 181 181 181 182 182 183 184 184 185 185 186 186 187 XSC firmware XBee-PRO XSC RF Module overview XBee®-PRO 900HP/XSC RF Modules 189 10 Pin signals Electrical characteristics Timing specifications 189 190 191 XBee-PRO XSC specifications Performance specifications Power requirements Networking specifications General specifications Antenna options Regulatory conformity summary 195 195 196 196 196 197 XBee-PRO XSC RF Module operation Serial communications UART-interfaced data flow Serial data Flow control Data In (DIN) buffer and flow control Data Out (DO) buffer and flow control Operating modes Idle mode Transmit mode Receive mode Sleep mode Command mode 199 199 199 199 200 201 201 201 202 202 203 205 Configuration and commands Programming examples Connect the device to a PC Send binary commands Example Special commands FR (Force Reset) PL (TX Power Level) Command mode options AT (Guard Time After) BT (Guard Time Before) CC (Command Sequence Character) CD (DO3 Configuration) CN (Exit Command Mode) CT (Command Mode Timeout) E0 (Echo Off) E1 (Echo On) PC (Power-up to Transparent operating mode) Networking and security commands AM (Auto-set MY) MD (RF Mode) MY (Source Address) Network commands DT (Destination Address) XBee®-PRO 900HP/XSC RF Modules 210 210 210 210 211 211 211 211 212 212 212 213 213 214 214 214 215 215 215 216 216 217 217 11 HP (Preamble ID) HT (Time before Wake-up Initializer) ID (Network ID) MK (Address Mask) RN (Delay Slots) RR (Unicast Mac Retries) SY (Time Before Initialization) TT (Streaming Limit) Serial interfacing commands BD (Interface Data Rate) CS (DO2 Configuration) FL (Software Flow Control) FT (Flow Control Threshold) NB (Parity) PK (Maximum RF Packet Size) RB (Packetization Threshold) RO (Packetization Timeout) RT (DI2 Configuration) Diagnostic commands ER (Receive Count Error) GD (Receive Good Count) RE (Restore Defaults) RP (RSSI PWM Timer) RZ (DI Buffer Size) RS (RSSI) SH (Serial Number High) SL (Serial Number Low) TR (Transmission Failure Count) VR (Firmware Version - Short) Sleep commands FH (Force Wakeup Initializer) HT (Time before Wake-up Initializer) LH (Wakeup Initializer Timer) PW (Pin Wakeup) SM (Sleep Mode) ST (Wake Time) 217 218 218 218 219 219 220 221 221 221 222 223 224 224 224 225 225 226 226 226 227 227 228 228 229 229 229 230 230 231 231 231 232 232 233 233 Network configurations Network topologies Point-to-point networks Point-to-multipoint networks Peer to peer networks Addressing Address recognition Basic communications Streaming mode (default) Repeater mode Acknowledged mode 236 236 236 237 238 239 239 239 240 244 S3B hardware certifications Agency certifications - United States United States (FCC) XBee®-PRO 900HP/XSC RF Modules 248 248 12 OEM labeling requirements XBee-PRO 900HP and XBee-PRO XSC FCC notices Limited modular approval Fixed base station and mobile applications Portable applications and SAR testing RF exposure statement FCC-approved antennas (900 MHz) Antennas approved for use with the XBee-PRO 900HP RF Module FCC publication 996369 related information ISED (Innovation, Science and Economic Development Canada) Labeling requirements Contains IC: 1846A-XB900HP Transmitters for detachable antennas Detachable antenna Brazil ANATEL Mexico IFETEL OEM labeling requirements IDA (Singapore) certification Labeling Frequency band Antenna gain 248 248 248 249 249 250 250 251 251 257 259 259 259 259 259 260 261 261 262 262 262 262 Legacy S3B hardware certifications Agency certifications - United States United States (FCC) OEM labeling requirements XBee PRO S3 XBee PRO S3B FCC notices Limited modular approval Fixed base station and mobile applications Portable applications and SAR testing RF exposure statement ISED (Innovation, Science and Economic Development Canada) Labeling requirements Contains IC: 1846A-XB900HP Contains IC: 1846A-XBEEXSC or Contains IC: 1846A-XBPS3B Antenna options: 900 MHz antenna listings Transmitters with detachable antennas Detachable antenna Brazil ANATEL XBee®-PRO 900HP/XSC RF Modules 264 264 264 264 264 265 265 266 266 266 267 267 267 267 268 273 274 275 13 About the XBee-PRO 900HP RF Module The XBee-PRO 900HP RF Modules consist of firmware loaded onto XBee-PRO S3B hardware. These embedded RF devices provide wireless connectivity to end-point devices in mesh networks. You can build networks up to 128 nodes using the XBee devices. For larger networks of up to 1,000 or more nodes, we offer RF optimization services to assist with proper network configuration. For more information network configuration, contact Digi Technical Support. Note The XBee-PRO 900HP RF Module is not backward compatible with the legacy XBee-PRO 900 (Part Number: XBP09-DP…) or XBee-PRO DigiMesh 900 (Part Number: XBP09-DM…) RF modules. The XBee-PRO S3B hardware consists of: n One Energy Micro EFM®32G230F128 microcontroller n One Analog Devices ADF7023 radio transceiver n One RF power amplifier n One NXP MC9S08QE32® microcontroller, only in the programmable version of the XBee User guide structure This user guide contains documentation for two RF protocols: XStream Compatible (XSC) and 900HP. The XSC firmware is provided for customers who need compatibility with existing networks that need to be 9XStream compatible. Customers who do not require this compatibility should not use the XSC firmware, but rather the newer 900HP firmware. The XSC firmware section at the back of this user guide contains documentation for the XSC firmware only. All other firmware documentation in the user guide is applicable to the 900HP firmware only. For more information about XSC firmware see the XSC firmware section. The XBee-PRO 900HP RF Module is not backward compatible with the legacy XBee-PRO 900 (Part Number: XBP09-DP…) or XBee-PRO DigiMesh 900 (Part Number: XBP09-DM…) RF Modules. The following table describes how to use this user guide based on the Digi part number for the module: XBee®-PRO 900HP/XSC RF Modules 14 About the XBee-PRO 900HP RF Module Digi Part Numbers FCC ID Safety instructions Hardware Platform Preinstalled Firmware Firmware Available Regulatory Information XBP09-XC… MCQXBEEXSC S31 XSC XSC Legacy S3B hardware certifications XBP9B-XC*T-001 (revision G and earlier) XBP9B-XC*T-002 (revision G and earlier) XBP9B-XC*T-021 (revision F and earlier) XBP9B-XC*T-022 (revision F and earlier) MCQXBPS3B S3B XSC XSC Legacy S3B hardware certifications XBP9B-XC*T-001 (revision H and later) XBP9B-XC*T-002 (revision H and later) XBP9B-XC*T-021 (revision G and later) XBP9B-XC*T-022 (revision G and later) all other part numbers beginning XBP9B-XC... MCQXB900HP S3B XSC XSC / 900HP XBP9B-D… MCQXB900HP S3B 900HP XSC / 900HP Safety instructions XBee modules n The XBee radio module cannot be guaranteed operation due to the radio link and so should not be used for interlocks in safety critical devices such as machines or automotive applications. n The XBee radio module have not been approved for use in (this list is not exhaustive): l medical devices l nuclear applications l explosive or flammable atmospheres n There are no user serviceable components inside the XBee radio module. Do not remove the shield or modify the XBee in any way. Modifications may exclude the module from any warranty and can cause the XBee radio to operate outside of regulatory compliance for a given country, leading to the possible illegal operation of the radio. n Use industry standard ESD protection when handling the XBee module. 1The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. XBee®-PRO 900HP/XSC RF Modules 15 About the XBee-PRO 900HP RF Module Safety instructions n Take care while handling to avoid electrical damage to the PCB and components. n Do not expose XBee radio modules to water or moisture. n Use this product with the antennas specified in the XBee module user guides. n The end user must be told how to remove power from the XBee radio module or to locate the antennas 20 cm from humans or animals. XBee®-PRO 900HP/XSC RF Modules 16 Technical specifications Performance specifications Power requirements General specifications Networking specifications Regulatory conformity summary Serial communication specifications GPIO specifications Secondary processor specifications XBee®-PRO 900HP/XSC RF Modules 18 18 19 19 19 20 20 21 17 Technical specifications Performance specifications Performance specifications This table describes the performance specifications for the devices. Note Range figure estimates are based on free-air terrain with limited sources of interference. Actual range will vary based on transmitting power, orientation of transmitter and receiver, height of transmitting antenna, height of receiving antenna, weather conditions, interference sources in the area, and terrain between receiver and transmitter, including indoor and outdoor structures such as walls, trees, buildings, hills, and mountains. Specification Value Ideal RF line-of-sight range 10 kb/s: up to 9 miles (15.5 km) 200 kb/s: up to 4 miles (6.5 km) (with 2.1 dB dipole antennas) Transmit power output 24 dBm (250 mW) (software selectable) RF data rate (high) 200 kb/s RF data rate (low) 10 kb/s Serial UART interface Complementary metal–oxide–semiconductor (CMOS) Serial universal asynchronous receiver/transmitter (UART), baud rate stability of 1. 7E 00 18 91 00 13 A2 00 41 AE B5 4E FF FE E8 E8 00 11 C1 05 C1 54 78 44 61 74 61 1C Frame type 64-bit source 0x91 0x0013A200 0x87BD 41AEB54E Unused Explicit output Source Reserved EP XBee®-PRO 900HP/XSC RF Modules Dest EP Cluster Profile Rx options 0xE8 0xE8 0x0011 0xC105 0xC1 0x54784461746 1  Digi data Digi data Data Digi profile ACK was sent in DigiMesh network "TxData" Received data 156 Frame descriptions I/O Sample Indicator - 0x92 I/O Sample Indicator - 0x92 Description This frame type is emitted when a device configured with standard API output—AO (API Options) = 0— receives an I/O sample frame from a remote device. Only devices running in API mode will send I/O samples out the serial port. Format The following table provides the contents of the frame. For details on frame structure, see API frame format. Frame Field Offset Size Description 0 8-bit Start Delimiter Indicates the start of an API frame. 1 16-bit Length Number of bytes between the length and checksum. 3 8-bit Frame type I/O Sample Indicator - 0x92 4 64-bit 64-bit source address The sender's 64-bit IEEE address. 12 16-bit Reserved Unused, but typically 0XFFFE. 14 8-bit Receive options Bit field of options that apply to the received message: n Bit 0: Packet was Acknowledged [0x01] n Bit 1: Packet was sent as a broadcast [0x02] Note Option values may be combined. 15 8-bit Number of samples The number of sample sets included in the payload. This field typically reports 1 sample. 16 16-bit Digital sample mask Bit field that indicates which I/O lines on the remote are configured as digital inputs or outputs, if any: bit 0: DIO0 bit 1: DIO1 bit 2: DIO2 bit 3: DIO3 bit 4: DIO4 bit 5: DIO5 bit 6: DIO6 bit 7: DIO7 bit 8: DIO8 bit 9: DIO9 bit 10: DIO10 XBee®-PRO 900HP/XSC RF Modules 157 Frame descriptions Offset I/O Sample Indicator - 0x92 Size Frame Field Description bit 11: DIO11 bit 12: DIO12 bit 13: DIO13 bit 14: DIO14 bit 15: N/A For example, a digital channel mask of 0x002F means DIO 0, 1, 2, 3, and 5 are enabled as digital I/O. 18 8-bit Analog sample mask Bit field that indicates which I/O lines on the remote are configured as analog input, if any: bit 0: AD0 bit 1: AD1 bit 2: AD2 bit 3: AD3 bit 7: Supply Voltage (enabled with V+ command) 19 16-bit Digital samples (if included) If the sample set includes any digital I/O lines (Digital channel mask > 0), this field contain samples for all enabled digital I/O lines. If no digital lines are configured as inputs or outputs, this field will be omitted. DIO lines that do not have sampling enabled return 0. Bits in this field are arranged the same as they are in the Digital channel mask field. 22 16-bit variable Analog samples (if included) If the sample set includes any analog I/O lines (Analog channel mask > 0), each enabled analog input returns a 16-bit value indicating the ADC measurement of that input. Analog samples are ordered sequentially from AD0 to AD3. EOF 8-bit Checksum 0xFF minus the 8-bit sum of bytes from offset 3 to this byte (between length and checksum). Examples Each example is written without escapes (AP = 1) and all bytes are represented in hex format. For brevity, the start delimiter, length, and checksum fields have been excluded. I/O sample A device with the 64-bit address of 0013A20012345678 is configured to periodically send I/O sample data to a particular device. The device is configured with DIO3, DIO4, and DIO5 configured as digital I/O, and AD1 and AD2 configured as an analog input. The destination will emit the following frame: 7E 00 16 92 00 13 A2 00 12 34 56 78 FF FE C1 01 00 38 06 00 28 02 25 00 F8 E8 XBee®-PRO 900HP/XSC RF Modules 158 Frame descriptions I/O Sample Indicator - 0x92 Frame type 64-bit source 0x92 0x0013A20 0x87AC 0 12345678 Sampl e Reserve d Unused XBee®-PRO 900HP/XSC RF Modules Rx option s Num sample s Digital Analog Digital channe channe sample l mask l mask s Analog Analog sampl sampl e1 e2 0xC1 0x01 0x0038 ACK was sent in mesh networ k b'00 Single sample 111000 (typical) DIO3, DIO4, and DIO5 enabled 0x06 0x0028 0x0225 0x00F8 b'0110 AD1 and AD2 enabled b'00 101000 DIO3 and DIO5 are HIGH; DI04 is LOW AD1 data AD2 data 159 Frame descriptions Node Identification Indicator - 0x95 Node Identification Indicator - 0x95 Description This frame type is emitted when a node identification broadcast is received. The node identification indicator contains information about the identifying device, such as address, identifier string (NI), and other relevant data. A node identifies itself to the network under these conditions: n The commissioning button is pressed once. n A CB 1 command is issued. n A synchronous sleep node stays awake for 30 seconds in order to receive a sync message. It also sends out an identifying message. See ND (Network Discover) for information on the payload formatting. See NO (Node Discovery Options) for configuration options that modify the output of this frame. Format The following table provides the contents of the frame. For details on frame structure, see API frame format. Offset Size Frame Field Description 0 8-bit Start Delimiter Indicates the start of an API frame. 1 16-bit Length Number of bytes between the length and checksum. 3 8-bit Frame type Node Identification Indicator - 0x95 4 64-bit 64-bit source address The sender's 64-bit address. 12 16-bit Reserved Unused, but this field is typically set to 0xFFFE. 14 8-bit Options Bit field of options that apply to the received message: XBee®-PRO 900HP/XSC RF Modules n Bit 0: Reserved n Bit 1: Packet was sent as a broadcast [0x02] n Bit 2: Reserved n Bit 4: Reserved n Bit 5: Reserved n Bit 6, 7: DigiMesh delivery method l b’00 = l b’01 = Point-multipoint [0x40] l b’10 = Directed Broadcast [0x80] l b’11 = DigiMesh [0xC0] 160 Frame descriptions Offset Node Identification Indicator - 0x95 Size Frame Field Description Note Option values may be combined. 15 16-bit Reserved Unused, but this field is typically set to 0xFFFE. 17 64-bit 64-bit remote address The 64-bit address of the device that sent the Node Identification. 25 variable (2-byte minimum) Node identification string Node identification string on the remote device set by NI (Node Identifier). The identification string is terminated with a NULL byte (0x00). 27+NI 16-bit Reserved Unused, but this field is typically set to 0xFFFE. 29+NI 8-bit Network device type What type of network device the remote identifies as: 0 = Coordinator 1 = Router 2 = End Device 30+NI 8-bit Source event The event that caused the node identification broadcast to be sent. 0 = Reserved 1 = Frame sent by node identification pushbutton event—see D0 (DIO0/AD0). 31+NI 16-bit Digi Profile ID The Digi application Profile ID—0xC105. 33+NI 16-bit Digi Manufacturer ID The Digi Manufacturer ID—0x101E. 35+NI 32-bit Device type identifier (optional) The user-defined device type on the remote device set by DD (Device Type Identifier). Only included if the receiving device has the appropriate NO (Node Discovery Options) bit set. EOF-1 8-bit RSSI (optional) The RSSI of the last hop that relayed the message. Only included if the receiving device has the appropriate NO (Node Discovery Options) bit set. EOF 8-bit Checksum 0xFF minus the 8-bit sum of bytes from offset 3 to this byte—between length and checksum. Examples Each example is written without escapes (AP = 1) and all bytes are represented in hex format. For brevity, the start delimiter, length, and checksum fields have been excluded. Identify remote device A technician is replacing a DigiMesh device in the field and needs to have the its entry removed from a cloud server's database. The technician pushes the commissioning button on the old device once to send an identification broadcast. The server can use the broadcast to identify which device is being replaced and perform the necessary action. When the node identification broadcast is sent, every device that receives the message will flash the association LED and emit the following information frame: XBee®-PRO 900HP/XSC RF Modules 161 Frame descriptions Node Identification Indicator - 0x95 7E 00 27 95 00 13 A2 00 12 34 56 78 FF FE C2 FF FE 00 13 A2 00 12 34 56 78 4C 48 37 35 00 FF FE 01 01 C1 05 10 1E 00 14 00 08 0D Frame type 64-bit source 0x95 0x0013A 0xFFFE 0xC2 200 1234567 8 Identifica tion Reser ved Unuse d XBee®-PRO 900HP/XSC RF Modules Option 64-bit s remote DigiMe sh broadc ast NI String Reser ved Devi ce type 0x0013A 0x4C48373 0xFFFE 0x01 200 5 00 1234567 8 "LH75" + null Unuse d Rout er Eve nt Profi MFG  le ID ID 0x01 0xC1 05 Butt Digi on press 0x10 1E Digi 162 Frame descriptions Remote AT Command Response- 0x97 Remote AT Command Response- 0x97 Request frame: Remote AT Command Request - 0x17 Description This frame type is emitted in response to a Remote AT Command Request - 0x17. Some commands send back multiple response frames; for example, the ND command. Refer to individual AT command descriptions for details on API response behavior. This frame is only emitted if the Frame ID in the request is non-zero. Format The following table provides the contents of the frame. For details on frame structure, see API frame format. Offset Size Frame Field Description 0 8-bit Start Delimiter Indicates the start of an API frame. 1 16-bit Length Number of bytes between the length and checksum. 3 8-bit Frame type Remote AT Command Response - 0x97 4 8-bit Frame ID Identifies the data frame for the host to correlate with a prior request. 5 64-bit 64-bit source address The sender's 64-bit address. 13 16-bit Reserved Unused, but this field is typically set to 0xFFFE. 15 16-bit AT command The two ASCII characters that identify the AT Command. 17 8-bit Command status Status code for the host's request: 0x00 = OK 0x01 = ERROR 0x02 = Invalid command 0x03 = Invalid parameter 0x04 = Transmission failure 0x0C = Encryption error 18-n variable Parameter value (optional) If the host requested a command parameter change, this field will be omitted. If the host queried a command by omitting the parameter value in the request, this field will return the value currently set on the device. EOF 8-bit Checksum 0xFF minus the 8-bit sum of bytes from offset 3 to this byte (between length and checksum). XBee®-PRO 900HP/XSC RF Modules 163 Frame descriptions Remote AT Command Response- 0x97 Examples Each example is written without escapes (AP = 1) and all bytes are represented in hex format. For brevity, the start delimiter, length, and checksum fields have been excluded. Set remote command parameter Host set the NI string of a remote device to "Remote" using a Remote AT Command Request - 0x17. The corresponding 0x97 Remote AT Command Response with a matching Frame ID is emitted as a response: 7E 00 0F 97 27 00 13 A2 00 12 34 56 78 12 7E 4E 49 00 51 Frame type Frame ID 0x97 0x27 Response Matches request 64-bit source 0x0013A200 12345678 Reserved AT command Command Status Command data 0x127E 0x4E49 0x00 (omitted) Unused "NI" Success Parameter changes return no data Transmission failure Host queued the the PAN ID change of a remote device using a Remote AT Command Request - 0x17. Due to existing network congestion, the host will retry any failed attempts. The corresponding 0x97 Remote AT Command Response with a matching Frame ID is emitted as a response: 7E 00 0F 97 27 00 13 A2 00 12 34 56 78 FF FE 49 44 04 EA Frame type Frame ID 0x97 0x27 Response Matches request 64-bit source 0x0013A200 12345678 Reserved AT command Command Status Command data 0xFFFE 0x4944 0x04 (omitted) Unused "ID" Transmission failure Parameter changes return no data Query remote command parameter Query the temperature of a remote device—TP (Board Temperature). The corresponding 0x97 Remote AT Command Response with a matching Frame ID is emitted with the temperature value as a response: 7E 00 11 97 27 00 13 A2 00 12 34 56 78 FF FE 54 50 00 00 2F A8 XBee®-PRO 900HP/XSC RF Modules 164 Frame descriptions Remote AT Command Response- 0x97 Frame type Frame ID 0x97 0x27 Response Matches request XBee®-PRO 900HP/XSC RF Modules 64-bit source Reserved AT command Command Status Command data 0x0013A200 12345678 0x0013A200 12345678 0x4944 0x00 0x002F Unused "TP" Success +47 °C 165 Advanced application features Remote configuration commands Network commissioning and diagnostics I/O line monitoring XBee®-PRO 900HP/XSC RF Modules 167 167 175 166 Advanced application features Remote configuration commands Remote configuration commands A device in API mode has provisions to send configuration commands to remote devices using the Remote Command Request API frame. For more information, see Operate in API mode. You can use this API frame to send commands to a remote module to read or set command parameters. Send a remote command To send a remote command populate the Remote AT Command Request frame (0x17) with: 1. The 64-bit address and of the remote device. 2. The correct command options value. 3. The command and parameter data (optional). Apply changes on remote devices When you use remote commands to change command parameter settings on a remote device, parameter changes do not take effect until you apply the changes. For example, changing the BD parameter does not change the serial interface on the remote until the changes are applied. To apply changes, do one of the following: n Set the apply changes option bit in the API frame. n Issue an AC (Apply Changes) command to the remote device. n Issue a WR + FR command to the remote device to save changes and reset the device. Remote command responses If the remote device receives a remote command request transmission, and the API frame ID is nonzero, the remote sends a remote command response transmission back to the device that sent the remote command. When a remote command response transmission is received, a device sends a remote command response API frame out its serial port. The remote command response indicates the status of the command (success, or reason for failure), and in the case of a command query, it includes the register value. The device that sends a remote command will not receive a remote command response frame if either of the following conditions exist: n The destination device could not be reached. n The frame ID in the remote command request is set to 0. Network commissioning and diagnostics We call the process of discovering and configuring devices in a network for operation, "network commissioning." Devices include several device discovery and configuration features. In addition to configuring devices, you must develop a strategy to place devices to ensure reliable routes. To accommodate these requirements, modules include features to aid in placing devices, configuring devices, and network diagnostics. Configure devices You can configure XBee devices locally through serial commands (AT or API) or remotely through remote API commands. API devices can send configuration commands to set or read the configuration settings of any device in the network. XBee®-PRO 900HP/XSC RF Modules 167 Advanced application features Network commissioning and diagnostics Network link establishment and maintenance Build aggregate routes In many applications it is necessary for many or all of the nodes in the network to transmit data to a central aggregator node. In a new DigiMesh network the overhead of these nodes discovering routes to the aggregator node can be extensive and taxing on the network. To eliminate this overhead, use the AG command to automatically build routes to an aggregate node in a DigiMesh network. Send a unicast To send a unicast, devices configured for Transparent mode (AP = 0) must set their DH/DL registers to the MAC address of the node which they need to transmit to. In networks of Transparent mode devices which transmit to an aggregator node, it is necessary to set every device's DH/DL registers to the MAC address of the aggregator node. Use the AG command to set the DH/DL registers of all the nodes in a DigiMesh network to that of the aggregator node. Use the AG command Upon deploying a DigiMesh network, send the AG command on the desired aggregator node to cause all nodes in the network to build routes to the aggregator node. You can use the command to automatically update the DH/DL registers to match the MAC address of the aggregator node. The AG command requires a 64-bit parameter. The parameter indicates the current value of the DH/DL registers on a device which should be replaced by the 64-bit address of the node sending the AG broadcast. If it is not desirable to update the DH/DL of the device receiving the AG broadcast, you can use the invalid address of 0xFFFE. API enabled devices output an Aggregate Addressing Update 0x8E if they update their DH/DL address. All devices that receive an AG broadcast update their routing table information to build a route to the sending device, regardless of whether or not their DH/DL address is updated. This routing information will be used for future transmissions of DigiMesh unicasts. Example 1: To update the DH/DL registers of all modules in the network to be equal to the MAC address of an aggregator node with a MAC address of 0x0013a2004052c507 after network deployment the following technique could be employed: 1. Deploy all devices in the network with the default DH/DL of 0xFFFF. 2. Send an ATAGFFFF command on the aggregator node. Following the preceding sequence would result in all of the nodes in the network which received the AG broadcast to have a DH of 0x0013a200 and a DL of 0x4052c507. These nodes would have automatically built a route to the aggregator. Example 2: To cause all nodes in the network to build routes to an aggregator node with a MAC address of 0x0013a2004052c507 without affecting the DH/DL of any nodes in the network, send the AGFFFE command on the aggregator node. This sends an AG broadcast to all nodes in the network. All of the nodes will update their internal routing table information to contain a route to the aggregator node. None of the nodes update their DH/DL registers, because none of the registers are set to an address of 0xFFFE. Node replacement You can also use the AG command to update the routing table and DH/DL registers in the network after a device is replaced, and you can update the DH/DL registers of nodes in the network. XBee®-PRO 900HP/XSC RF Modules 168 Advanced application features Network commissioning and diagnostics n To update only the routing table information without affecting the DH/DL registers, use Example 2. n To update the DH/DL registers of the network, use the method in the following example. Example: Use the device with serial number 0x0013a2004052c507 as a network aggregator and replace it with a device with serial number 0x0013a200f5e4d3b2. Issue the AG0013a2004052c507 command on the new module. This causes all devices with a DH/DL register setting of 0x0013a2004052c507 to update their DH/DL register setting to the MAC address of the sending device (0x0013a200f5e4d3b2). Place devices For a network installation to be successful, installers must be able to determine where to place individual XBee devices to establish reliable links throughout the network. RSSI indicators It is possible to measure the received signal strength on a device using the DB command. DB returns the RSSI value (measured in -dBm) of the last received packet. However, this number can be misleading in DigiMesh networks. The DB value only indicates the received signal strength of the last hop. If a transmission spans multiple hops, the DB value provides no indication of the overall transmission path, or the quality of the worst link; it only indicates the quality of the last link. Determine the DB value in hardware using the RSSI/PWM device pin (pin 6). If you enable the RSSI PWM functionality (P0 command), when the device receives data, it sets the RSSI PWM to a value based on the RSSI of the received packet (this value only indicates the quality of the last hop). You could connect this pin to an LED to indicate if the link is stable or not. Device discovery Network discovery Use the network discovery command to discover all devices that have joined a network. Issuing the ND command sends a broadcast network discovery command throughout the network. All devices that receive the command send a response that includes: n Device addressing information n Node identifier string (see NI (Node Identifier)) n Other relevant information You can use this command for generating a list of all module addresses in a network. Neighbor polling Use the neighbor poll command to discover the modules which are immediate neighbors (within RF range) of a particular node. You can use this command to determining network topology and determining possible routes. The device sends the command using the FN command. You can initiate the FN command locally on a node using AT command mode or by using a local AT command request frame. You can also initiate the command remotely by sending the target node an FN command using a remote AT command request API frame. A node that executes an FN command sends a broadcast to all of its immediate neighbors. All devices that receive this broadcast send an RF packet to the node that initiated the FN command. In an instance where the device initiates the command remotely, it sends the responses directly to the node XBee®-PRO 900HP/XSC RF Modules 169 Advanced application features Network commissioning and diagnostics which sent the FN command to the target node. The device outputs the response packet on the initiating radio in the same format as a network discovery frame. Link reliability To install a successful mesh network, you must be able to determine where to place individual XBee devices to establish reliable links throughout the mesh network. Network link testing To determine the success rate of many transmissions, send unicast data through the network from one device to another to measure the performance of the mesh network. To simplify link testing, the modules support a loopback cluster ID (0x12) on the data endpoint (0xE8). The device transmits any data sent to this cluster ID on the data endpoint back to the sender as illustrated in the following figure: The configuration steps to send data to the loopback cluster ID depend on the AP setting. AT configuration (AP=0) To send data to the loopback cluster ID on the data endpoint of a remote device, set the CI command value to 0x12. Set the SE and DE commands set to 0xE8 (default value). Set the DH and DL commands to the address of the remote. After exiting command mode, the source device transmits any received serial characters to the remote device, and returned to the sender. API configuration (AP=1 or AP=2) Send an Explicit Addressing Command API frame (0x11) using 0x12 as the cluster ID and 0xE8 as the source and destination endpoint. The remote device echoes any data packets it receives to the sender. Link testing between adjacent devices To test the quality of a link between two adjacent nodes in a network, use the Test Link Request Cluster ID send a number of test packets between any two nodes in a network. Initiate a link test using an Explicit TX Request frame. Address the command frame to the Test Link Request Cluster ID (0x0014) on destination endpoint 0xE6 on the device to execute the test link. The Explicit TX Request frame contains a 12 byte payload with the following format: XBee®-PRO 900HP/XSC RF Modules 170 Advanced application features Number of bytes Network commissioning and diagnostics Field name Description 8 Destination address The address the device tests its link with. 2 Payload size The size of the test packet. Use the MP command to query the maximum payload size for this device. 2 Iterations The number of packets to send. Use a number between 1 and 4000. After completing the transmissions of the test link packets, the executing device sends the following data packet to the requesting device's Test Link Result Cluster (0x0094) on endpoint (0xE6). If the requesting device is operating in API mode, the device outputs the following information as an API Explicit RX Indicator Frame: Number of bytes Field name Description 8 Destination address The address where the device tested its link. 2 Payload size The size of the test packet sent to test the link. 2 Iterations The number of packets sent. 2 Success The number of packets successfully acknowledged. 2 Retries The total number of MAC retries to transfer all the packets. 1 Result 0x00 - command was successful. 0x03 - invalid parameter used. 1 RR The maximum number of MAC retries allowed. 1 maxRSSI The strongest RSSI reading observed during the test. 1 minRSSI The weakest RSSI reading observed during the test. 1 avgRSSI The average RSSI reading observed during the test. Example Suppose that the link between device A (SH/SL = 0x0013a20040521234) and device B (SH/SL=0x0013a2004052abcd) is being tested by transmitting 1,000 40 byte packets. Send the following API packet to the serial interface of the device outputting the results, device C. Note that device C can be the same device as device A or B (Whitespace delineates fields and bold text is the payload portion of the packet): 7E 0020 11 01 0013A20040521234 FFFE E6 E6 0014 C105 00 00 0013A2004052ABCD 0028 03E8 EB And the following is a possible packet returned: 7E 0027 91 0013A20040521234 FFFE E6 E6 0094 C105 00 0013A2004052ABCD 0028 03E8 03E7 0064 00 0A 50 53 52 9F (999 out of 1000 packets successful, 100 retries used, RR=10, maxRSSI= - 80 dBm, minRSSI= - 83 dBm, avgRSSI= - 82 dBm) If the result field is not equal to zero then an error occurred. Ignore the other fields in the packet. If the Success field is equal to zero then ignore the RSSI fields. XBee®-PRO 900HP/XSC RF Modules 171 Advanced application features Network commissioning and diagnostics Trace routing Determining the route a DigiMesh unicast takes to its destination is useful when setting up a network or diagnosing problems within a network. Use the Trace Route API option of Tx Request Packets to transmit routing information packets to the originator of a DigiMesh unicast by the intermediate nodes. For a description of the API frames, see API operating mode. If you enable the Trace Route API option, the device sends the unicast to its destination devices, which forward the unicast to its eventual destination. The destination devices transmit a Route Information—RI—packet back along the route to the unicast originator. When a unicast is sent with the Trace Route API option enabled, the unicast is sent to its destination radios which forward the unicast to its eventual destination and transmit a Route Information—RI— packet back along the route to the unicast originator. For more information, see API operating mode. The destination devices contain addressing information for the unicast and intermediate hop that generates the trace route packet, and other link quality information. Example: Suppose you unicast a data packet with the trace route enabled from radio A to radio E, through radios B, C, and D. The following sequence occurs: n After the successful MAC transmission of the data packet from A to B, A outputs an RI Packet indicating that the transmission of the data packet from A to E was successfully forwarded one hop from A to B. n After the successful MAC transmission of the data packet from B to C, B transmits a RI Packet to A. Then, A outputs this RI packet out its serial interface. n After the successful MAC transmission of the data packet from C to D, C transmits a RI Packet to A—through B. Then, A outputs this RI packet out its serial interface. n After the successful MAC transmission of the data packet from D to E, D transmits an RI Packet to A—through C and B. Then, A outputs this RI packet out its serial interface. Route Information packets are not guaranteed to arrive in the same order as the unicast packet took. It is also possible Route Information packets that are transferred on a weak route to fail before arriving at the unicast originator. Because of the large number of Route Information packets that can be generated by a unicast with Trace Route enabled, we suggest that the Trace Route option only be used for occasional diagnostic purposes and not for normal operations. NACK messages Transmit Request (0x10 and 0x11) frames contain a negative-acknowledge character (NACK) API option (Bit 2 of the Transmit Options field). If you use this option when transmitting data, when a MAC acknowledgment failure occurs on one of the hops to the destination device, the device generates a Route Information Packet (0x8D) frame and sends it to the originator of the unicast. This information is useful because it allows you to identify and repair marginal links. Commissioning pushbutton and associate LED XBee devices support a set of commissioning pushbutton and LED behaviors to aid in device deployment and commissioning. These include the commissioning push button definitions and associate LED behaviors. The following features can be supported in hardware: XBee®-PRO 900HP/XSC RF Modules 172 Advanced application features Network commissioning and diagnostics TH RF Module Connect a pushbutton and an LED to XBee-PRO 900HP RF Module pins 20 and 15 respectively to support the commissioning pushbutton and associate LED functionalities. SMT RF Module Commissioning pushbutton The commissioning pushbutton definitions provide a variety of simple functions to help with deploying devices in a network. Enable the commissioning button functionality by setting D0 (DIO0/AD0) to 1 (enabled by default). Button presses Sleep configuration and sync status 1 Not configured for sleep Immediately sends a Node Identification broadcast transmission. All devices that receive this transmission blink their Associate LED rapidly for 1 second. All API devices that receive this transmission send a Node Identification Indicator - 0x95 out their serial interface. 1 Configured for asynchronous sleep Wakes the module for 30 seconds. Immediately sends a Node Identification broadcast transmission. All devices that receive this transmission blink their Associate LED rapidly for 1 second. All API devices that receive this transmission send a Node Identification Indicator - 0x95 out their serial interface. 1 Configured for synchronous sleep Wakes the device for 30 seconds (or until the synchronized network goes to sleep). Queues a Node Identification XBee®-PRO 900HP/XSC RF Modules Action 173 Advanced application features Button presses Network commissioning and diagnostics Sleep configuration and sync status Action broadcast transmission sent at the beginning of the next network wake cycle. All devices receiving this transmission blink their Associate LEDs rapidly for 1 second. All API devices that receive this transmission send a Node Identification Indicator - 0x95 out their serial interface. 2 Not configured for synchronous sleep No effect. 2 Configured for synchronous sleep Causes a node configured with sleeping router nomination enabled (see SO (Sleep Options)) to immediately nominate itself as the network sleep coordinator. 4 Any Issues an RE (Restore Defaults)to restore device parameters to default values. Use CB (Commissioning Pushbutton) to simulate button presses in software. Issue a CB command with a parameter set to the number of button presses you want executed. For example, sending CB1 executes the actions associated with a single button press. The node identification frame is similar to the node discovery response frame; it contains the device’s address, node identifier string (NI command), and other relevant data. All API devices that receive the node identification frame send it out their serial interface as a Node Identification Indicator - 0x95. Associate LED The Associate pin (pin 15) provides an indication of the device's sleep status and diagnostic information. To take advantage of these indications, connect an LED to the Associate pin. To enable the Associate LED functionality, set the D5 command to 1; it is enabled by default. If enabled, the Associate pin is configured as an output. This section describes the behavior of the pin. The Associate pin indicates the synchronization status of a sleep compatible XBee-PRO 900HP RF Module. If a device is not sleep compatible, the pin functions as a power indicator. Use the LT command to override the blink rate of the Associate pin. If you set LT to 0, the device uses the default blink time: 500 ms for a sleep coordinator, 250 ms otherwise. The following table describes the Associate LED functionality. Sleep mode LED status Meaning 0 On, blinking The device has power and is operating properly 1, 4, 5 Off The device is in a low power mode 1, 4, 5 On, blinking The device has power, is awake and is operating properly 7 On, solid The network is asleep, or the device has not synchronized with the network, or has lost synchronization with the network 7, 8 On, slow blinking (500 ms blink time) The device is acting as the network sleep coordinator and is operating properly XBee®-PRO 900HP/XSC RF Modules 174 Advanced application features Sleep mode I/O line monitoring LED status Meaning 7, 8 On, fast blinking (250 ms blink time) The device is properly synchronized with the network 8 Off The device is in a low power mode 8 On, solid The device has not synchronized or has lost synchronization with the network Diagnostics support The Associate pin works with the Commissioning Pushbutton to provide additional diagnostic behaviors to aid in deploying and testing a network. If you press the Commissioning Pushbutton once, the device transmits a broadcast Node Identification Indicator (0x95) frame at the beginning of the next wake cycle if the device is sleep compatible, or immediately if the device is not sleep compatible. If you enable the Associate LED functionality using the D5 command, a device that receives this transmission blinks its Associate pin rapidly for one second. I/O line monitoring I/O samples XBee devices support both analog input and digital I/O line modes on several configurable pins. Queried sampling Devices support both analog input and digital I/O line modes on several configurable pins. The following table provides typical parameters for the pin configuration commands (D0 - D9, P0 P2). Pin command parameter Description 0 Unmonitored digital input 1 Reserved for pin-specific alternate functionality 2 Analog input (A/D pins) or PWM output (PWM pins) 3 Digital input, monitored 4 Digital output, low 5 Digital output, high 7 Alternate functionality, where applicable The following table provides the pin configurations when you set the configuration command for a particular pin. XBee®-PRO 900HP/XSC RF Modules 175 Advanced application features I/O line monitoring Device pin name Device pin number Configuration command CD / DIO12 4 P2 PWM0 / RSSI / DIO10 6 P0 PWM1 / DIO11 7 P1 DTR / SLEEP_RQ / DIO8 9 D8 AD4 / DIO4 11 D4 CTS/ DIO7 12 D7 ON/SLEEP/ DIO9 13 D9 ASSOC / AD5 / DIO5 15 D5 RTS / DIO6 16 D6 AD3 / DIO3 17 D3 AD2 / DIO2 18 D2 AD1 / DIO1 19 D1 AD0 / DIO0 / Commissioning Pushbutton 20 D0 Use the PR command to enable internal pull up/down resistors for each digital input. Use the PD command to determine the direction of the internal pull up/down resistor. If you issue the IS command using a a local or remote AT Command API frame, then the device returns an AT Command Response (0x88) frame with the I/O data included in the command data portion of the packet. Field Name Description 1 Sample sets Number of sample sets in the packet. Always set to 1. 2 Digital channel mask Indicates which digital I/O lines have sampling enabled. Each bit corresponds to one digital I/O line on the device. bit 0 = AD0/DIO0 bit 1 = AD1/DIO1 bit 2 = AD2/DIO2 bit 3 = AD3/DIO3 bit 4 = DIO4 bit 5 = ASSOC/DIO5 bit 6 = RTS/DIO6 bit 7 = CTS/GPIO7 bit 8 = DTR / SLEEP_RQ / DIO8 bit 9 = ON_SLEEP / DIO9 bit 10 = RSSI/DIO10 bit 11 = PWM/DIO11 bit 12 = CD/DIO12 For example, a digital channel mask of 0x002F means DIO0,1,2,3, and 5 are XBee®-PRO 900HP/XSC RF Modules 176 Advanced application features Field Name I/O line monitoring Description enabled as digital I/O. 1 Variable Analog channel mask Indicates which lines have analog inputs enabled for sampling. Each bit in the analog channel mask corresponds to one analog input channel. Sampled data set If you enable any digital I/O lines, the first two bytes of the data set indicate the state of all enabled digital I/O. Only digital channels that you enable in the Digital channel mask bytes have any meaning in the sample set. If do not enable any digital I/O on the device, it omits these two bytes. Following the digital I/O data (if there is any), each enabled analog channel returns two bytes. The data starts with AIN0 and continues sequentially for each enabled analog input channel up to AIN5. bit 0 = AD0/DIO0 bit 1 = AD1/DIO1 bit 2 = AD2/DIO2 bit 3 = AD3/DIO3 bit 4 = AD4/DIO4 bit 5 = ASSOC/AD5/DIO5 Example Sample AT response 0x01 [1 sample set] 0x0C0C [Digital Inputs: DIO 2, 3, 10, 11 enabled] 0x03 [Analog Inputs: A/D 0, 1 enabled] 0x0408 [Digital input states: DIO 3, 10 high, DIO 2, 11 low] 0x03D0 [Analog input: ADIO 0 = 0x3D0] 0x0124 [Analog input: ADIO 1 =0x120] Periodic I/O sampling Periodic sampling allows a device to take an I/O sample and transmit it to a remote device at a periodic rate. Use the IR command to set the periodic sample rate. n To disable periodic sampling, set IR to 0. n For all other IR values, the firmware samples data when IR milliseconds elapse and the sample data transmits to a remote device. The DH and DL commands determine the destination address of the I/O samples. Only devices with API operating mode enabled send I/O data samples out their serial interface. Devices that are in Transparent mode (AP = 0) discard the I/O data samples they receive. You must configure at least one pin as a digital or ADC input to generate sample data. A device with sleep enabled transmits periodic I/O samples at the IR rate until the ST time expires and the device can resume sleeping. For more information about setting sleep modes, see Sleep modes. XBee®-PRO 900HP/XSC RF Modules 177 Advanced application features I/O line monitoring Detect digital I/O changes You can configure devices to transmit a data sample immediately whenever a monitored digital I/O pin changes state. The IC command is a bitmask that you use to set which digital I/O lines to monitor for a state change. If you set one or more bits in IC, the device transmits an I/O sample as soon it observes a state change in one of the monitored digital I/O lines using edge detection. The figure below shows how I/O change detection can work with periodic sampling. XBee®-PRO 900HP/XSC RF Modules 178 General Purpose Flash Memory General Purpose Flash Memory Access General Purpose Flash Memory General Purpose Flash Memory commands Work with flash memory XBee®-PRO 900HP/XSC RF Modules 180 180 181 187 179 General Purpose Flash Memory General Purpose Flash Memory General Purpose Flash Memory XBee-PRO 900HP RF Modules provides 119 512-byte blocks of flash memory that an application can read and write to. This memory provides a non-volatile data storage area that an application uses for many purposes. Some common uses of this data storage include: n Storing logged sensor data n Buffering firmware update data for a host microcontroller n Storing and retrieving data tables needed for calculations performed by a host microcontroller The General Purpose Memory (GPM) is also used to store a firmware update file for over-the-air firmware updates of the device itself. Access General Purpose Flash Memory To access the GPM of a target node locally or over-the-air, send commands to the MEMORY_ACCESS cluster ID (0x23) on the DIGI_DEVICE endpoint (0xE6) of the target node using explicit API frames. For a description of Explicit API frames, see Operate in API mode. To issue a GPM command, format the payload of an explicit API frame as follows: Byte offset in payload Number of bytes Field name General field description 0 1 GPM_CMD_ID Specific GPM commands are described in detail in the topics that follow. 1 1 GPM_OPTIONS Command-specific options. 2 2* GPM_BLOCK_NUM The block number addressed in the GPM. 4 2* GPM_START_INDEX The byte index within the addressed GPM block. 6 2* GPM_NUM_BYTES The number of bytes in the GPM_ DATA field, or in the case of a READ, the number of bytes requested. 8 varies GPM_DATA * Specify multi-byte parameters with big-endian byte ordering. When a device sends a GPM command to another device via a unicast, the receiving device sends a unicast response back to the requesting device's source endpoint specified in the request packet. It does not send a response for broadcast requests. If the source endpoint is set to the DIGI_DEVICE endpoint (0xE6) or Explicit API mode is enabled on the requesting device, then the requesting node outputs a GPM response as an explicit API RX indicator frame (assuming it has API mode enabled). The format of the response is similar to the request packet: XBee®-PRO 900HP/XSC RF Modules 180 General Purpose Flash Memory General Purpose Flash Memory commands Byte offset in payload Number of bytes Field name General field description 0 1 GPM_CMD_ID This field is the same as the request field. 1 1 GPM_STATUS Status indicating whether the command was successful. 2 2* GPM_BLOCK_NUM The block number addressed in the GPM. 4 2* GPM_START_INDEX The byte index within the addressed GPM block. 6 2* GPM_NUM_BYTES The number of bytes in the GPM_DATA field. 8 varies GPM_DATA * Specify multi-byte parameters with big-endian byte ordering. General Purpose Flash Memory commands This section provides information about commands that interact with GPM: PLATFORM_INFO_REQUEST (0x00) A PLATFORM_INFO_REQUEST frame can be sent to query details of the GPM structure. Field name Command-specific description GPM_CMD_ID Should be set to PLATFORM_INFO_REQUEST (0x00). GPM_OPTIONS This field is unused for this command. Set to 0. GPM_BLOCK_NUM This field is unused for this command. Set to 0. GPM_START_INDEX This field is unused for this command. Set to 0. GPM_NUM_BYTES This field is unused for this command. Set to 0. GPM_DATA No data bytes should be specified for this command. PLATFORM_INFO (0x80) When a PLATFORM_INFO_REQUEST command request has been unicast to a node, that node sends a response in the following format to the source endpoint specified in the requesting frame. Field name Command-specific description GPM_CMD_ID Should be set to PLATFORM_INFO (0x80). GPM_STATUS A 1 in the least significant bit indicates an error occurred. All other bits are reserved at this time. XBee®-PRO 900HP/XSC RF Modules 181 General Purpose Flash Memory General Purpose Flash Memory commands Field name Command-specific description GPM_BLOCK_NUM Indicates the number of GPM blocks available. GPM_START_INDEX Indicates the size, in bytes, of a GPM block. GPM_NUM_BYTES The number of bytes in the GPM_DATA field. For this command, this field will be set to 0. GPM_DATA No data bytes are specified for this command. Example A PLATFORM_INFO_REQUEST sent to a device with a serial number of 0x0013a200407402AC should be formatted as follows (spaces added to delineate fields): 7E 001C 11 01 0013A200407402AC FFFE E6 E6 0023 C105 00 00 00 00 0000 0000 0000 24 Assuming all transmissions were successful, the following API packets would be output the source node's serial interface: 7E 0007 8B 01 FFFE 00 00 00 76 7E 001A 91 0013A200407402AC FFFE E6 E6 0023 C105 C1 80 00 0077 0200 0000 EB ERASE (0x01) The ERASE command erases (writes all bits to binary 1) one or all of the GPM flash blocks. You can also use the ERASE command to erase all blocks of the GPM by setting the GPM_NUM_BYTES field to 0. Field name Command-specific description GPM_CMD_ID Should be set to ERASE (0x01). GPM_OPTIONS There are currently no options defined for the ERASE command. Set this field to 0. GPM_BLOCK_NUM Set to the index of the GPM block that should be erased. When erasing all GPM blocks, this field is ignored (set to 0). GPM_START_INDEX The ERASE command only works on complete GPM blocks. The command cannot be used to erase part of a GPM block. For this reason GPM_START_INDEX is unused (set to 0). GPM_NUM_BYTES Setting GPM_NUM_BYTES to 0 has a special meaning. It indicates that every flash block in the GPM should be erased (not just the one specified with GPM_BLOCK_NUM). In all other cases, the GPM_NUM_BYTES field should be set to the GPM flash block size. GPM_DATA No data bytes are specified for this command. ERASE_RESPONSE (0x81) When an ERASE command request has been unicast to a node, that node sends a response in the following format to the source endpoint specified in the requesting frame. XBee®-PRO 900HP/XSC RF Modules 182 General Purpose Flash Memory General Purpose Flash Memory commands Field name Command-specific description GPM_CMD_ID Should be set to ERASE_RESPONSE (0x81). GPM_STATUS A 1 in the least significant bit indicates an error occurred. All other bits are reserved at this time. GPM_BLOCK_NUM Matches the parameter passed in the request frame. GPM_START_INDEX Matches the parameter passed in the request frame. GPM_NUM_BYTES The number of bytes in the GPM_DATA field. For this command, this field will be set to 0. GPM_DATA No data bytes are specified for this command. Example To erase flash block 42 of a target radio with serial number of 0x0013a200407402ac format an ERASE packet as follows (spaces added to delineate fields): 7E 001C 11 01 0013A200407402AC FFFE E6 E6 0023 C105 00 C0 01 00 002A 0000 0200 37 Assuming all transmissions were successful, the following API packets would be output the source node's serial interface: 7E 0007 8B 01 FFFE 00 00 00 76 7E 001A 91 0013A200407402AC FFFE E6 E6 0023 C105 C1 81 00 002A 0000 0000 39 WRITE (0x02) and ERASE_THEN_WRITE (0x03) The WRITE command writes the specified bytes to the GPM location specified. Before writing bytes to a GPM block it is important that the bytes have been erased previously. The ERASE_THEN_WRITE command performs an ERASE of the entire GPM block specified with the GPM_BLOCK_NUM field prior to doing a WRITE. Field name Command-specific description GPM_CMD_ID Should be set to WRITE (0x02) or ERASE_THEN_WRITE (0x03). GPM_OPTIONS There are currently no options defined for this command. Set this field to 0. GPM_BLOCK_NUM Set to the index of the GPM block that should be written. GPM_START_INDEX Set to the byte index within the GPM block where the given data should be written. GPM_NUM_BYTES Set to the number of bytes specified in the GPM_DATA field. Only one GPM block can be operated on per command. For this reason, GPM_START_INDEX + GPM_NUM_BYTES cannot be greater than the GPM block size. The number of bytes sent in an explicit API frame (including the GPM command fields) cannot exceed the maximum payload size of the device. The maximum payload size can be queried with the NP command. GPM_DATA The data to be written. XBee®-PRO 900HP/XSC RF Modules 183 General Purpose Flash Memory General Purpose Flash Memory commands WRITE _RESPONSE (0x82) and ERASE_THEN_WRITE_RESPONSE (0x83) When a WRITE or ERASE_THEN_WRITE command request has been unicast to a node, that node sends a response in the following format to the source endpoint specified in the requesting frame. Field name Command-specific description GPM_CMD_ID Should be set to WRITE_RESPONSE (0x82) or ERASE_THEN_WRITE_ RESPONSE (0x83) GPM_STATUS A 1 in the least significant bit indicates an error occurred. All other bits are reserved at this time GPM_BLOCK_NUM Matches the parameter passed in the request frame GPM_START_INDEX Matches the parameter passed in the request frame GPM_NUM_BYTES The number of bytes in the GPM_DATA field. For this command, this field will be set to 0 GPM_DATA No data bytes are specified for these commands Example To write 15 bytes of incrementing data to flash block 22 of a target radio with serial number of 0x0013a200407402ac a WRITE packet should be formatted as follows (spaces added to delineate fields): 7E 002B 11 01 0013A200407402AC FFFE E6 E6 0023 C105 00 C0 02 00 0016 0000 000F 0102030405060708090A0B0C0D0E0F C5 Assuming all transmissions were successful and that flash block 22 was previously erased, the following API packets would be output the source node's serial interface: 7E 0007 8B 01 FFFE 00 00 00 76 7E 001A 91 0013A200407402AC FFFE E6 E6 0023 C105 C1 82 00 0016 0000 0000 4C READ (0x04) You can use the READ command to read the specified number of bytes from the GPM location specified. Data can be queried from only one GPM block per command. Field name Command-specific description GPM_CMD_ID Should be set to READ (0x04). GPM_OPTIONS There are currently no options defined for this command. Set this field to 0. GPM_BLOCK_NUM Set to the index of the GPM block that should be read. GPM_START_INDEX Set to the byte index within the GPM block where the given data should be read. GPM_NUM_BYTES Set to the number of data bytes to be read. Only one GPM block can XBee®-PRO 900HP/XSC RF Modules 184 General Purpose Flash Memory Field name General Purpose Flash Memory commands Command-specific description be operated on per command. For this reason, GPM_START_INDEX + GPM_NUM_BYTES cannot be greater than the GPM block size. The number of bytes sent in an explicit API frame (including the GPM command fields) cannot exceed the maximum payload size of the device. You can query the maximum payload size with the NP AT command. GPM_DATA No data bytes should be specified for this command. READ_RESPONSE (0x84) When a READ command request has been unicast to a node, that node sends a response in the following format to the source endpoint specified in the requesting frame. Field name Command-specific description GPM_CMD_ID Should be set to READ_RESPONSE (0x84). GPM_STATUS A 1 in the least significant bit indicates an error occurred. All other bits are reserved at this time. GPM_BLOCK_NUM Matches the parameter passed in the request frame. GPM_START_INDEX Matches the parameter passed in the request frame. GPM_NUM_BYTES The number of bytes in the GPM_DATA field. GPM_DATA The bytes read from the GPM block specified. Example To read 15 bytes of previously written data from flash block 22 of a target radio with serial number of 0x0013a200407402ac a READ packet should be formatted as follows (spaces added to delineate fields): 7E 001C 11 01 0013A200407402AC FFFE E6 E6 0023 C105 00 C0 04 00 0016 0000 000F 3B Assuming all transmissions were successful and that flash block 22 was previously written with incrementing data, the following API packets would be output the source node's serial interface: 7E 0007 8B 01 FFFE 00 00 00 76 7E 0029 91 0013A200407402AC FFFE E6 E6 0023 C105 C1 84 00 0016 0000 000F 0102030405060708090A0B0C0D0E0F C3 FIRMWARE_VERIFY (0x05) and FIRMWARE_VERIFY_AND_INSTALL (0x06) Use the FIRMWARE_VERIFY and FIRMWARE_VERIFY_AND_INSTALL commands when remotely updating firmware on a device. For more information about firmware updates. These commands check if the GPM contains a valid over-the-air update file. For the FIRMWARE_VERIFY_AND_INSTALL command, if the GPM contains a valid firmware image then the device resets and begins using the new firmware. XBee®-PRO 900HP/XSC RF Modules 185 General Purpose Flash Memory General Purpose Flash Memory commands Field name Command-specific description GPM_CMD_ID Should be set to FIRMWARE_VERIFY (0x05) or FIRMWARE_VERIFY_ AND_INSTALL (0x06) GPM_OPTIONS There are currently no options defined for this command. Set this field to 0. GPM_BLOCK_NUM This field is unused for this command. Set to 0. GPM_START_INDEX This field is unused for this command. Set to 0. GPM_NUM_BYTES This field is unused for this command. Set to 0. GPM_DATA This field is unused for this command FIRMWARE_VERIFY_RESPONSE (0x85) When a FIRMWARE_VERIFY command request has been unicast to a node, that node sends a response in the following format to the source endpoint specified in the requesting frame. Field name Command-specific description GPM_CMD_ID Should be set to FIRMWARE_VERIFY_RESPONSE (0x85) GPM_STATUS A 1 in the least significant bit indicates the GPM does not contain a valid firmware image. A 0 in the least significant bit indicates the GPM does contain a valid firmware image. All other bits are reserved at this time. GPM_BLOCK_NUM This field is unused for this command. Set to 0. GPM_START_INDEX This field is unused for this command. Set to 0. GPM_NUM_BYTES This field is unused for this command. Set to 0. GPM_DATA This field is unused for this command FIRMWARE_VERIFY _AND_INSTALL_RESPONSE (0x86) When a FIRMWARE_VERIFY_AND_INSTALL command request has been unicast to a node, that node sends a response in the following format to the source endpoint specified in the requesting frame only if the GPM memory does not contain a valid image. If the image is valid, the device resets and begins using the new firmware. Field name Command-specific description GPM_CMD_ID Should be set to FIRMWARE_VERIFY_AND_INSTALL_RESPONSE (0x86). GPM_STATUS A 1 in the least significant bit indicates the GPM does not contain a valid firmware image. All other bits are reserved at this time. GPM_BLOCK_NUM This field is unused for this command. Set to 0. XBee®-PRO 900HP/XSC RF Modules 186 General Purpose Flash Memory Work with flash memory Field name Command-specific description GPM_START_INDEX This field is unused for this command. Set to 0. GPM_NUM_BYTES This field is unused for this command. Set to 0. GPM_DATA This field is unused for this command. Example To verify a firmware image previously loaded into the GPM on a target device with serial number 0x0013a200407402ac, format a FIRMWARE_VERIFY packet as follows (spaces added to delineate fields): 7E 001C 11 01 0013A200407402AC FFFE E6 E6 0023 C105 00 00 05 00 0000 0000 0000 1F Assuming all transmissions were successful and that the firmware image previously loaded into the GPM is valid, the following API packets would be output the source node's serial interface: 7E 0007 8B 01 FFFE 00 00 00 76 7E 001A 91 0013A200407402AC FFFE E6 E6 0023 C105 C1 85 00 0000 0000 0000 5F Work with flash memory When working with the General Purpose Memory, observe the following limitations: n Flash memory write operations are only capable of changing binary 1s to binary 0s. Only the erase operation can change binary 0s to binary 1s. For this reason, you should erase a flash block before performing a write operation. n When performing an erase operation, you must erase the entire flash memory block—you cannot erase parts of a flash memory block. n Flash memory has a limited lifetime. The flash memory on which the GPM is based is rated at 20,000 erase cycles before failure. Take care to ensure that the frequency of erase/write operations allows for the desired product lifetime. Digi's warranty does not cover products that have exceeded the allowed number of erase cycles. n Over-the-air firmware upgrades erase the entire GPM. Any user data stored in the GPM will be lost during an over-the-air upgrade. XBee®-PRO 900HP/XSC RF Modules 187 XSC firmware This section provides an overview of the XBee-PRO XSC firmware and the technical specifications. XBee-PRO XSC RF Module overview Pin signals Electrical characteristics XBee®-PRO 900HP/XSC RF Modules 189 189 190 188 XSC firmware XBee-PRO XSC RF Module overview XBee-PRO XSC RF Module overview The XBee-PRO XSC RF Modules are engineered to afford integrators with an easy-to-use RF solution that provides reliable delivery of critical data between remote devices. These modules come configured to sustain reliable long-range wireless links. The XBee-PRO XSC RF Module is a drop-in wireless solution that transfers a standard asynchronous serial data stream. The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant, which features better performance, lower current draw, and is backward compatible with and a direct replacement for S3 radios. The S3B hardware with XSC firmware is also fully backward compatible (serial interface and over-the-air) with the 9XStream radios. Pin signals The following table shows the pin signal descriptions. Low-asserted signals are distinguished with a horizontal line over the signal name. Pin Public signal I/O 1 VCC I 2 DO  (Data Out) O N/A Serial data exiting the module (to the UART host); See UART-interfaced data flow. 3 DI (Data In I N/A Serial data entering the module (from UART host). See UART-interfaced data flow. 4 DO3 / RX LED O High Pin is driven high during RF data reception; otherwise, the pin is driven low. See CD (DO3 Configuration) to enable. 5 RESET1 I/O Low Re-boot module (minimum pulse is 90 µs). Open Drain configuration. Module drives reset line low momentarily on reboot and power up. 6 CONFIG2 I Low / high Pin can be used as a backup method for entering Command Mode during power-up. Primary method is with +++. See AT commands for more information. O Driven high Do not connect 7 When active Function Supply voltage 1Has a pull up resistor. S3B has internal pull-up. 2Has a pull up resistor. S3B has internal pull-up. XBee®-PRO 900HP/XSC RF Modules 189 XSC firmware Pin Electrical characteristics Public signal 8 I/O When active Function NC 9 DI3 / SLEEP1 I 10 GND 11 Do not connect High By default, DI3 pin is not used. To configure this pin to support sleep modes, see Sleep mode, SM (Sleep Mode) and PW (Pin Wakeup). Ground O Driven high Do not connect 12 DO2 / CTS/ RS485 Enable O Low CTS (clear-to-send) flow control. When pin is driven low, UART host is permitted to send serial data to the module. Refer to UART-interfaced data flow and for more information. RS-485 Enable. To configure this pin to enable RS-485 (2-wire or 4-wire) communications, refer to UARTinterfaced data flow and . 13 ON / SLEEP O High High = Indicates power is on and module is not in Sleep mode. Low = Sleep mode or module is unpowered. 14 VREF I N/A Not used on this module. For compatibility with other XBee devices, we recommend connecting this pin to a voltage reference if analog sampling is desired. Otherwise, connect to GND. 15 TX / PWR O N/A Low = TX - Pin pulses low during transmission High = PWR - Indicates power is on and module is not in Sleep mode. 16 DI2 / RTS / CMD2 I Low RTS (request-to-send) flow control - By default, this pin is not used. To configure this pin to regulate the flow of serial data exiting the module, refer to UART-interfaced data flow and RT (DI2 Configuration). CMD. Refer to Configuration and commands and RT (DI2 Configuration) to enable binary command programming. 17 O Driven low Do not connect 18 O Driven low Do not connect 19 O Driven low Do not connect 20 O Driven low Do not connect Electrical characteristics When the transmitting device receives the first byte of data in the DIN buffer, it initiates the data flow sequence. As long as the TX device is not already receiving RF data, it converts the data in the DIN 1Has a pull up resistor. S3B has internal pull-up. 2Has a pull down resistor. S3B has internal pull-up. XBee®-PRO 900HP/XSC RF Modules 190 XSC firmware Electrical characteristics buffer into packets and transmits them over-the-air to the receiving device. Timing specifications The following figure illustrates the timing specifications. Host A and Host B correspond to a transmitting device (Host A) and receiving device (Host B). XBee®-PRO 900HP/XSC RF Modules 191 XSC firmware Electrical characteristics The following table provides typical AC characteristics when SY = 0. The symbols correspond with the previous two figures. Symbol Description 9600 baud rate (32 byte packet) TTX Latency from the time data is transmitted until received 72.0 ms TTL Time that TX/PWR pin is driven low 16.8 ms TRL Time that RX LED pin is driven high 25.6 ms TST Channel Initialization Time 35.0 ms The following table provides typical DC characteristics when VCC = 3.0 - 3.6 VDC. Symbol Parameter Vcc Module supply voltage Condition Min 3.01 Typical Max Units 3.6 V 1The minimum voltage for S3B is 2.1 V, however maximum power is reduced and sensitivity may degrade. XBee®-PRO 900HP/XSC RF Modules 192 XSC firmware Electrical characteristics Symbol Parameter Condition Min VIL Input low voltage All input signals VIH Input high voltage All input signals VOL Output low-level voltage Iout = Iout_Max VOH Output high-level voltage Iout = Iout_Max IL Input leakage current With pull-up resistors disabled1 IO1 Output current IO2 Output current Typical Max Units -0.3 0.3 VCC V 0.7 VCC VCC + 0.3 V 0.4 V -0.4 VCC V 40 400 nA Pins 2, 15 (DOUT, TX/PWR) 2 mA Pins 4, 12, 13 (DO3, CTS, ON/SLEEP) 8 mA 1S3B can have pull-ups enabled and still maintain low leakage current. XBee®-PRO 900HP/XSC RF Modules 193 XBee-PRO XSC specifications Performance specifications Power requirements Networking specifications General specifications Antenna options Regulatory conformity summary XBee®-PRO 900HP/XSC RF Modules 195 195 196 196 196 197 194 XBee-PRO XSC specifications Performance specifications Performance specifications The following table describes the performance specifications for the devices. Note Range figure estimates are based on free-air terrain with limited sources of interference. Actual range will vary based on transmitting power, orientation of transmitter and receiver, height of transmitting antenna, height of receiving antenna, weather conditions, interference sources in the area, and terrain between receiver and transmitter, including indoor and outdoor structures such as walls, trees, buildings, hills, and mountains. Specification XBee-PRO XSC (S3* hardware) XBee-PRO XSC (S3B hardware) Indoor/urban range Up to 370 m (1200 ft) Up to 610 m (2000 ft) Outdoor line-of-sight range Up to 9.6 km (6 mi) with dipole antenna Up to 24 km (15 mi) with highgain antenna Up to 14 km (9 mi) with dipole antenna Up to 45 km (28 mi) with highgain antenna Interface data rate 125 - 65,000 b/s (software selectable, includes non-standard baud rates) Throughput data rate 9,600 b/s 9.6 kb/s or 19.2 kb/s RF data rate 10 kb/s 10 kb/s or 20 kb/s Transmit power output +20 dBm (100 mW) Up to 24 dBm (250 mW) software selectable Receiver sensitivity -106 dBm -109 dBm at 9600 baud -107 dBm at 19200 baud * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. Power requirements This table describes the power requirements for the devices.  Specification XBee-PRO XSC (S3B XBee-PRO XSC (S3* hardware) hardware) Supply voltage 3.0-3.6 VDC regulated 2.1 to 3.6 VDC Receive current 65 mA 26 mA typical Transmit current 265 mA 215 mA at 24 dBm Power down current 50 uA 2.5 µA typical @3.3 v * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. XBee®-PRO 900HP/XSC RF Modules 195 XBee-PRO XSC specifications Networking specifications Networking specifications The following table provides the networking specifications for the device. Specification XBee-PRO XSC (S3B XBee-PRO XSC (S3* hardware) hardware) Frequency range 902-928 MHz (located in the 900 MHz ISM band) Spread spectrum Frequency hopping Network topology Point-to-point, peer-to-peer, point-to-multipoint Channel capacity 7 hop sequences share 25 frequencies Board-level serial data interface  3V CMOS UART (5 V-tolerant) (S3B) 3 V CMOS UART * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. General specifications The following table describes the general specifications for the devices. Specification XBee-PRO XSC (S3* and S3B hardware) Module board size 3.29 cm x 2.44 cm x 0.546 cm (1.297 x 0.962 x 0.215 in) Dimensions do not include connector/antenna or pin lengths Weight 5 to 8 grams, depending on the antenna option Connector Two rows of 10 pins, 22 mm apart with 2 mm spaced male Berg-type headers Operating temperature -40 to 85 ºC (industrial) * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. Antenna options The following table describes the antenna options for the devices. Specification XBee-PRO XSC (S3* and S3B hardware) Integrated wire ¼ wave monopole, 8.26 cm (3.25 in) length, 1.9 dBi gain RF connector Reverse-polarity SMA or U.FL Impedance 50 Ω unbalanced * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. XBee®-PRO 900HP/XSC RF Modules 196 XBee-PRO XSC specifications Regulatory conformity summary Regulatory conformity summary This table describes the agency approvals for the XBee-PRO XSC. Specification XBee-PRO XSC (S3* and S3B hardware) FCC Part 15.247 FCC ID: MCQ-XB900HP Innovation, Science and Economic Development Canada (ISED) IC: 1846A-XB900HP Australia RCM Brazil ANATEL 3727-12-1209 RoHS Compliant * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. XBee®-PRO 900HP/XSC RF Modules 197 XBee-PRO XSC RF Module operation Serial communications UART-interfaced data flow Serial data Flow control Operating modes XBee®-PRO 900HP/XSC RF Modules 199 199 199 199 201 198 XBee-PRO XSC RF Module operation Serial communications Serial communications The XBee module interfaces to a host device through a CMOS-level asynchronous serial port. Through its serial port, the module can communicate with any UART voltage compatible device or through a level translator to any RS-232/485/422 device. UART-interfaced data flow Devices that have a UART interface connect directly through the pins of the XBee module as shown in the following figure. The following diagram shows the system data flow in a UART-interfaced environment (Low-asserted signals distinguished with horizontal line over signal name). Serial data Data enters the XBee device through the DI pin as an asynchronous serial signal. When no data is being transmitted, the signal should idle high. The UART performs tasks, such as timing and parity checking, that are needed for data communications. Serial communication consists of two UARTs, one being the XBee device's and the other being the microcontroller's, configured with compatible parameters (baud rate, parity, start bits, stop bits, data bits) to have successful communication. Each data packet consists of a start bit (low), 8 data bits (least significant bit first) and a stop bit (high). The following figure illustrates the serial bit pattern of data passing through the module. The UART data packet 0x1F (decimal number “31”) transmits through the XBee-PRO 900HP RF Module example data format is 8-N-1 (bits - parity - # of stop bits). Flow control The following internal data flow diagram shows the five most commonly-used pin signals. XBee®-PRO 900HP/XSC RF Modules 199 XBee-PRO XSC RF Module operation Flow control Data In (DIN) buffer and flow control When serial data enters the device through the DIN pin (pin ), it stores the data in the DIN buffer until it can process the data. When the firmware satisfies the RB and RO parameter thresholds, the device attempts to initialize an RF transmission. If the device is already receiving RF data, it stores the serial data in the device's DIN buffer. 1. The device does not receive any serial characters for the amount of time set with in the RO command; see RO (Packetization Timeout). 2. The device receives the maximum number of characters that fits in an RF packet. 3. The device receives the Command Mode sequence. If the DIN buffer becomes full, you must implement hardware or software flow control in order to prevent overflow (loss of data between the host and the device). To eliminate the need for flow control: 1. Send messages that are smaller than the DIN buffer size. The size of the DIN buffer varies according to the packet size (PK parameter) and the parity setting (NB parameter) you use. 2. Interface at a lower baud rate (BD parameter) than the RF data rate of the firmware (BR parameter) of the firmware. In the following situations, the DIN buffer may become full and overflow: 1. If you set the serial interface data rate higher than the RF data rate of the device, the device receives data from the host faster than it can transmit the data over-the-air. 2. If the device receives a continuous stream of RF data or if the device monitors data on a network, it places any serial data that arrives on the DIN pin (pin ) in the DIN buffer. It transmits the data in the DIN buffer over-the-air when the device no longer detects RF data in the network. Hardware flow control (CTS) The firmware asserts CTS before the DIN buffer is full so it has time to send the signal and the host has time to stop sending data. When the DIN buffer is full, the firmware de-asserts CTS (high) to signal the host to stop sending data; refer to FT (Flow Control Threshold) and CS (DO2 Configuration). The firmware re-asserts CTS after the DIN buffer has 34 bytes of memory available. XBee®-PRO 900HP/XSC RF Modules 200 XBee-PRO XSC RF Module operation Operating modes Data Out (DO) buffer and flow control When a device receives RF data, the data enters the DOUT buffer and the device sends it out the serial port to a host device. Once the DOUT buffer reaches capacity, it loses any additional incoming RF data. In the following situations, the DOUT buffer may become full and overflow: 1. If the RF data rate is set higher than the interface data rate of the device, the devices receives data from the transmitting device faster than it can send the data to the host. 2. If the host does not allow the device to transmit data out from the DOUT buffer because of being held off by hardware or software flow control. Hardware flow control (RTS) If you enable RTS for flow control (RT = 2), data will not be sent out the DO Buffer as long as RTS (pin 16) is de-asserted. Software flow control (XOFF) You can enable XON/XOFF software flow control using FL (Software Flow Control). This option only works with ASCII data. Operating modes This section describes the different operating modes for the device. Idle mode When not receiving or transmitting data, the device is in Idle mode. During Idle mode, the device listens for valid data on both the RF and serial ports. The device shifts into the other modes of operation under the following conditions: XBee®-PRO 900HP/XSC RF Modules 201 XBee-PRO XSC RF Module operation Operating modes n Transmit mode (serial data in the serial receive buffer is ready to be packetized). n Receive mode (valid RF data received through the antenna). n Command mode (Command mode sequence issued, not available with Smart Energy software or when using the SPI port). Transmit mode When the device received the first byte of serial data from the UART in the DI buffer, the modem attempts to shift to Transmit Mode and initiate an RF connection with other modems. After completing the transmission, the modem returns to Idle Mode. RF transmission begins after meeting either of the following criteria: 1. RB bytes have been received in the DI buffer and are pending for RF transmission. For more information, see RB (Packetization Threshold). The RB parameter may be set to any value between 1 and the RF packet size (PK), inclusive. When RB = 0, the packetization threshold is ignored. 2. At least one character has been received in the DI buffer (pending for RF transmission) and RO time has been observed on the UART. Refer to RO (Packetization Timeout). - The time out can be disabled by setting RO to zero. In this case, transmission will begin after RB bytes have been received in the DI buffer. Note RF reception must complete before the modem is able to enter into Transmit Mode. After meeting either RB or RO conditions, the modem initializes a communications channel. Channel initialization is the process of sending an RF initializer that synchronizes receiving modems with the transmitting modem. During channel initialization, incoming serial data accumulates in the DI buffer. The device then: n Groups serial data in the DI buffer (for more information, see PK (Maximum RF Packet Size) n Converts the data to RF data n Transmits the data over-the-air until the DI buffer is empty RF data, which includes the payload data, follows the RF initializer. The payload includes up to the maximum packet size (PK Command) bytes. As the transmitting modem nears the end of the transmission, it inspects the DI buffer to see if more data exists to be transmitted. This could be the case if more than PK bytes were originally pending in the DI buffer or if more bytes arrived from the UART after the transmission began. If more data is pending, the transmitting modem assembles a subsequent packet for transmission. Receive mode If a destination node receives a valid RF packet, the destination node transfers the data to its serial transmit buffer. For the serial interface to report receive data on the RF network, that data must meet the following criteria: n ID match n Channel match n Address match XBee®-PRO 900HP/XSC RF Modules 202 XBee-PRO XSC RF Module operation Operating modes Sleep mode Sleep Modes enable the device to operate at minimal power consumption when not in use. The following Sleep mode options are available: n Pin sleep n Cyclic sleep For the device to transition to Sleep Mode, the module must have a non-zero SM (Sleep Mode) Parameter and one of the following must occur: n The device is idle (no data transmission or reception) for a user-defined period of time. Refer to the ST (Wake Time) n The device asserts SLEEP (only for Pin Sleep option). In Sleep Mode, the device will not transmit or receive data until the module first transitions to Idle Mode. All Sleep Modes are enabled and disabled using the SM command. The device triggers transitions into and out of sleep modes are triggered by various events as shown in the table below. Transition out of Sleep mode Related commands Typical power consumption (S3)* Typical power consumption (S3B) Sleep mode setting Transition into Sleep mode Pin Sleep (SM = 1) microcontroller can shut down and wake devices by asserting (high) SLEEP (pin 9). The module completes a transmission or reception before activating Pin Sleep. De-assert (low) SLEEP (pin 9). SM 50 µA 2.5 µA Cyclic Sleep (SM = 3-8) Automatic transition to Sleep Mode occurs in cycles as defined by the SM (Sleep Mode) Command. The cyclic sleep time interval must be shorter than the “Wake-up Initializer Timer” (set by LH Command). After the cyclic sleep time interval elapses. Device can be forced into Idle Mode if PW (Pin Wakeup) command is enabled. SM, ST, HT, LH, PW 76 µA when sleeping 2.5 µA when sleeping * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. XBee®-PRO 900HP/XSC RF Modules 203 XBee-PRO XSC RF Module operation Operating modes Pin Sleep (SM = 1) To achieve this state, assert the SLEEP pin (high). The device remains in Pin Sleep until you de-assert the SLEEP pin. After enabling Pin Sleep, the SLEEP pin controls whether the device is active or sleeping. When the host de-asserts SLEEP, the device is fully operational. When the host asserts SLEEP, the device transitions to Sleep mode and remains in its lowest power-consuming state until the host de-asserts the pin. This pin is only active if the device is setup to operate in this mode; otherwise the firmware ignores the pin. Once in Pin Sleep, the device de-asserts (high) CTS (pin ) , indicating that other devices should not send data to the device. The device also de-asserts (low) the TX_PWR line (pin ) when the device is in Pin Sleep mode. You cannot assert the SLEEP (pin9) until the transmission of the second byte has started. Note The device completes a transmission or reception before activating Pin Sleep. Cyclic Sleep Mode (SM = 4 - 8) Cyclic Sleep modes allow device wakes according to the times designated by the cyclic sleep settings. If the device detects a wake-up initializer during the time it is awake, the device synchronizes with the transmitting device and receives data after the wake-up initializer runs its duration. Otherwise, the device returns to Sleep mode and continues to cycle in and out of activity until a wake-up initializer is detected. While the device is in Cyclic Sleep mode, it de-asserts (high) CTS (pin ) to indicate not to send data to the device. When the device awakens to listen for data, it asserts CTS and transmits any data received on the DI pin. The device also de-asserts (low) the TX_PWR (pin ) when it is in Cyclic Sleep mode. The device remains in Sleep mode for a user-defined period of time ranging from 1 second to 16 seconds (SM parameters 4 through 8). After this interval of time, the device returns to Idle mode and listens for a valid data packet. The listen time depends on the BR parameter setting. The default BR setting of 1 requires at least a 35 ms wake time, while the BR setting of 0 requires a wake time of up to 225 ms. If the device does not detect valid data on any frequency, it returns to Sleep mode. If it detects valid data, it transitions into Receive mode and receives the incoming RF packets. The device then returns to Sleep mode after a period of inactivity determined by the ST parameter. You can also configure the device to wake from cyclic sleep when the SLEEP pin is de-asserted. To configure a device to operate in this manner, you must send the PW (Pin Wake-up) command. When you de-assert the SLEEP pin, it forces the device into Idle mode and it can begin transmitting or receiving data. It remains active until it no longer detects data for the time that ST specifies, at which point it resumes its low-power cyclic state. Cyclic scanning Each RF transmission consists of an RF initializer and payload. The RF initializer contains initialization information and all receiving devices must wake during the wake-up initializer portion of data transmission in order to synchronize with the transmitting device and receive the data. The cyclic interval time defined by the SM (Sleep Mode) command must be shorter than the interval time defined by LH (Wake-up Initializer Timer) command. Correct configuration (LH > SM) In the following figure, the length of the wake-up initializer exceeds the time interval of Cyclic Sleep. The receiver is guaranteed to detect the wake-up initializer and receive the accompanying payload data. XBee®-PRO 900HP/XSC RF Modules 204 XBee-PRO XSC RF Module operation Operating modes Incorrect configuration (LH < SM) Length of wake-up initializer is shorter than the time interval of Cyclic Sleep. This configuration is vulnerable to the receiver waking and missing the wake-up initializer (and therefore also the accompanying payload data). Command mode To modify or read device parameters, the device must be in Command Mode, the state in which it interprets received characters on the UART as commands. Two command types are available for programming the device: XBee®-PRO 900HP/XSC RF Modules 205 XBee-PRO XSC RF Module operation n AT commands n Binary commands Operating modes For modified parameter values to persist in the device registry, you must save changes to non-volatile memory using WR (Write) Command. Otherwise, parameters are restored to previously saved values after you power the device off and then on again. AT commands To enter AT Command mode: n Send the 3-character command sequence +++ and observe guard times before and after the command characters. You can use the Terminal tab (or other serial communications software) of the XCTU Software to enter the sequence. Or n Assert (low) the CONFIG pin and either turn the power going to the device off and back on. If using a Digi XBIB-R Interface Board, you can also hold the Data-In line low (also known as a break) while rebooting the device by pressing the reset button on the device assembly [device assembly = device mounted to an interface board. Default AT Command mode sequence (for transition to Command Mode): n No characters sent for one second. See the BT (Guard Time Before). n Input three plus characters (“+++”) within one second. See CC (Command Sequence Character). n No characters sent for one second. See AT (Guard Time After). Send AT commands: Send AT commands and parameters using the following syntax. Syntax for sending AT commands To read a parameter value stored in the XBee-PRO XSC RF Module register, leave the parameter field blank. The preceding example changes the XBee-PRO XSC RF Module’s Destination Address to 0x1F. To store the new value to non-volatile (long term) memory, send the Write (WR) command before powering off the XBee-PRO XSC RF Module. System response When the device sends a command to the XBee-PRO XSC RF Module, the device parses and executes the command. If the execution of the command is successful, the device returns an OK message. If the execution of the command results in an error, the returns an ERROR message. Exit AT Command mode: If no valid AT Commands are received within the time specified by CT (Command Mode Time-out) Command, the device automatically does one of the following: XBee®-PRO 900HP/XSC RF Modules 206 XBee-PRO XSC RF Module operation n Returns to Idle Mode n Send CN (Exit Command Mode) Command Operating modes For an example of programming the XBee-PRO XSC RF Module using AT Commands and descriptions of each configurable parameter, refer to Configuration and commands. Binary commands Sending and receiving parameter values using binary commands is the fastest way to change operating parameters of the module. Binary commands are used most often to sample signal strength (RS parameter) or error counts; or to change module addresses and channels for polling systems when a quick response is necessary. Because sending and receiving parameter values takes place through the same data path as 'live' data (received RF payload), follow the CTS pin to distinguish between the two types of data (commands vs 'live' data). Common questions regarding the use of binary commands: n What are the implications of asserting CMD while live data is being sent or received? n After sending serial data, is there a minimum time delay before CMD can be asserted? n Is a time delay required after CMD is de-asserted before payload data can be sent? n How can I determine the difference between live data and data received in response to a command? You must assert CMD (pin 16) in order to send binary commands to the device. You can assert the CMD pin to recognize binary commands anytime during the transmission or reception of data. The device only check the status of the CMD signal at the end of the stop bit as the byte is shifted into the serial port. The application does not allow control over when data is received, except by waiting for dead time between bursts of communication. If the device sends a command in the middle of a stream of payload data to be transmitted, the command executes in the order it is received. If the radio is continuously receiving data, the radio waits for a break in the received data before executing the command. The CTS signal frames the response coming from the binary command request as shows in the following figure. The user must observe a minimum time delay of 100 µs (after the stop bit of the command byte has been sent) before de-asserting the CMD (pin 16). The command executes after all parameters associated with the command have been sent. If all parameters are not received within 0.5 seconds, the module aborts the command and returns to Idle Mode. Note Binary commands that return only one parameter byte must also be written with two parameter bytes, 0-padded, LSB first. Refer to for a binary programming example. You can query commands for their current value by sending the command logically ORed (bit-wise) with the value 0x80 (hexadecimal) with CMD asserted. When the device sends the binary value (with no parameters), the current value of the command parameter is sent back through the DO pin. Binary command write then read XBee®-PRO 900HP/XSC RF Modules 207 XBee-PRO XSC RF Module operation Operating modes Signal #4 is CMD (pin 16) Signal #1 is the DIN (pin 3) signal to the radio Signal #2 is the DOUT (pin 2) signal from the radio Signal #3 is CTS (pin 12) This graph shows a value written to a register and then read out to verify it. While not in the middle of other received data, the CTS signal outlines the data response out of the device Note For the XBee module to recognize a binary command, you must set the RT (DI2 Configuration) parameter to one. If you have not enabled binary programming RT = 0 or 2, the device will not recognize that the CMD pin is asserted and therefore will not recognize the data as binary commands. XBee®-PRO 900HP/XSC RF Modules 208 Configuration and commands Programming examples Send binary commands Special commands Command mode options Networking and security commands Network commands Serial interfacing commands Diagnostic commands Sleep commands XBee®-PRO 900HP/XSC RF Modules 210 210 211 211 215 217 221 226 231 209 Configuration and commands Programming examples Programming examples For steps on sending AT commands to a device, refer to: n Send AT commands n Exit Command mode For more information, refer to the XCTU online help at: docs.digi.com/display/XCTU/XCTU+Overview Connect the device to a PC The programming examples that follow require the installation of XCTU and a serial connection to a PC. Digi stocks connector boards to facilitate interfacing with a PC. 1. Download XCTU from the Digi website: digi.com/products/xbee-rf-solutions/xctu-software/xctu#resources 2. After the .exe file downloads to the PC, double-click the file to launch the XCTU Setup Wizard. Follow the steps in the wizard to completely install XCTU. 3. Mount the device to an interface board, then connect the assembly to a PC. 4. Launch XCTU and click the Add devices tab on the upper left corner of the screen. 5. Verify that the baud rate and parity settings of the Serial/USB port match those of the device. Note Failure to enter Command mode is commonly due to baud rate mismatch. Ensure that the Baud Rate: setting on the Add radio device window matches the interface data rate of the device. By default, the BD parameter = 9600 b/s. Send binary commands Example Use XCTU's Serial Console tool to change the device's DT (Destination Address) parameter and save the new address to non-volatile memory. This example requires XCTU and a serial connection to a PC. To send binary commands: 1. Set the RT command to 1 to enable binary command programming; do this in Command mode or configure it through XCTU. 2. Drive pin 16 high to assert CMD by de-asserting the RTS line in XCTU. The device enters Binary Command mode. 3. Send hexadecimal bytes (parameter bytes must be 2 bytes long). The next four lines are examples, not required values: 00 (Send binary command DT) 0D (Least significant byte of parameter bytes) 1A (Most significant byte of parameter bytes) 08 (Send binary command WR) 4. Drive pin 16 low to de-assert CMD. After you send the commands, CTS (pin ) de-asserts (driven low) temporarily. The device exits Binary Command mode. XBee®-PRO 900HP/XSC RF Modules 210 Configuration and commands Special commands The default flow control is NONE, so if you are using XCTU, CTS is not an issue. However, you can still observe the behavior of the CTS line by monitoring the CTS indicator in the terminal or console. Special commands The following commands are special commands. FR (Force Reset) If you issue FR while the device is in Command Mode, the reset effectively exits Command mode. Resets the device through the UART. The device responds immediately with an OK and performs a reset 100 ms later. Parameter range N/A Default N/A PL (TX Power Level) Sets or displays the power level at which the device transmits conducted power. The device calibrates Power lever 4 and other levels are approximate. Binary command 0x3C (60 decimal) Parameter range 0-4 Parameter Configuration 0 +7.0 dBm, (5 mW) 1 +15.0 dBm, (32 mW) 2 +18.0 dBm, (63 mW) 3 +21.0 dBm, (125 mW) 4 +24.0 dBm, (250 mW) Default 4 Bytes returned 1 Command mode options The following commands are Command mode option commands. XBee®-PRO 900HP/XSC RF Modules 211 Configuration and commands Command mode options AT (Guard Time After) Sets or displays the time-of-silence that follows the CC (Command Sequence Character) of the Command mode sequence (BT + CC + AT). By default, one second must elapse before and after the command sequence character. The times-of-silence surrounding the Command Sequence Character prevent the device from inadvertently entering Command mode. Binary command 0x05 (5 decimal) Parameter range 0x02 – 0xFFFF [x 100 milliseconds] Default 0xA (1 second) Bytes returned 2 BT (Guard Time Before) Sets the DI pin silence time that must precede the Command Sequence Character (CC command) of the Command mode sequence. Binary command 0x04 (4 decimal) Parameter range 2 - 0xFFFF [x 100ms] Default 0x0A (1 second) Bytes returned 2 CC (Command Sequence Character) Sets or displays the character the device uses between guard times of the AT Command mode sequence. The AT Command mode sequence causes the device to enter Command Mode (from Idle Mode). Note We recommend using the a value within the rage of 0x20-0x7F as those are ASCII characters. Binary command 0x13 (19 decimal) Parameter range 0x0 - 0xFF XBee®-PRO 900HP/XSC RF Modules 212 Configuration and commands Command mode options Recommended: 0x20 - 0x7F (ASCII) Default 0x2B (ASCII “+”) Bytes returned 1 CD (DO3 Configuration) Selects or reads the behavior of the DO3/RX LED line. Parameter range 0-3 Parameter Configuration 0 RX LED 1 Default high 2 Default low 3 Reserved 4 Assert only when you have sent the packet addressed to the device. Default 0 Bytes returned 1 CN (Exit Command Mode) Makes the device exit Command mode. Binary command 0x09 (9 decimal) Parameter range N/A Default N/A Bytes returned N/A XBee®-PRO 900HP/XSC RF Modules 213 Configuration and commands Command mode options CT (Command Mode Timeout) Set or read the Command mode timeout parameter. If a device does not receive any valid commands within this time period, it returns to Idle mode from Command mode. Use the CN (Exit Command mode) command to exit Command mode manually. Binary command 0x06 (6 decimal) Parameter range 0x02 - 0xFFFFF [x 100 milliseconds] Default 0xC8 (20 seconds) Bytes returned 2 E0 (Echo Off) Turns off the character echo in Command mode. By default, echo is off. Binary command 0x0A (10 decimal) Parameter range N/A Default N/A Bytes returned N/A E1 (Echo On) Enables character echo in Command mode. Each character that you type echoes back to the terminal when E1 is active. E0 (Echo Off) is the default. Binary command 0x0B (11 decimal) Parameter range N/A Default N/A XBee®-PRO 900HP/XSC RF Modules 214 Configuration and commands Networking and security commands Bytes returned N/A PC (Power-up to Transparent operating mode) Sets the device to power-up directly into Command mode from reset or power-on. If you enable the PC Command with the SM Parameter set to 1, you can use the DI3 (pin 9) to enter Command mode. If the PC command is enabled with the SM parameter set to 1, DI3 (pin 9) can be used to enter the module into Command mode. When the device de-asserts (low) the DI3 pin, it wakes-up in Command mode. This behavior allows device DTR emulation. Binary command 0x1E (30 decimal) Parameter range 0-1 Parameter Configuration 0 Power-up to Idle mode 1 Power-up to Command mode Default 0 Bytes returned 1 Networking and security commands The following AT commands are networking and security commands. AM (Auto-set MY) Sets the MY (Source Address) parameter from the factory-set serial number of the device. The address consists of bits 29, 28 and 13-0 of the serial number, in that order. Sending AM displays the address. Note This command is only supported on S3B modules. Binary command 0x3A (58 decimal) Parameter range N/A Default N/A XBee®-PRO 900HP/XSC RF Modules 215 Configuration and commands Networking and security commands Bytes returned N/A MD (RF Mode) Sets or displays the settings that enable the Peer-to-peer or Repeater modes on the device. Repeater Mode enables longer range via an intermediary device. When MD=3, the module acts as a “store and forward” repeater. The device repeats any packets not addressed to this node. A Repeater End Node handles repeated messages, but will not repeat the message over-the-air. For more information, see Repeater mode. Binary command 0x32 (50 decimal) Parameter range 0, 3, 4 Parameter Configuration 0 Peer-to-Peer (transparent operation) 3 Repeater & End Node 4 End Node Default 0 Bytes returned 1 MY (Source Address) Sets or displays the Source Address of a device. For more information, see Addressing. Binary command 0x2A (42 decimal) Parameter range Default 0xFFFF (Disabled - DT (Destination Address) parameter serves as both source and destination address). Bytes returned 2 XBee®-PRO 900HP/XSC RF Modules 216 Configuration and commands Network commands Network commands The following commands are network commands. DT (Destination Address) Sets or displays the networking address of a device. The devices use three filtration layers: n Vendor ID Number (ID) n Channel (HP) n Destination Address (DT) The DT command assigns an address to a device that enables it to communicate with only devices that have the same address. All devices that share the same Destination Address can communicate freely with each other. Devices in the same network with a different Destination Address than the transmitter listen to all transmissions to stay synchronized, but will not send any of the data out their serial ports. Binary command 0x00 (0 decimal) Parameter range 0 - 0xFFFF Default 0 Bytes returned 2 HP (Preamble ID) Set or read the device's hopping channel number. A channel is one of three layers of filtration available to the device. In order for devices to communicate with each other, the devices must have the same channel number since each channel uses a different hopping sequence. Devices can use different channels to prevent devices in one network from listening to transmissions of another. When a device receives a packet it checks HP before the network ID, as it is encoded in the preamble and the network ID is encoded in the MAC header. Binary command 0x11 (17 decimal) Parameter range 0-6 Default 0 Bytes returned 1 XBee®-PRO 900HP/XSC RF Modules 217 Configuration and commands Network commands HT (Time before Wake-up Initializer) Sets or displays the time of inactivity (no serial or RF data is sent or received) before a transmitting (TX) RF device sends a wake-up initializer. The main purpose of this command is to prevent devices from sending the Long Header with every data packet. For more information on long headers, see LH (Wakeup Initializer Timer). For RX devices operating in Cyclic Sleep mode (SM = 4-8), set HT to be shorter than the ST command. The TX device sends a wake-up initializer, which instructs all receiving (RX) devices to remain awake to receive RF data. From the perspective of the RX device: after HT time elapses and the inactivity timeout (ST command) is met, the RX device goes into cyclic sleep. In cyclic sleep, the RX device wakes once per sleep interval (SM command) to check for a wake-up initializer. When it detects a wake-up initializer, the device stays awake to receive data. The wake-up initializer must be longer than the cyclic sleep interval to ensure that sleeping devices detect incoming data. When HT time elapses, the TX device knows it needs to send a wake-up initializer for all RX devices to remain awake and receive the next transmission. Binary command 0x03 (3 decimal) Parameter range 0 - 0xFFFF [x 100 ms] Default 0xFFFF (wake-up initializer will not be sent) Bytes returned 2 ID (Network ID) Sets or displays the Vendor Identification Number (VID) of the device. Devices must have matching VIDs in order to communicate. If the device uses OEM network IDs, 0xFFFF uses the factory value. Binary command 0x27 (39 decimal) Parameter range 0x10 - 0x7FFFF (user-settable) 0x8000 - 0xFFFF (factory-set) Default N/A MK (Address Mask) Sets or read the device's Address Mask. All RF data packets contain the Destination Address of the transmitting (TX) device. When a device receives a packet, the TX device's Destination Address is logically combined bitwise (in other words, joined with AND) with the Address Mask of the receiving (RX) device. The resulting value must match XBee®-PRO 900HP/XSC RF Modules 218 Configuration and commands Network commands the Destination Address or Address Mask of the RX device for the packet to be received and sent out the RX device's DO (Data Out) pin. If the combined value does not match the Destination Address or Address Mask of the RX device, it discards the packet. The firmware treats all 0 values as irrelevant and ignores them. For more information, see Addressing. Binary command 0x12 (18 decimal) Parameter range 0 - 0xFFFF Default 0xFFFF Note The Destination address (DT parameter) of the transmitting device must match the destination address of the receiving device.) Bytes returned 2 RN (Delay Slots) Sets or displays the time delay that the transmitting device inserts before attempting to resend a packet. If the transmitting device fails to receive an acknowledgment after sending a packet, it inserts a random number of delay slots (ranging from 0 to (RN minus 1)) before attempting to resend the packet. Each delay slot is 38 ms. If two devices attempt to transmit at the same time, the random time delay after packet failure only allows one device to transmit the packet successfully, while the other device waits until the channel is available for RF transmission. RN is only applicable if: n You enable retries using the RR command, or n You insert forced delays into a transmission using the TT command Binary command 0x19 (25 decimal) Parameter range 0 - 0xFF [slots] Default 0 (no delay slots inserted) Bytes returned 1 RR (Unicast Mac Retries) Sets or displays the maximum number of retries sent for a given RF packet. When you enable RR (RR > 0), it enables RF packet retries and ACKs. XBee®-PRO 900HP/XSC RF Modules 219 Configuration and commands Network commands After transmitting a packet, the transmitting device waits to receive an ACK from a receiving device. If it does not receive the ACK in the time that RN specifies, it transmits the original packet again. The transmitting device transmits the RF packet repeatedly until it receives an ACK or until it sends the packet RR times. Note You must have retries enabled for all modules in the network for retries to work. Binary command 0x18 (24 decimal) Parameter range 0 - 0xFF Default 0 (disabled) Bytes returned 1 SY (Time Before Initialization) Keeps a communication channel open as long as the device transmits or receives before the active connection expires. You can use this command to reduce latency in a query/response sequence and set it 100 ms longer than the delay between transmissions. This command allows multiple Modules to share a hopping channel for a given amount of time after receiving data. By default, all packets include an RF initializer that contains channel information used to synchronize any listening receivers to the transmitter’s hopping pattern. Once a new device comes within range, it is able to instantly synchronize to the transmitter and start receiving data. If no new devices are introduced into the system, the synchronization information becomes redundant once devices have become synchronized. The SY command allows the devices to remove this information from the RF Initializer after the initial synchronization. For example, changing the SY Parameter to 0x14 (20 decimal) allows all devices to remain in sync for 2 seconds after the last data packet was received. The device does not send synchronization information unless transmission stops for more than 2 seconds. This command allows significant savings in packet transmission time. The SY command is not supported above a value of 5 when interfacing an XBee-PRO XSC S3B with a 9XStream. We do not recommend this command for use in an interference-prone environment. Interference can break up the session making the communications channel unavailable until the SY time expires. If you set SY to zero, the channel session opens and closes with each transmission, resulting in a more robust link with increased latency. Binary command 0x17 (23 decimal) Parameter range 0 – 0xFF [x 100 milliseconds] XBee®-PRO 900HP/XSC RF Modules 220 Configuration and commands Serial interfacing commands Default 0 (Disabled - channel initialization information is sent with each RF packet.) Bytes returned 1 TT (Streaming Limit) Sets or displays the limit on the number of bytes that a device can send before issuing a random delay. If a device is sending a continuous stream of RF data, it inserts a delay that stops its transmission and gives other devices time to transmit once it sends TT bytes of data. The random delay it inserts lasts between 1 and RN + 1 delay slots where each delay slots lasts 38 ms. You can use TT to simulate full-duplex behavior. Binary command 0x1A (26 decimal) Parameter range 0xFFFF (0 = disabled) Default 0xFFFF (65535 decimal) Bytes returned 2 Serial interfacing commands The following commands are serial interfacing commands. BD (Interface Data Rate) Sets and reads the serial interface data rate (baud rate) between the device and the host. The baud rate is the rate that the host sends serial data to the device. When you make an update to the interface data rate, the change does not take effect until the host issues the CN command and the device returns the OK response. The BD parameter does not affect the RF data rate. If you set the interface data rate higher than the RF data rate, you may need to implement a flow control configuration. Non-standard interface data rates When the host sends a value above 0x7D, the firmware stores the closest interface data rate represented by the number in the BD register. For example, to set a rate of 19200 b/s, send the following command line: ATBD4B00. Note When using XCTU, you can only set and read non-standard interface data rates using the XCTU Serial Console tool. You cannot access non-standard rates through the configuration section of XCTU. When you send the BD command with a non-standard interface data rate, the UART adjusts to accommodate the interface rate you request. In most cases, the clock resolution causes the stored BD XBee®-PRO 900HP/XSC RF Modules 221 Configuration and commands Serial interfacing commands parameter to vary from the sent parameter. Sending ATBD without an associated parameter value returns the value actually stored in the device’s BD register. The following table provides the parameters sent versus the parameters stored. BD parameter sent (HEX) Interface data rate (b/s) S3* BD parameter stored (HEX) S3B BD parameter stored (HEX) 0 1200 0 0 4 19,200 4 4 6 57600 6 5 12C 300 12B 12B E100 57600 E883 E10D * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. Binary command 0x15 (21 decimal) Parameter ranges 0 - 6 (standard rates) 0x7D – 0xFFFF (125d – 65535d) (non-standard rates) Parameter Configuration (b/s) 0 1200 1 2400 2 4800 3 9600 4 19200 5 38400 6 57600 Default Set to equal device’s factory-set RF data rate. Bytes returned 2 CS (DO2 Configuration) Sets or displays the behavior of the DO2 pin signal. This output can provide RS-232 flow control and controls the TX enable signal for RS-485 or RS-422 operations. By default, DO2 provides RS-232 Clear-to-Send (CTS ) flow control. XBee®-PRO 900HP/XSC RF Modules 222 Configuration and commands Serial interfacing commands Binary command 0x1F (31 decimal) Parameter range 0-4 Parameter Configuration 0 RS-232 CTS flow control 1 RS-485 TX enable low 2 Static high 3 RS-485 TX enable high 4 Static low Default 0 Bytes returned 1 FL (Software Flow Control) Configures software flow control. Use the device as the DO2 (pin 12) to implement Hardware flow control to regulate when serial data can be transferred to the device . The XON character used is 0x11 (17 decimal). The XOFF character used is 0x13 (19 decimal). Binary command 0x07 (7 decimal) Parameter range 0-1 Parameter Value Configuration 0 Disable software flow control 1 Enable software flow control Default 0 Bytes returned 1 XBee®-PRO 900HP/XSC RF Modules 223 Configuration and commands Serial interfacing commands FT (Flow Control Threshold) Sets or displays the flow control threshold. De-assert CTS when the number of bytes specified by the FT parameter are in the DIN buffer. Reassert CTS when less than FT - 16 bytes are in the UART receive buffer. Binary command 0x24 (36 decimal) Parameter range DI buffer size minus 0x11 bytes Default 0xBBF - DI buffer size minus 0x11 (17 decimal) NB (Parity) Set or read the parity settings for UART communications. Parameter range 0 - 4 (S3* hardware) 0 - 5 (S3B hardware) * The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware variant. Parameter Configuration 0 8-bit (no parity ) 1 8-bit even 2 8-bit odd 3 8-bit mark 4 8-bit space 5 9-bit data (S3B Hardware) Default 0 Bytes returned 1 PK (Maximum RF Packet Size) Sets or displays the maximum size of RF packets that a device in Transparent operating mode (AP = 0) transmits. You can use the maximum packet size along with the RB and RO parameters to implicitly set the channel dwell time. XBee®-PRO 900HP/XSC RF Modules 224 Configuration and commands Serial interfacing commands Changes to the PK parameter may have a secondary effect on the RB (Packetization Threshold) parameter. RB must always be less than or equal to PK. If you change PK to a value that is less than the current value of RB, the RB value lowers to be equal to PK. Note This command is only supported on S3B hardware. Binary command 0x29 (41 decimal) Parameter range 0x2 - 0x100 [Bytes] Default 0x40 (64 decimal) Bytes returned 2 RB (Packetization Threshold) Sets or displays the character threshold value. RF transmission begins after a device receives data in the DIN buffer and meets either of the following criteria: n The UART receives RB characters n The UART receive lines detect RO character times of silence after receiving at least 1 byte of data If a device lowers PK below the value of RB, RB is automatically lowered to match the PK value. If RO = 0, the device must receive RB bytes before beginning transmission. RB and RO criteria only apply to the first packet of a multi-packet transmission. If data remains in the DIN buffer after the first packet, transmissions continue in a streaming manner until there is no data left in the DIN buffer. Binary command 0x20 (32 decimal) Parameter range 1 - 0x100 (bytes) (Maximum value equals the current value of PK Parameter (up to 0x100 HEX (800 decimal)) Default 1 Bytes returned 2 RO (Packetization Timeout) Set or read the number of character times of inter-character silence required before transmission begins. For information on how RO works with the RB command, see RB (Packetization Threshold). XBee®-PRO 900HP/XSC RF Modules 225 Configuration and commands Diagnostic commands After a device receives a serial byte and it receives no other byte before the RO timeout, the tranmission begins. Binary command 0x21 (33 decimal) Parameter range 0 - 0xFFFF [x 200 µs] Default 0 Bytes returned 2 RT (DI2 Configuration) Sets or displays the behavior of the DI2/RTS/CMD line. You must use RT to enable RTS flow control or binary programming. Binary command 0x16 (22 decimal) Parameter range 0-2 Parameter Configuration 0 Disabled 1 Binary Command enable 2 RTS flow control enable Default 0 (disabled) Bytes returned 1 Diagnostic commands The following commands are diagnostic commands. ER (Receive Count Error) Sets or displays the receive error. The error-count records the number of packets partially received then aborted on a reception error. This value returns to 0 after a reset and is not non-volatile (that is, the value does not persist in the module’s memory after a power-up sequence). Once the “Receive Error Count” reaches its maximum value (up to 0xFFFF), it remains at its maximum count value until the maximum count value is explicitly changed or you reset the device. XBee®-PRO 900HP/XSC RF Modules 226 Configuration and commands Diagnostic commands To reset the counter to any 16-bit unsigned value, append a hexadecimal parameter to the command. This value is volatile (the value does not persist in the device's memory after a power-up sequence). Binary command 0x0F (15 decimal) Parameter range 0 - 0xFFFF Default 0 Bytes returned 2 GD (Receive Good Count) This count increments when a device receives a packet that contains integrity errors of some sort. When the number reaches 0xFFFF, the firmware does not count further events. To reset the counter to any 16-bit unsigned value, append a hexadecimal parameter to the command. Parameter range 0 - 0xFFFF Default 0 Bytes returned 2 RE (Restore Defaults) Restore device parameters to factory defaults. RE does not cause the device to store default values to non-volatile (persistent) memory. You must send the WR command prior to power-down or reset to save the default settings in the device's nonvolatile memory. Binary command 0x0E (14 decimal) Parameter range N/A Default N/A Bytes returned N/A XBee®-PRO 900HP/XSC RF Modules 227 Configuration and commands Diagnostic commands RP (RSSI PWM Timer) Enables a pulse-width modulated (PWM) output on the CONFIG pin. We calibrate the pin to show the difference between received signal strength and the sensitivity level of the device. PWM pulses vary from zero to 95 percent. Zero percent means the RF signal the device receives is at or below the device's sensitivity level. The following table shows dB levels above sensitivity and PWM values. The total time period of the PWM output is 8.32 ms. PWM output consists of 40 steps, so the minimum step size is 0.208 ms. dB above sensitivity PWM percentage (high period / total period) 10 47.5% 20 62.5% 30 77.5% A non-zero value defines the time that PWM output is active with the RSSI value of the last RF packet the device receives. After the set time when the device has not received RF packets, it sets the PWM output low (0 percent PWM) until the device receives another RF packet. It also sets PWM output low at power-up. A parameter value of 0xFF permanently enables PWM output and always reflects the value of the last received RF packet. The PWM output and Config input share the CONFIG /RSSI pin. When the device is powered, the Config pin is an input. During the power-up sequence, if RP is a non-zero value, the firmware configures the Config pin as an output and sets it low until the device receives the first RF packet. With a non-zero RP parameter, the CONFIG pin is an input for RP ms after power up. The PWM output and Config input share the CONFIG pin. When the device is powered, the Config pin is an input. During the power-up sequence, the device reads Config pin to determine whether to go to AT command mode. The Config pin is then configured as an output and set to low until the device receives the first RF packet. With a non-zero RP parameter, the CONFIG pin is an input for RP ms after power up. Binary command 0x22 (34 decimal) Parameter range 0 - 0xFF [x 100 ms] Default 0 (disabled) Bytes returned 1 RZ (DI Buffer Size) Reads the size of the DI buffer of the UART receiving device. Multiply the DI buffer size by 1.5 to determine the DO buffer size. Binary command 0x2C (44 decimal) XBee®-PRO 900HP/XSC RF Modules 228 Configuration and commands Diagnostic commands Parameter range Read-only Default N/A Bytes returned 1 Note This command is only supported on S3B modules. RS (RSSI) Returns the signal level of the last packet received. You can use this reading to determine range characteristics of devices under various conditions of noise and distance. Once you issues the command, the device returns a value between 0x6 and 0x36, where 0x36 represents a very strong signal level and 0x4 indicates a low signal level. Binary command 0x1C (28 decimal) Parameter range 0x06 – 0x36 [read-only] Default N/A Bytes returned 1 SH (Serial Number High) Reads the device's serial number high word. Binary command 0x25 (37 decimal) Parameter range 0x0 - 0xFFFF [read-only] Default N/A Bytes returned 2 SL (Serial Number Low) Reads the serial number low word of the device. XBee®-PRO 900HP/XSC RF Modules 229 Configuration and commands Diagnostic commands Binary command 0x26 (38 decimal) Parameter range 0 - 0xFFFF [read-only] Default N/A Bytes returned 2 TR (Transmission Failure Count) Records the number of retransmit failures. The device increments this number each time a packet is not acknowledged within the number of retransmits specified by the RR (Retries) Command. It therefore counts the number of packets that have not been successfully received and have been dropped. The TR Parameter is not non-volatile and resets to zero each time the device is reset. Binary command 0x1B (27 decimal) Parameter range 0 - 0xFFFF Default 0 Bytes returned 2 VR (Firmware Version - Short) Reads the firmware version on a device. Firmware versions contain four significant digits: A.B.C.D. If B = 2, the device is programmed for operation in Australia only. Binary command 0x14 (20 decimal) Parameter range [read-only]: 0 - 0xFFFF Default N/A Bytes returned 2 XBee®-PRO 900HP/XSC RF Modules 230 Configuration and commands Sleep commands Sleep commands The following commands are sleep commands. FH (Force Wakeup Initializer) Forces the device to send a wake-up initializer on the next transmission. Only use FH with cyclic sleep modes active on remote devices. You do not need to issue the WR (Write) command with FH. Binary command 0x0D (13 decimal) Parameter range N/A Default N/A Bytes returned N/A HT (Time before Wake-up Initializer) Sets or displays the time of inactivity (no serial or RF data is sent or received) before a transmitting (TX) RF device sends a wake-up initializer. The main purpose of this command is to prevent devices from sending the Long Header with every data packet. For more information on long headers, see LH (Wakeup Initializer Timer). For RX devices operating in Cyclic Sleep mode (SM = 4-8), set HT to be shorter than the ST command. The TX device sends a wake-up initializer, which instructs all receiving (RX) devices to remain awake to receive RF data. From the perspective of the RX device: after HT time elapses and the inactivity timeout (ST command) is met, the RX device goes into cyclic sleep. In cyclic sleep, the RX device wakes once per sleep interval (SM command) to check for a wake-up initializer. When it detects a wake-up initializer, the device stays awake to receive data. The wake-up initializer must be longer than the cyclic sleep interval to ensure that sleeping devices detect incoming data. When HT time elapses, the TX device knows it needs to send a wake-up initializer for all RX devices to remain awake and receive the next transmission. Binary command 0x03 (3 decimal) Parameter range 0 - 0xFFFF [x 100 ms] Default 0xFFFF (wake-up initializer will not be sent) Bytes returned 2 XBee®-PRO 900HP/XSC RF Modules 231 Configuration and commands Sleep commands LH (Wakeup Initializer Timer) Sets or displays the duration of time during which the wake-up initializer is sent. When receiving devices are in Cyclic Sleep Mode, they power-down after a period of inactivity as specified by the ST parameter and will periodically wake and listen for data transmissions. In order for the receiving devices to remain awake, they must detect ~35 ms of the wake-up initializer. You must use LH whenever a receiving device is operating in Cyclic Sleep mode. The wake-up initializer time must be longer than the cyclic sleep time, which is set by the SM (Sleep Mode) parameter. If the wake-up initializer time is less than the Cyclic Sleep interval, the connection is at risk of missing the wake-up initializer transmission. To view a diagram of the correct configuration, see SM (Sleep Mode). Binary command 0x0C (12 decimal) Parameter range 0 - 0xFF [x100 milliseconds] Default 1 Bytes returned 1 PW (Pin Wakeup) Enables or disables the sleep pin. Under normal operation, a device in Cyclic Sleep mode cycles from an active state to a low-power state at regular intervals until it is ready to receive data. If you set PW to 1, you can use the SLEEP pin (pin 26) to wake the device from Cyclic Sleep. When you de-assert (low) the SLEEP pin, the device is operational and will not go into Cyclic Sleep. Once you assert the SLEEP pin, the device remains active for the period of time specified by the ST parameter and returns to Cyclic Sleep mode if no data is ready to transmit. PW is only valid if Cyclic Sleep is enabled. Binary command 0x1D (29 decimal) Parameter range 0-1 Parameter Configuration 0 Disabled 1 Enabled Default 0 XBee®-PRO 900HP/XSC RF Modules 232 Configuration and commands Sleep commands Bytes returned 1 SM (Sleep Mode) Sets or displays the device's sleep mode settings, which configure the device to run in states that require minimal power consumption. By default, Sleep Mode is disabled and the device remains continually active. The SM command allows the device to run in a lower-power state and be configured in one of the eight settings. Cyclic Sleep settings wake the device after the amount of time designated by the SM command. If the device detects a wake-up initializer during the time it is awake, it synchronizes with the transmitter and starts receiving data after the wake-up initializer runs its duration. Otherwise, the device returns to Sleep Mode and continues to cycle in and out of inactivity until it detects the Wakeup Initializer. If a Cyclic Sleep setting is chosen, the ST, LH and HT parameters must also be set as described in Sleep mode. Binary command 0x01 Parameter range 0, 1 3 - 8 Parameter Description 0 Disabled 1 Pin Sleep 3 Cyclic 0.5 second sleep (RF module wakes every 0.5 seconds) 4 Cyclic 1 second sleep (RF module wakes every 1.0 seconds) 5 Cyclic 2 second sleep 6 Cyclic 4 second sleep 7 Cyclic 8 second sleep 8 Cyclic 16 second sleep Default 0 Bytes returned 1 ST (Wake Time) Sets or displays the amount of time (in tenths of seconds) that the device remains inactive before entering Sleep mode. For example, if you set ST to 0x64 (100 decimal), the device enters Sleep mode after 10 seconds of inactivity (no transmitting or receiving). XBee®-PRO 900HP/XSC RF Modules 233 Configuration and commands Sleep commands You can only use this command if you use SM to select Cyclic Sleep or Serial Port Sleep mode settings; see SM (Sleep Mode). Binary command 0x02 (2 decimal) Parameter range 0x10 – 0xFFFF [x 100 milliseconds] Default 0x64 (10 seconds) Bytes returned 2 XBee®-PRO 900HP/XSC RF Modules 234 Network configurations Network topologies Addressing Basic communications XBee®-PRO 900HP/XSC RF Modules 236 238 239 235 Network configurations Network topologies Network topologies The device supports three different network topologies: n Point-to-point n Point-to-multipoint n Peer-to-peer Point-to-point networks This following section provides the RF communication type and RF mode for point-to-point networks. Definition Point-to-point means that an RF data link exists between two devices. Sample network profile (Broadcast communications) Use default values for all devices. Sample network profile (Acknowledged communications) Note Assume default values for all parameters that are not in this list. These profiles do not reflect addressing implementations. 1. Use XCTU or an alternative terminal program to send the AM command. See AM (Auto-set MY) for details. 2. Set the destination address to 0xFFFF, send: DT FFFF Basic RF modes Streaming, Multi-Transmit, Repeater. Acknowledged RF mode Acknowledged mode. Point-to-multipoint networks This following section provides the RF communication type and RF mode for point-to-multipoint networks. Definition Point-to-multipoint refers to a network with RF data links between one base and multiple remotes. XBee®-PRO 900HP/XSC RF Modules 236 Network configurations Network topologies Sample network profile (Broadcast communications) Note Assume default values for all parameters that are not in this list. These profiles do not reflect addressing implementations. Base: 1. Send MY 0 to set the source address to 0x00. 2. Send DT FFFF to set the destination address to 0xFFFF. Remotes: 1. Use XCTU or another terminal program to send the AM command. See AM (Auto-set MY) for details. 2. Send DT 0 to set the destination address to 0x00. Sample network profile (Acknowledged communications) Note Assume the default value for all parameters that are not in this list. These profiles do not reflect addressing implementations. Base: 1. Send MY 0 to set the source address to 0x00. 2. Send DT FFFF to set the destination address to 0xFFFF. 3. Send RR 3 to set the number of retries to 3. Remotes: 1. Use XCTU or another terminal program to send the AM command. 2. Send DT FFFF to set the destination address to 0xFFFF. 3. Send RR 3 to set the number of retries to 3. Basic RF modes Streaming, Multi-Transmit, Repeater, and Polling. Acknowledged RF mode Acknowledged and Polling. Peer to peer networks This following section provides the RF communication type and RF mode for peer-to-peer networks. XBee®-PRO 900HP/XSC RF Modules 237 Network configurations Addressing Definition In Peer-to-peer networks, devices remain synchronized without the use of master/slave dependencies. Each device shares the roles of master and slave. Digi's peer-to-peer architecture features fast synch times (35 ms to synchronize devices) and fast cold start times (50 ms before transmission). Sample network profile (Broadcast communications) Note Assume default values for all parameters that are not in this list. These profiles do not reflect addressing implementations. Use default values for all devices. Sample network profile (Acknowledged communications) Note Assume default values for all parameters that are not in this list. These profiles do not reflect addressing implementations. All devices: 1. Send MY 0 to set the source address to 0x00. 2. Send DT FFFF to set the destination address to 0xFFFF. 3. Send RR 3 to set the number of retries to 3. Basic RF modes Streaming. Acknowledged RF mode Acknowledged. Addressing Each RF packet contains addressing information that the receiving devices use to filter incoming RF data. Receiving devices inspect the Preamble ID—HP parameter—Vendor Identification Number—ID parameter—and Destination Address—DT parameter—in each RF packet. A receiving device discards all data that does not pass through all three network security layers. The following image illustrates the addressing layers in the RF packet header. XBee®-PRO 900HP/XSC RF Modules 238 Network configurations Basic communications Address recognition Transmissions can be addressed to a specific device or group of devices using the DT (Destination Address) and MK (Address Mask) parameters. The transmitting device dictates whether the packet is intended for a specific device (local address) or multiple devices (global address) by comparing the packet’s DT parameter to its own MK parameter. Basic communications Basic communications includes two sub-types: n Broadcast. By default, the XBee-PRO 900HP RF Modules communicate through Broadcast communications and within a peer-to-peer network topology. When any device transmits, all other devices within range receive the data and pass it directly to their host device. n Addressed. If addressing parameters match, the device forwards the RF data it receives to the DOUT buffer; otherwise, it discards the RF data. When using Basic communications, the integrator handles any functions, such as acknowledgments, at the application layer. The Broadcast modes provide transparent communications, meaning that the RF link replaces a wired link. Streaming mode (default) Characteristics: Highest data throughput n Lowest latency and jitter n Reduced immunity to interference n Transmissions never acknowledged (ACK) by receiving module(s) Required parameter values (TX Module): RR (Retries) = 0 Related commands: Networking (DT, MK, MY), Serial Interfacing (PK, RB, RO, TT) Recommended use: Mode is most appropriate for data systems more sensitive to latency and/or jitter than to occasional packet loss. XBee®-PRO 900HP/XSC RF Modules 239 Network configurations Basic communications Streaming Mode data flow n Streaming Mode state diagram (TX Module) n Events and processes in this mode are common to all of the other RF Modes. Note When the device is streaming data, RB and RO parameters are only observed on the first packet. After transmission begins, the TX event continues uninterrupted until the DI buffer is empty or it reaches the streaming limit (TT Command). As with the first packet, the payload of each subsequent packet includes up to the maximum packet size (PK Command). The transmitting device specifies the streaming limit (TT Command) as the maximum number of bytes the transmitting device can send in one transmission event. After it reaches the TT parameter threshold, the transmitting module forces a random delay of 1 to RN delay slots (exactly 1 delay slot if RN = 0). The device sends subsequent packets without an RF initializer since receiving devices stay synchronized with the transmitting device for the duration of the transmission event (from preceding packet information). However, due to interference, some receiving devices may lose data (and synchronization to the transmitting device), particularly during long transmission events. Once the transmitting device sends all pending data or has reaches the TT limit, the transmission event ends. The transmitting device will not transmit again for exactly RN delay slots if the local (that is, the transmitting device’s) RN parameter is set to a non-zero value. The receiving devices will not transmit for a random number of delays between 0 and (RN-1) if the local (that is, the receiving module’s) RN parameter is set to a non-zero value. These delays are intended to lessen congestion following long bursts of packets from a single transmitting device, during which several receiving devices may have become ready to transmit. Repeater mode Characteristics n Self-organizing - No route configuration is necessary. n Self-healing / Fault-tolerant. n Low power consumption and Minimized interference. n Network throughput is determined by number of hops, not by number of repeaters. Multiple repeaters within range of source node count as one hop. n Supports “transparent” multi-drop mode or addressed data filtering mode. n Duplicate RF packets are automatically filtered out. n All packets propagate to every node in the network (filtering rules apply). n Broadcast communications - each packet comes out every node exactly once. n Addressed communications - all devices see every packet. Only the device with a matching address forwards it to the DO buffer (UART IN). n Devices transmit and forward data entering the network on any device through every repeater device until it reaches the ends of the network. n Each repeater repeats a packet only once. XBee®-PRO 900HP/XSC RF Modules 240 Network configurations Basic communications Constraints n Requires that each device have a unique MY (Source Address) parameter. n System must introduce just one packet at a time to the network for transmission (256 bytes max). n Each hop (H) decreases the network throughput by a factor of 1/(H+1). Additional repeaters add network redundancy without decreasing throughput. Required parameter values (TX module): MD = 3 or 4, MY = unique value. Send the AM (Auto-set MY) and WR (Write) commands to all devices in the network). Related commands: Networking (MD, DT, MY, AM), Serial Interfacing (RN, PK, RO, RB). Recommended use: Use in networks where intermediary nodes required to relay data to devices that are beyond the transmission range of the base device. Theory of operation Integrators can extend the effective range and reliability of a data radio system by forwarding traffic through one or more repeaters. Instead of using routing tables and path discovery to establish dynamic paths through a network, the repeater system uses a sophisticated algorithm to propagate each RF packet through the entire network. The network supports RF packets of up to 256 bytes. The repeater network can operate using broadcast or addressed communications for multi-drop networks and works well in many systems with no special configuration. When in Repeater Mode, the network repeats each message among all available nodes exactly one time. This mechanism eliminates the need for configuring specific routes. The network is selforganizing and self-healing so that the system is able to receive transmissions in the event of a device going down. Sample Repeater network topology: To summarize, the system sends and receives 64 bytes 5 times per second for a throughput of 320 bytes per second with no repeaters and 128 bytes per second with 2 repeaters. Generally, the network throughput decreases by a factor of 1/(R+1), with R representing the number of repeaters between the source and destination. Configuration instruction (Basic Broadcast communications) Assign each device a unique MY (source) address. The AM (Auto-set MY) command configures a unique source address based on device serial number. Enable Basic Broadcast Communications (DT = 0xFFFF) or Addressed Broadcast Communications (DT specifies a destination). Configure PK, RO and RB to ensure that RF packet aligns with protocol packet. (for example, PK=0x100, RB=0x100, RO depends on baud rate). Configure one or more repeaters in the system (MD = 3). XBee®-PRO 900HP/XSC RF Modules 241 Network configurations Basic communications Configure remote nodes as destinations (MD = 4). This ensures that the remote node waits for the repeater traffic to subside before transmitting a response. The preceding configuration instructions reflect configuration for a Basic Broadcast Repeater system. To configure a Basic Addressed Repeater system, use the DT (Destination Address) parameter to assign unique addresses to each device in the network. Algorithm details n Packet ID (PID) consists of the transmitting device MY address and packet serial number. n Devices ignore incoming packets with a PID already found in the PID buffer. n Each device maintains a PID buffer 8 deep of previously received packets (managed as FIFO). Packets may be shifted out the serial port and/or repeated depending on the DT parameter contained in the RF packet. The following table shows the DT (Destination Address) parameter truth. Address match Send out serial port? Repeat? Global Yes Yes Local Yes Yes None No Yes Repeat delay based on RSSI A transmitted packet may be received by more that one repeater at the same time. To reduce the probability of repeaters transmiting at the same time that may result in a collision and possible data loss, an algorithm allows a variable back-off prior to retransmission of the packet by a repeater. Devices that receive the packet with a stronger RF signal (RSSI) have the first opportunity to retransmit the packet. Use the RN (Delay Slots) parameter to configure the delay. n Set RN=0 (no delays) for small networks with few repeaters or repeaters that are not within range of each other. n Set RN=1 for systems with 2 to 5 repeaters that may be within range of each other. Use the following formula to compute the actual length of the delay: Delay (ms) = L * DS DS = (-41-RSSI)/(10*RN)+RandomInt(0,RN) Where: n L is the length of the transmitted packet in milliseconds. n DS is the number of delay slots to wait. n RSSI is the received signal strength in dBm. n RN is the value of the RN register. n RandomInt(A,B) is a function that returns a random integer from A to B-0. Response packet delay As a packet propagates through the repeater network, if any node receives the data and generates a quick response, the response must be delayed so it does not collide with subsequent retransmissions XBee®-PRO 900HP/XSC RF Modules 242 Network configurations Basic communications of the original packet. To reduce collisions, both repeater and end node radios in a repeater network delay transmission of data shifted in the serial port allowing any repeaters within range to complete their retransmissions. The time for this delay is computed by the followinformula: Maximum Delay (ms) = L * DS DS = (((41(-100))/10)*RN)+RN+1 Where: n L is the length of the transmitted packet in milliseconds. n DS is the number of delay slots to wait. n RSSI is the received signal strength in dBm. n RN is the value of the RN register. Use case - broadcast repeater network Consider devices R1 through R10, each communicating to a PLC using the ModBus protocol and spaced evenly in a line. All ten nodes are configured as ‘destinations & repeaters’ within the scope of Basic Broadcast Communications (MD=3, AM, DT=0xFFFF, PK=0x100, RO=0x03, RB=0x100, RN=1). The Base Host (BH) shifts payload that is destined for R10 to R1. R1 initializes RF communication and transmits payload to nodes R2 through R5 which are all within range of R1. Modules R2 through R5 receive the RF packet and retransmit the packet simultaneously; they also send data out the serial ports to the PLCs. The following table shows the commands used to configure repeater functions. Binary AT command command AT command name Range # Bytes returned Factory default AM 0x3A (58d) Auto-set MY - - - DT 0x00 (0d) Destination Address 0-0xFFFF 2 0 MD 0x3C (60d) RF Mode 3-4 1 0 MY 0x2A (42d) Source Address 0-0xFFFF 2 0xFFFF RN 0x19 (25d) Delay Slots 0-0xFF [slots] 1 0 WR 0x08 (8d) Write - - - Bandwidth considerations Using broadcast repeaters in a network reduces the overall network data throughput as each repeater buffers an entire packet before retransmitting it. For example: if the destination is within range of the transmitter and the packet is 32 bytes long, the transmission takes approximately 72 ms on a 9600 baud XSC device. If that same packet has to propagate through two repeaters, it takes 72 ms to arrive at the first repeater, another 72 ms to get to the second and a final 72 ms to get to the destination, for a total of 216 ms. Considering UART transfer times (~1ms/byte at 9600 baud), a server to send a 32 byte query and receive a 32 byte response is ~200 ms, which allows for 5 polls per second. With the two repeaters in the path, the same query/response sequence would take about 500 ms for 2 polls per second. XBee®-PRO 900HP/XSC RF Modules 243 Network configurations Basic communications Acknowledged mode Characteristics: Reliable delivery through positive acknowledgments for each packet Throughput, latency, and jitter vary depending on the quality of the channel and the strength of the signal. Recommended use: Acknowledge Mode configuration is appropriate when reliable delivery is required between modules. If messages are smaller than 256 bytes, use RB and RO commands to align RF packets with application packets. Required parameter values (TX device): RR (Retries) >= 1 Related commands: Networking (DT, MK, RR), Serial Interfacing (PK, RN, TT, RO, RB) The following table shows a sample network profile. Device Parameter settings (assume default values for parameter not listed) All ATRR A [set the number of retries to 0x0A] ATRN 5 [set the number of delay slots to 5] Acknowledged mode connection sequence After sending a packet while in Acknowledged Mode, the transmitting device listens for the ACK (acknowledgment). If it receives the ACK, it either sends a subsequent packet (if more transmit data is pending), or waits for exactly RN random delay slots before allowing another transmission (if no more data is pending for transmission). n If the transmitting device does not receive the ACK within the allotted time, it retransmits the packet with a new RF initializer following the ACK slot. There is no delay between the first ACK slot and the first retransmission. Subsequent retransmissions incur a delay of a random number of delay slots, between 0 and RN. n If RN is set to 0 on the transmitting device, there are never any back-off delays between retransmissions. During back-off delays, the transmitting device enters Idle Mode and may receive RF data. This can increase the back-off delay, as the radio cannot return to RF transmit (or retransmit) mode as long as it is receiving RF data. After receiving and acknowledging a packet, the receiving device moves to the next frequency and listens for either a retransmission or new data for a specific period of time. Even if the transmitting device indicates no more pending transmit data, it may have not received the previous ACK and may retransmit the packet (potentially with no delay after the ACK slot). In this case, the receiving device always detects the immediate retransmission, which holds off the communications channel and reduces collisions. Receiving devices acknowledge each retransmission they receive, but they only pass the first copy of a packet received out the UART. RB and RO parameters are not applied to subsequent packets. This means that once transmission has begun, it continues uninterrupted until the DI buffer is empty or reaches its streaming limit (TT). As with the first packet, the payload of each subsequent packet includes up to the maximum packet size (PK parameter). n The transmitting device checks for more pending data near the end of each packet. n The streaming limit (TT parameter) specifies the maximum number of bytes the transmitting device sends in one transmission event, which may consist of many packets and retries. If it reaches the TT parameter, the transmitting device forces a random delay of 1 to RN delay slots (exactly 1 delay slot if RN is zero). XBee®-PRO 900HP/XSC RF Modules 244 Network configurations n Basic communications The device counts each packet only once toward TT, no matter how many times the packet is retransmitted. Subsequent packets in acknowledged mode are similar to those in streaming mode, with the addition of an acknowledgment between each packet, and the possibility of retransmissions. The device sends subsequent packets without an RF initializer, because the receiving devices are already synchronized to the transmitting device from the preceding packets and they remain synchronized for the duration of the transmission event. Each packet retransmission includes an RF initializer. Once the transmitting device sends all pending data or reaches the TT limit, the acknowledged transmission event is completed. n The transmitting device does not transmit again for exactly RN delay slots, if the local RN parameter is set to a nonzero value. n The receiving device does not transmit for a random number of delay slots between 0 and (RN1), if the local RN parameter is set to a nonzero value. These delays can lessen congestion following long bursts of packets from a single transmitting device when several receiving devices may be ready to transmit. XBee®-PRO 900HP/XSC RF Modules 245 Network configurations XBee®-PRO 900HP/XSC RF Modules Basic communications 246 S3B hardware certifications Agency certifications - United States ISED (Innovation, Science and Economic Development Canada) Brazil ANATEL Mexico IFETEL IDA (Singapore) certification XBee®-PRO 900HP/XSC RF Modules 248 259 260 261 262 247 Agency certifications - United States United States (FCC) The XBee-PRO 900HP/XBee-PRO XSC RF Modules comply with Part 15 of the FCC rules and regulations. Compliance with the labeling requirements, FCC notices and antenna usage guidelines is required. To fulfill FCC certification requirements, the OEM must comply with the following regulations: n The system integrator must ensure that the text on the external label provided with this device is placed on the outside of the final product. n XBee/XBee-PRO RF modules may only be used with antennas that have been tested and approved for use with this module. For more information, see . OEM labeling requirements WARNING! As an Original Equipment Manufacturer (OEM) you must ensure that FCC labeling requirements are met. You must include a clearly visible label on the outside of the final product enclosure that displays the following content: XBee-PRO 900HP and XBee-PRO XSC Required FCC Label for OEM products containing the XBee-PRO 900HP/XBee-PRO XSC RF Module: Contains FCC ID: MCQ-XB900HP The enclosed device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions: (i. ) this device may not cause harmful interference and (ii. ) this device must accept any interference received, including interference that may cause undesired operation. FCC notices IMPORTANT: The XBee/XBee-PRO RF Module has been certified by the FCC for use with other products without any further certification (as per FCC section 2.1091). Modifications not expressly approved by Digi could void the user's authority to operate the equipment. IMPORTANT: OEMs must test final product to comply with unintentional radiators (FCC section 15.107 and 15.109) before declaring compliance of their final product to Part 15 of the FCC rules. IMPORTANT: The RF module has been certified for remote and base radio applications. If the module will be used for portable applications, the device must undergo SAR testing. This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may XBee®-PRO 900HP/XSC RF Modules 248 S3B hardware certifications Agency certifications - United States cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures: n Re-orient or relocate the receiving antenna. n Increase the separation between the equipment and receiver. n Connect equipment and receiver to outlets on different circuits. n Consult the dealer or an experienced radio/TV technician for help. Limited modular approval This is an RF module approved for Limited Modular use operating as a mobile transmitting device with respect to section 2.1091 and is limited to OEM installation for Mobile and Fixed applications only. During final installation, end-users are prohibited from access to any programming parameters. Professional installation adjustment is required for setting module power and antenna gain to meet EIRP compliance for high gain antenna(s). Final antenna installation and operating configurations of this transmitter including antenna gain and cable loss must not exceed the EIRP of the configuration used for calculating MPE. Grantee (Digi) must coordinate with OEM integrators to ensure the end-users and installers of products operating with the module are provided with operating instructions to satisfy RF exposure requirements. The FCC grant is valid only when the device is sold to OEM integrators. Integrators are instructed to ensure the end-user has no manual instructions to remove, adjust or install the device. FCC-approved antennas CAUTION! This device has been tested with Reverse Polarity SMA connectors with the antennas listed in the tables of this section. When integrated into OEM products, fixed antennas require installation preventing end-users from replacing them with non-approved antennas. Antennas not listed in the tables must be tested to comply with FCC Section15.203 (unique antenna connectors) and Section 15.247 (emissions). CAUTION! The FCC requires that all spread spectrum devices operating within the Unlicensed radio frequency bands must limit themselves to a maximum radiated power of 4 Watts EIRP. Failure to observe this limit is a violation of our warranty terms, and shall void the user’s authority to operate the equipment. This can be stated: RF power - cable loss + antenna gain