Digi XBee-PRO 900HP User Manual

Download

XBee®-PRO 900HP/XSC RF Modules

S3 and S3B

User Guide

Revision history—90002173

Revision Date Description

S October

2016

T May 2018 Added note on range estimation. Changed ICto ISED.

U July 2018 Added the 0x00, 0x80 and 0x89 frames for the 900HP.

V June

2019

W January

2020

Replaced the Programmable bootloader section with the Programmable XBee SDK section. Updated the indoor range spec. Corrected the SPand ST parameter default values.

Added FCC publication 996369 related information.

Added IFETEL 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.

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)

XBee®-PRO 900HP/XSC RF Modules

Trace (if possible)

Description of issue

Steps to reproduce

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

Include the document title and part number (XBee®-PRO 900HP/XSC RF Modules, 90002173 W) in the subject line of your email.

techcomm@digi.com

XBee®-PRO 900HP/XSC RF Modules

Contents

About the XBee-PRO 900HP RF Module

User guide structure 14

Technical specifications

Performance specifications 17 Power requirements 17 General specifications 18 Networking specifications 18 Regulatory conformity summary 18 Serial communication specifications 19

UART pin assignments 19

SPI pin assignments 19 GPIO specifications 19 Secondary processor specifications 20

Hardware

Mechanical drawings 23 Pin signals 24 Design notes 26

Power supply design 26

Board layout 26

Antenna performance 26

Recommended pin connections 27

Module operation for the programmable variant 28

Programmable XBee SDK 30

Configure the XBee-PRO 900HP RF Module

Software libraries 32 Configure the device using XCTU 32 Over-the-air firmware updates 32

Distribute the new application 32

Verify the new application 33

Install the application 33 XBee Multi Programmer 34

XBee®-PRO 900HP/XSC RF Modules

Operation

Basic operational design 36 Serial interface 36 UART data flow 36

Serial data 37 Configuration considerations 37

Select the serial port 37

Force UART operation 38

Select the SPI port 38 Serial port selection 39

Serial receive buffer 39

Serial transmit buffer 39 UART flow control 39

CTS flow control 39

RTS flow control 39

SPI operation

SPI communications 42 SPI implementation 42 SPI signals 43 Full duplex operation 44 Low power operation 44 SPI and API mode 45 SPI parameters 45

Modes

Serial modes 47

Transparent operating mode 47

API operating mode 47

Comparing Transparent and API modes 47 Modes of operation 49

Idle mode 49

Transmit mode 49

Receive mode 49

Command mode 49

Sleep mode 52

Sleep modes

About sleep modes 54

Asynchronous modes 54

Synchronous modes 54 Normal mode 54 Asynchronous pin sleep mode 55 Asynchronous cyclic sleep mode 55 Asynchronous cyclic sleep with pin wake up mode 55 Synchronous sleep support mode 55 Synchronous cyclic sleep mode 56 The sleep timer 56 Indirect messaging and polling 56

XBee®-PRO 900HP/XSC RF Modules

Indirect messaging 56

Polling 57 Sleeping routers 57

Sleep coordinator sleep modes in the DigiMesh network 57

Synchronization messages 58

Become a sleep coordinator 60

Select sleep parameters 62

Start a sleeping synchronous network 62

Add a new node to an existing network 63

Change sleep parameters 64

Rejoin nodes that lose sync 64 Diagnostics 65

Query sleep cycle 65

Sleep status 66

Missed sync messages command 66

Sleep status API messages 66

Networking methods

The MAC and PHY layers 68 64-bit addresses 68 Make a unicast transmission 69 Make a broadcast transmission 69 Delivery methods 69

Point to Point / Point to Multipoint (P2MP) 69

Repeater/directed broadcast 70

DigiMesh networking 71

AT commands

Special commands 77

AC (Apply Changes) 77

FR (Force Reset) 77

RE (Restore Defaults) 77

WR (Write) 77 MAC/PHY commands 78

AF (Available Frequencies) 78

CM (Channel Mask) 78

MF (Minimum Frequency Count) 79

HP (Preamble ID) 79

ID (Network ID) 80

MT(Broadcast Multi-Transmits) 80

PL (TX Power Level) 80

RR (Unicast Mac Retries) 81

ED (Energy Detect) 81 Diagnostic commands 81

BC (Bytes Transmitted) 81

DB (Last Packet RSSI) 81

ER (Received Error Count) 82

GD (Good Packets Received) 82

EA (MAC ACK Failure Count) 82

TR (Transmission Failure Count) 83

UA (MAC Unicast Transmission Count) 83

%H (MAC Unicast One Hop Time) 83

XBee®-PRO 900HP/XSC RF Modules

%8 (MAC Broadcast One Hop Time) 83 Network commands 84

CE (Node Messaging Options) 84

BH (Broadcast Hops) 84

NH (Network Hops) 84

NN (Network Delay Slots) 85

MR (Mesh Unicast Retries) 85

RN (Delay Slots) 85 Addressing commands 86

SH (Serial Number High) 86

SL (Serial Number Low) 86

DH (Destination Address High) 86

DL (Destination Address Low) 86

TO (Transmit Options) 87

NI (Node Identifier) 87

NT (Node Discover Time) 88

NO (Node Discovery Options) 88

CI (Cluster ID) 89

DE (Destination Endpoint) 89

SE (Source Endpoint) 89 Addressing discovery/configuration commands 89

AG (Aggregator Support) 89

DN (Discover Node) 90

ND (Network Discover) 90

FN (Find Neighbors) 91 Security commands 92

EE (Security Enable) 92

KY (AES Encryption Key) 92 Serial interfacing commands 92

BD (Baud Rate) 92

NB (Parity) 93

SB (Stop Bits) 93

RO (Packetization Timeout) 94

FT (Flow Control Threshold) 94

AP (API Mode) 94

AO (API Options) 95 I/O settings commands 95

CB (Commissioning Pushbutton) 95

D0 (DIO0/AD0) 95

D1 (DIO1/AD1) 96

D2 (DIO2/AD2) 96

D3 (DIO3/AD3) 97

D4 (DIO4) 97

D5 (DIO5/ASSOCIATED_INDICATOR) 98

D6 (DIO6/RTS) 98

D7 (DIO7/CTS) 99

D8 (DIO8/SLEEP_REQUEST) 99

D9 (DIO9/ON_SLEEP) 100

P0 (DIO10/RSSI/PWM0 Configuration) 100

P1 (DIO11/PWM1 Configuration) 101

P2 (DIO12 Configuration) 101

P3 (DIO13/DOUT) 102

P4 (DIO14/DIN) 102

PD (Pull Up/Down Direction) 102

PR (Pull-up/Down Resistor Enable) 102

XBee®-PRO 900HP/XSC RF Modules

M0 (PWM0 Duty Cycle) 103

M1 (PWM1 Duty Cycle) 103

LT (Associate LED Blink Time) 104

RP (RSSI PWM Timer) 104 I/O sampling commands 104

AV (Analog Voltage Reference) 104

IC (DIO Change Detection) 105

IF (Sleep Sample Rate) 105

IR (I/O Sample Rate) 106

IS (Force Sample) 106

TP (Board Temperature) 106

%V (Voltage Supply Monitoring) 107 Sleep commands 107

SM (Sleep Mode) 107

SO (Sleep Options) 107

SN (Number of Sleep Periods) 108

SP (Sleep Period) 108

ST (Wake Time) 109

WH (Wake Host Delay) 109 Diagnostic - sleep status/timing commands 109

SS (Sleep Status) 109

OS (Operating Sleep Time) 110

OW (Operating Wake Time) 110

MS (Missed Sync Messages) 111

SQ (Missed Sleep Sync Count) 111 Command mode options 111

CC (Command Character) 111

CN (Exit Command Mode) 111

CT (Command Mode Timeout) 112

GT (Guard Times) 112 Firmware commands 112

VL (Version Long) 112

VR (Firmware Version) 112

HV (Hardware Version) 112

HS (Hardware Series) 113

DD (Device Type Identifier) 113

NP (Maximum Packet Payload Bytes) 113

CK (Configuration CRC) 113

Operate in API mode

API mode overview 116 API frame format 116

API operation (AP parameter = 1) 116

API operation-with escaped characters (AP parameter = 2) 116 Data bytes that need to be escaped: 117

Length 117

Frame data 117 API serial exchanges 119

AT commands 119

Transmit and Receive RF data 120

Remote AT commands 120

Device Registration 121 Calculate and verify checksums 121

Example 121

XBee®-PRO 900HP/XSC RF Modules

Frame descriptions

64-bit Transmit Request - 0x00 124

Description 124

Format 124

Examples 125 Local AT Command Request - 0x08 125

Description 125

Format 126

Examples 126 Queue Local AT Command Request - 0x09 128

Description 128

Examples 128 Transmit Request - 0x10 130

Description 130

Transmit options bit field 131

Examples 131 Explicit Addressing Command Request - 0x11 133

Description 133

64-bit addressing 133

Reserved endpoints 133

Reserved cluster IDs 133

Reserved profile IDs 133

Transmit options bit field 135

Examples 135 Remote AT Command Request - 0x17 137

Description 137

Format 137

Examples 138 64-bit Receive Packet - 0x80 140

Description 140

Format 140

Examples 141 Local AT Command Response - 0x88 142

Description 142

Examples 143 Transmit Status - 0x89 144

Description 144

Delivery status codes 145

Examples 145 Modem Status - 0x8A 147

Description 147 Modem status codes 148

Examples 148 Extended Transmit Status - 0x8B 150

Description 150 Route Information - 0x8D 152

Description 152

Format 152

Examples 153 Aggregate Addressing Update- 0x8E 154

Description 154

Examples 154 Receive Packet - 0x90 156

Description 156

XBee®-PRO 900HP/XSC RF Modules

Examples 157 Explicit Receive Indicator - 0x91 158

Description 158

Examples 159 I/O Sample Indicator- 0x92 160

Description 160

Examples 161 Node Identification Indicator - 0x95 163

Description 163

Examples 165 Remote AT Command Response- 0x97 166

Description 166

Examples 167

Advanced application features

Remote configuration commands 170

Send a remote command 170

Apply changes on remote devices 170

Remote command responses 170 Network commissioning and diagnostics 170

Configure devices 170

Network link establishment and maintenance 171

Place devices 172

Device discovery 172

Link reliability 173

Commissioning pushbutton and associate LED 175 I/O line monitoring 178

I/O samples 178

Queried sampling 178

Periodic I/O sampling 181

Detect digital I/O changes 181

General Purpose Flash Memory

General Purpose Flash Memory 183 Access General Purpose Flash Memory 183 General Purpose Flash Memory commands 184

PLATFORM_INFO_REQUEST (0x00) 184

PLATFORM_INFO (0x80) 184

ERASE (0x01) 185

ERASE_RESPONSE (0x81) 185

WRITE (0x02) and ERASE_THEN_WRITE (0x03) 186

WRITE _RESPONSE (0x82) and ERASE_THEN_WRITE_RESPONSE (0x83) 187

READ (0x04) 187

READ_RESPONSE (0x84) 188

FIRMWARE_VERIFY (0x05) and FIRMWARE_VERIFY_AND_INSTALL(0x06) 188

FIRMWARE_VERIFY_RESPONSE (0x85) 189

FIRMWARE_VERIFY _AND_INSTALL_RESPONSE (0x86) 189 Work with flash memory 190

XBee®-PRO 900HP/XSC RF Modules

XSC firmware

XBee-PRO XSC RF Module overview 192 Pin signals 192 Electrical characteristics 193

Timing specifications 194

XBee-PRO XSC specifications

Performance specifications 198 Power requirements 198 Networking specifications 199 General specifications 199 Antenna options 199 Regulatory conformity summary 200

XBee-PRO XSC RF Module operation

Serial communications 202 UART-interfaced data flow 202 Serial data 202 Flow control 202

Data In (DIN) buffer and flow control 203

Data Out (DO) buffer and flow control 204 Operating modes 204

Idle mode 204

Transmit mode 205

Receive mode 205

Sleep mode 205

Command mode 208

Configuration and commands

Programming examples 213

Connect the device to a PC 213 Send binary commands 213

Example 213 Special commands 214

FR (Force Reset) 214

PL (TX Power Level) 214 Command mode options 214

AT (Guard Time After) 215

BT (Guard Time Before) 215

CC (Command Sequence Character) 215

CD (DO3 Configuration) 216

CN (Exit Command Mode) 216

CT (Command Mode Timeout) 217

E0 (Echo Off) 217

E1 (Echo On) 217

PC (Power-up to Transparent operating mode) 218 Networking and security commands 218

AM (Auto-set MY) 218

MD (RF Mode) 219

XBee®-PRO 900HP/XSC RF Modules

MY (Source Address) 219 Network commands 220

DT (Destination Address) 220

HP (Preamble ID) 220

HT (Time before Wake-up Initializer) 221

ID (Network ID) 221

MK (Address Mask) 221

RN (Delay Slots) 222

RR (Unicast Mac Retries) 222

SY (Time Before Initialization) 223

TT (Streaming Limit) 224 Serial interfacing commands 224

BD (Interface Data Rate) 224

CS (DO2 Configuration) 225

FL (Software Flow Control) 226

FT (Flow Control Threshold) 227

NB (Parity) 227

PK (Maximum RF Packet Size) 227

RB (Packetization Threshold) 228

RO (Packetization Timeout) 228

RT (DI2 Configuration) 229 Diagnostic commands 229

ER (Receive Count Error) 229

GD (Receive Good Count) 230

RE (Restore Defaults) 230

RP (RSSI PWM Timer) 231

RZ (DI Buffer Size) 231

RS (RSSI) 232

SH (Serial Number High) 232

SL (Serial Number Low) 232

TR (Transmission Failure Count) 233

VR (Firmware Version - Short) 233 Sleep commands 234

FH (Force Wakeup Initializer) 234

HT (Time before Wake-up Initializer) 234

LH (Wakeup Initializer Timer) 235

PW (Pin Wakeup) 235

SM (Sleep Mode) 236

ST (Wake Time) 236

Network configurations

Network topologies 239

Point-to-point networks 239

Point-to-multipoint networks 239

Peer to peer networks 240 Addressing 241

Address recognition 242 Basic communications 242

Streaming mode (default) 242

Repeater mode 243

Acknowledged mode 247

XBee®-PRO 900HP/XSC RF Modules

S3B hardware certifications

Agency certifications - United States 251

United States (FCC) 251

OEM labeling requirements 251

XBee-PRO 900HP and XBee-PRO XSC 251

FCC notices 251

Limited modular approval 252

Fixed base station and mobile applications 252

Portable applications and SAR testing 253

RF exposure statement 253

FCC-approved antennas (900 MHz) 254

Antennas approved for use with the XBee-PRO 900HP RF Module 254

FCC publication 996369 related information 260 ISED (Innovation, Science and Economic Development Canada) 262

Labeling requirements 262

Contains IC: 1846A-XB900HP 262

Transmitters for detachable antennas 262

Detachable antenna 262 Brazil ANATEL 263 Mexico IFETEL 264

OEM labeling requirements 264 IDA (Singapore) certification 264

Labeling 264

Frequency band 265

Antenna gain 265

Legacy S3B hardware certifications

Agency certifications - United States 267

United States (FCC) 267

OEM labeling requirements 267

XBee PRO S3 267

XBee PRO S3B 267

FCC notices 268

Limited modular approval 268

Fixed base station and mobile applications 269

Portable applications and SAR testing 269

RF exposure statement 269 ISED (Innovation, Science and Economic Development Canada) 270

Labeling requirements 270

Contains IC: 1846A-XB900HP 270

Contains IC: 1846A-XBEEXSC or Contains IC: 1846A-XBPS3B 270

Antenna options: 900 MHz antenna listings 271

Transmitters with detachable antennas 276

Detachable antenna 277 Brazil ANATEL 278

XBee®-PRO 900HP/XSC RF Modules

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

n One Analog Devices ADF7023 radio transceiver

n One RF power amplifier

n One NXP MC9S08QE32

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:

32G230F128 microcontroller

microcontroller, only in the programmable version of the XBee

XBee®-PRO 900HP/XSC RF Modules

About the XBee-PRO 900HP RF Module User guide structure

PreDigi Part Numbers FCC ID

Hardware Platform

installed

Firmware

Firmware Available

Regulatory Information

XBP09-XC… MCQ-

XBEEXSC

XBP9B-XC*T-001 (revision G and earlier)

MCQ-

XBPS3B XBP9B-XC*T-002 (revision G and earlier) XBP9B-XC*T-021 (revision F and earlier) XBP9B-XC*T-022 (revision F and earlier)

XBP9B-XC*T-001 (revision H and later)

MCQ-

XB900HP 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...

XBP9B-D… MCQ-

XB900HP

XSC XSC Legacy S3B

hardware certifications

S3B XSC XSC Legacy S3B

hardware certifications

S3B XSC XSC /

900HP

S3B 900HP XSC /

900HP

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

Technical specifications

Performance specifications 17 Power requirements 17 General specifications 18 Networking specifications 18 Regulatory conformity summary 18 Serial communication specifications 19 GPIO specifications 19 Secondary processor specifications 20

XBee®-PRO 900HP/XSC RF Modules

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

Ideal RF line-of-sight range

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

Serial interface data rate (software selectable)

Receiver sensitivity (typical)

Power requirements

The following table describes the power requirements for the XBee-PRO 900HP RF Module.

Value

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)

asynchronous receiver/transmitter (UART), baud rate stability of <1%

9600-230400 baud

-101 dBm, high data rate

-110 dBm, low data rate

Specification Value

Supply voltage 2.1 to 3.6 VDC

Transmit current PL = 4: 215 mA typical, (290 mA max)

Idle/receive current 29 mA typical at 3.3 V (35 mA max)

Sleep current 2.5 µA (typical)

Supply voltages of less than 3.0 V may reduce performance. Output power and receiver sensitivity may

degrade.

XBee®-PRO 900HP/XSC RF Modules

PL = 3: 160 mA typical PL = 2: 120 mA typical PL = 1: 95 mA typical PL = 0: 60 mA typical

Technical specifications General specifications

General specifications

The following table describes the general specifications for the devices.

Specification Value

Operating frequency band

Dimensions 3.29 cm x 2.44 cm x 0.546 cm (1.297" x 0.962" x 0.215)

Weight 5 to 8 grams, depending on the antenna option

Operating temperature -40 ºC to 85 º C (industrial)

Antenna options Integrated wire, U. FL RF connector, reverse-polarity SMA

Digital I/O Fifteen (15) I/O lines,

902 to 928 MHz (software selectable channels)

Dimensions do not include connector/antenna or pin lengths

connector

Analog-to-digital converter (ADC)

Four (4)10-bit analog inputs

Networking specifications

The following table provides the networking specifications for the device.

Specification Value

Supported network topologies Mesh, point-to-point, point-to-multipoint, peer-to-peer

Number of channels, user selectable channels

Addressing options Personal Area Network identifier (PAN ID), Preamble ID, and

Encryption 128 bit Advanced Encryption Standard (AES)

64 channels available

64-bit addresses

Regulatory conformity summary

This table describes the agency approvals for the devices.

Country Approval

United States (FCC Part 15.247) MCQ-XB900HP

Innovation, Science and Economic Development Canada (ISED)

Supply voltages of less than 3.0 V may reduce performance. Output power and receiver sensitivity may

degrade.

XBee®-PRO 900HP/XSC RF Modules

1846A-XB900HP

Technical specifications Serial communication specifications

Country Approval

Australia RCM

Brazil ANATEL 3727-12-1209

Singapore License No. DA105737 (XB900HP only)

Mexico IFETEL (XB900HP listed in Mexico

IFETEL)

RoHS2 Compliant

Serial communication specifications

The XBee-PRO 900HP RF Module supports both Universal Asynchronous Receiver / Transmitter (UART) and Serial Peripheral Interface (SPI)serial connections.

UART pin assignments

UART pins Device pin number

DOUT 2

DIN / CONFIG 3

CTS / DIO7 12

RTS / DIO6 16

SPI pin assignments

SPI pins Device pin number

SPI_SCLK / DIO18 18

SPI_SSEL / DIO17 17

SPI_MOSI / DIO16 11

SPI_MISO / DIO15 4

SPI_ATTN / DIO1 19

GPIO specifications

XBee devices have 15 General Purpose Input/Output (GPIO) ports available. The precise list depends on the device configuration as some devices use the GPIO pins for purposes such as serial communication. The following table shows the electrical specifications for the GPIO pins.

XBee®-PRO 900HP/XSC RF Modules

Technical specifications Secondary processor specifications

GPIO electrical specification Value

Voltage - supply 2.1 - 3.6 V (3.0 V or higher required for optimal performance)

Low Schmitt switching threshold 0.3 x V

High Schmitt switching threshold 0.7 x V

Input pull-up resistor value 40 kΩ

Input pull-down resistor value 40 kΩ

Output voltage for logic 0 0.05 x V

Output voltage for logic 1 0.95 x V

Output source current 2 mA

Output sink current 2 mA

Total output current (for GPIO pins) 48 mA

Note For information about Mexico IFETEL, see Mexico IFETEL. Only the XBee-PRO 900HP devices

listed are approved by IFETEL.

Secondary processor specifications

If the device has the programmable secondary processor, add the values from the following tables to the specifications listed in the Power requirements specifications. For more information about transmit, receive, and sleep currents, see Power requirements.

For example, if the secondary processor runs at 20 MHz and the primary processor is in receive mode, then the new current value is:

= Ir2+ Irx= 14 mA + 9 mA = 23 mA

total

where Ir2is the runtime current of the secondary processor and Irxis the receive current of the primary processor.

Optional secondary processor specification

Runtime current for 32 k running at 20 MHz +14 mA

Runtime current for 32 k running at 1 MHz +1 mA

Sleep current +0.5µ A typical

For additional specifications see the NXP datasheet and manual

Voltage requirement for secondary processor to operate at maximum clock frequency

XBee®-PRO 900HP/XSC RF Modules

Add these numbers to power requirement specifications (add to RX, TX, and sleep currents depending on mode of operation)

MC9S08QE32

2.4 to 3.6 VDC

Technical specifications Secondary processor specifications

Add these numbers to power requirement specifications (add to RX, TX, and sleep currents

Optional secondary processor specification

Minimum reset pulse for programmable variant 100 nS

Minimum reset pulse to radio 50 nS

Voltage reference (VREF) range 1.8 VDC to VCC

depending on mode of operation)

XBee®-PRO 900HP/XSC RF Modules

Hardware

Mechanical drawings 23 Pin signals 24 Design notes 26

XBee®-PRO 900HP/XSC RF Modules

Hardware Mechanical drawings

Mechanical drawings

The following figures show the mechanical drawings for the XBee-PRO 900HP RF Module. The drawings do not show antenna options.

XBee®-PRO 900HP/XSC RF Modules

Hardware Pin signals

Pin signals

The following table shows the pin signals and their descriptions. The table specifies signal direction with respect to the device. For more information on pin connections, see Design notes.

Pin # Name Direction

1 VCC Power supply

XBee®-PRO 900HP/XSC RF Modules

Default state Description

Hardware Pin signals

Default

Pin # Name Direction

2 DOUT/DIO13 Both Output GPIO/UART data out

state Description

3 DIN/CONFIG

/DIO14

4 DIO12/SPI_MISO Both Output GPIO/SPI slave out

5 RESET Input Device reset. Drive low to reset the device.

6 DIO10/PWM0 Both GPIO/RX signal strength indicator

7 DIO11/PWM1 Both GPIO/pulse width modulator

8 Reserved Disabled Do not connect

9 DTR/SLEEP_

RQ/DIO8

10 GND Ground

11 DIO4/SPI_MOSI Both GPIO/SPI slave in

12 CTS/DIO7 Both Output GPIO/clear-to-send flow control

13 ON_SLEEP /DIO9 Output Output GPIO/module status indicator

Both Input GPIO/UART data in

This is also an output with an open drain configuration with an internal 20 kΩ pull-up (never drive to logic high, as the device may be driving it low). The minimum pulse width is 1 mS.

Both Input GPIO/pin sleep control line (DTR on the

development board)

14 VREF Input Internally used for the programmable

secondary processor. For compatibility with other XBee devices, we recommend connecting this pin to the voltage reference if you desire analog sampling. Otherwise, connect to GND.

15 Associate/DIO5 Both Output GPIO/associate indicator

16 RTS /DIO6 Both Input GPIO/request-to-send flow control

17 AD3/DIO3/SPI_

SSEL

18 AD2/DIO2/SPI_

CLK

19 AD1/DIO1/SPI_

ATTN

20 AD0/DIO0 Both GPIO/analog input

Both GPIO/analog input/SPI slave select

Both GPIO/analog input /SPI clock

Both GPIO/analog input /SPI attention

XBee®-PRO 900HP/XSC RF Modules

Hardware Design notes

Design notes

The XBee modules do not require any external circuitry or specific connections for proper operation. However, there are some general design guidelines that we recommend to build and troubleshoot a robust design.

Power supply design

A poor power supply can lead to poor radio performance, especially if you do not keep the supply voltage within tolerance or if the noise is excessive. To help reduce noise, place a 1.0 µF and 47 pF capacitor as near as possible to pin 1 on the PCB. If you are using a switching regulator for the power supply, switch the frequencies above 500 kHz. Limit the power supply ripple to a maximum 50 mV peak to peak.

For designs using the programmable modules, we recommend an additional 10 µF decoupling cap near pin 1 of the device. The nearest proximity to pin 1 of the three caps should be in the following order:

1. 47 pf

2. 1 µF

3. 10 µF

Board layout

We design XBee modules to be self-sufficient and have minimal sensitivity to nearby processors, crystals or other printed circuit board (PCB) components. Keep power and ground traces thicker than signal traces and make sure that they are able to comfortably support the maximum current specifications. There are no other special PCB design considerations to integrate XBee modules, with the exception of antennas.

Antenna performance

Antenna location is important for optimal performance. The following suggestions help you achieve optimal antenna performance. Point the antenna up vertically (upright). Antennas radiate and receive the best signal perpendicular to the direction they point, so a vertical antenna's omnidirectional radiation pattern is strongest across the horizon.

Position the antennas away from metal objects whenever possible. Metal objects between the transmitter and receiver can block the radiation path or reduce the transmission distance. Objects that are often overlooked include:

n Metal poles

n Metal studs

n Structure beams

n Concrete, which is usually reinforced with metal rods

If you place the device inside a metal enclosure, use an external antenna. Common objects that have metal enclosures include:

n Vehicles

n Elevators

n Ventilation ducts

n Refrigerators

XBee®-PRO 900HP/XSC RF Modules

Hardware Design notes

n Microwave ovens

n Batteries

n Tall electrolytic capacitors

Use the following additional guidelines for optimal antenna performance:

n Do not place XBee modules with the chip antenna inside a metal enclosure.

n Do not place any ground planes or metal objects above or below the antenna.

n For the best results, mount the device at the edge of the host PCB. Ensure that the ground,

power, and signal planes are vacant immediately below the antenna section.

Recommended pin connections

The only required pin connections for two-way communication are VCC, GND, DOUT and DIN. To support serial firmware updates, you must connect VCC, GND, DOUT, DIN, RTS, and DTR.

Do not connect any pins that are not in use. Use the PR and PD commands to pull all inputs on the radio high with internal pull-up resistors. Unused outputs do not require any specific treatment.

For applications that need to ensure the lowest sleep current, never leave unconnected inputs floating. Use internal or external pull-up or pull-down resistors, or set the unused I/O lines to outputs.

You can connect other pins to external circuitry for convenience of operation including the Associate LED pin (pin 15) and the Commissioning pin (pin 20). The Associate LED pin flashes differently depending on the state of the module, and a pushbutton attached to pin 20 can enable various deployment and troubleshooting functions without you sending UART commands. For more information, see Commissioning pushbutton and associate LED.

Only the programmable versions of these devices use the VREF pin (pin 14). For compatibility with other XBee modules, we recommend connecting this pin to a voltage reference if you want to enable analog sampling. Otherwise, connect to GND.

XBee®-PRO 900HP/XSC RF Modules

XBee®-PRO 900HP/XSC RF Modules 28

Hardware Design notes

Module operation for the programmable variant

The modules with the programmable option have a secondary processor with 32k of flash and 2k of RAM. This allows module integrators to put custom code on the XBee module to fit their own unique needs. The DIN, DOUT, RTS, CTS, and RESET lines are intercepted by the secondary processor to allow it to be in control of the data transmitted and received. All other lines are in parallel and can be controlled by either the internal microcontroller or the MC9SO8QE micro; see the block diagram in Operation for details. The internal microcontroller by default has control of certain lines. The internal microcontroller can release these lines by sending the proper command(s) to disable the desired DIO line(s). For more information about commands, see

AT commands.

For the secondary processor to sample with ADCs, the XBee 14 (VREF) must be connected to a reference voltage.

Digi provides a bootloader that can take care of programming the processor over-the-air or through the serial interface. This means that over-the-air updates can be supported through an XMODEM protocol. The processor can also be programmed and debugged through a one wire interface BKGD (Pin

8).

XBee®-PRO 900HP/XSC RF Modules 29

Hardware Design notes

Programmable XBee SDK

The XBee Programmable module is equipped with a NXP MC9S08QE32 application processor. This application processor comes with a supplied bootloader. To interface your application code running on this processor to the XBee Programmable module's supplied bootloader, use the Programmable XBee SDK.

To use the SDK, you must also download CodeWarrior. The download links are:

n CodeWarrior IDE: http://ftp1.digi.com/support/sampleapplications/40003004_B.exe

n Programmable XBee SDK: http://ftp1.digi.com/support/sampleapplications/40003003_D.exe

If these revisions change, search for the part number on Digi’s website. For example, search for

40003003.

Install the IDE first, and then install the SDK.

The documentation for the Programmable XBee SDK is built into the SDK, so the Getting Started guide appears when you open CodeWarrior.

XBee®-PRO 900HP/XSC RF Modules

Configure the XBee-PRO 900HP RF Module

Software libraries 32 Configure the device using XCTU 32 Over-the-air firmware updates 32 XBee Multi Programmer 34

XBee®-PRO 900HP/XSC RF Modules

Configure the XBee-PRO 900HP RF Module Software libraries

Software libraries

One way to communicate with the XBee-PRO 900HP RF Module is by using a software library. The libraries available for use with the XBee-PRO 900HP RF Module include:

n XBee Java library

n XBee Python library

The XBee Java Library is a Java API. The package includes the XBee library, its source code and a collection of samples that help you develop Java applications to communicate with your XBee devices.

The XBee Python Library is a Python API that dramatically reduces the time to market of XBee projects developed in Python and facilitates the development of these types of applications, making it an easy process.

Configure the device using XCTU

XBee Configuration and Test Utility (XCTU) is a multi-platform program that enables users to interact with Digi radio frequency (RF) devices through a graphical interface. The application includes built-in tools that make it easy to set up, configure, and test Digi RF devices.

For instructions on downloading and using XCTU, see the XCTU User Guide.

Click Discover devices and follow the instructions. XCTU should discover the connected XBee-PRO 900HP RF Modules using the provided settings.

Click Add selected devices.The devices appear in the Radio Modules list. You can click a module to view and configure its individual settings. For more information on these items, see AT commands.

Over-the-air firmware updates

There are two methods of updating the firmware on the device. You can update the firmware locally with XCTU using the device's serial port interface. You can also update firmware using the device's RF interface (over-the-air updating.)

The over-the-air firmware update method provided is a robust and versatile technique that you can tailor to many different networks and applications. OTAupdates are reliable and minimize disruption of normal network operations.

In the following sections, we refer to the node that will be updated as the target node. We refer to the node providing the update information as the source node. In most applications the source node is locally attached to a computer running update software.

There are three phases of the over-the-air update process:

1. Distribute the new application

2. Verify the new application

3. Install the application

Distribute the new application

The first phase of performing an over-the-air update on a device is transferring the new firmware file to the target node. Load the new firmware image in the target node's GPM prior to installation. XBeePRO 900HP RF Modules use an encrypted binary (.ebin) file for both serial and over-the-air firmware updates. These firmware files are available on the Digi Support website and via XCTU.

Send the contents of the .ebin file to the target device using general purpose memory WRITE commands. Erase the entire GPM prior to beginning an upload of an .ebin file. The contents of the .ebin

XBee®-PRO 900HP/XSC RF Modules

Configure the XBee-PRO 900HP RF Module Over-the-air firmware updates

file should be stored in order in the appropriate GPM memory blocks. The number of bytes that are sent in an individual GPM WRITE frame is flexible and can be catered to the user application.

Example

The example firmware version has an .ebin file of 55,141 bytes in length. Based on network traffic, we determine that sending a 128 byte packet every 30 seconds minimizes network disruption. For this reason, you would divide and address the .ebin as follows:

GPM_BLOCK_NUM GPM_START_INDEX GPM_NUM_BYTES .ebin bytes

0 0 128 0 to 127

0 128 128 128 to 255

0 256 128 256 to 383

0 384 128 384 to 511

1 0 128 512 to 639

1 128 128 640 to 767

- - - -

107 0 54784 to 54911

107 128 54912 to 55039

107 256 101 55040 to 55140

Verify the new application

For an uploaded application to function correctly, every single byte from the .ebin file must be properly transferred to the GPM. To guarantee that this is the case, GPM VERIFY functions exist to ensure that all bytes are properly in place. The FIRMWARE_VERIFY function reports whether or not the uploaded data is valid. The FIRMWARE_VERIFY_AND_INSTALL command reports if the uploaded data is invalid. If the data is valid, it begins installing the application. No installation takes place on invalid data.

Install the application

When the entire .ebin file is uploaded to the GPM of the target node, you can issue a FIRMWARE_ VERIFY_AND_INSTALL command. Once the target receives the command it verifies the .ebin file loaded in the GPM. If it is valid, then the device installs the new firmware. This installation process can take up to eight seconds. During the installation the device is unresponsive to both serial and RF communication. To complete the installation, the target module resets. AT parameter settings which have not been written to flash using the WR command will be lost.

Important considerations

Write all parameters with the WR command before performing a firmware update. Packet routing information is also lost after a reset. Route discoveries are necessary for DigiMesh unicasts involving the updated node as a source, destination, or intermediate node.

XBee®-PRO 900HP/XSC RF Modules

Configure the XBee-PRO 900HP RF Module XBee Multi Programmer

Because explicit API Tx frames can be addressed to a local node (accessible via the SPI or UART) or a remote node (accessible over the RF port) the same process can be used to update firmware on a device in either case.

XBee Multi Programmer

The XBee Multi Programmer is a combination of hardware and software that enables partners and distributors to program multiple Digi Radio frequency (RF) devices simultaneously. It provides a fast and easy way to prepare devices for distribution or large networks deployment.

The XBee Multi Programmer board is an enclosed hardware component that allows you to program up to six RF modules thanks to its six external XBee sockets. The XBee Multi Programmer application communicates with the boards and allows you to set up and execute programming sessions. Some of the features include:

n Each XBee Multi Programmer board allows you to program up to six devices simultaneously.

Connect more boards to increase the programming concurrency.

n Different board variants cover all the XBee form factors to program almost any Digi RF device.

Download the XBee Multi Programmer application from:digi.com/support/productdetail?pid=5641

See the XBee Multi Programmer User Guide for more information.

XBee®-PRO 900HP/XSC RF Modules

Operation

Basic operational design 36 Serial interface 36 UART data flow 36 Configuration considerations 37 Serial port selection 39 UART flow control 39

XBee®-PRO 900HP/XSC RF Modules

Operation Basic operational design

Basic operational design

The XBee-PRO 900HP RF ModuleRF Module uses a multi-layered firmware base to order the flow of data, dependent on the hardware and software configuration that you choose. The following graphic shows a configuration block diagram, with the host serial interface as the physical starting point and the antenna as the physical endpoint for the transferred data. As long as one block can touch another block, the two interfaces can interact. For example, if the device is using SPI mode, Transparent Mode is not available.

The command handler is the code that processes commands from AT Command Mode or Application Programming Interface (API) Mode (see AT commands). The command handler also processes commands from remote radios (see Remote AT commands).

Serial interface

The XBee-PRO 900HP RF Module interfaces to a host device through a serial port. The device can communicate through its serial port with the following:

n Logic and voltage compatible universal asynchronous receiver/transmitter (UART).

n Level translator to any serial device, for example, through an RS-232 or USB interface board.

n SPI, as described in SPI communications.

UART data flow

Devices that have a UART interface connect directly to the pins of the XBee-PRO 900HP RF Module as shown in the following figure. The figure shows system data flow in a UART-interfaced environment. Low-asserted signals have a horizontal line over the signal name.

XBee®-PRO 900HP/XSC RF Modules

Operation Configuration considerations

Serial data

A device sends data to the XBee-PRO 900HP RF Module's UART through pin 3 DIN as an asynchronous serial signal. When the device is not transmitting data, the signals should idle high.

For serial communication to occur, you must configure the UART of both devices (the microcontroller and the XBee-PRO 900HP RF Module) with compatible settings for the baud rate, parity, start bits, stop bits, and data bits.

Each data byte consists of a start bit (low), 8 data bits (least significant bit first) and a stop bit (high). The following diagram illustrates the serial bit pattern of data passing through the device. The diagram shows UART data packet 0x1F (decimal number 31) as transmitted through the device.

You can configure the UART baud rate, parity, and stop bits settings on the device with the BD, NB, and SB commands respectively. For more information, see Serial interfacing commands.

Configuration considerations

The configuration considerations are:

n How do you select the serial port? For example, should you use the UART or the SPI port?

n If you use the SPI port, what data format should you use in order to avoid processing invalid

characters while transmitting?

n What SPI options do you need to configure?

Select the serial port

Both the UART and SPI ports are configured for serial port operation by default.

XBee®-PRO 900HP/XSC RF Modules

Operation Configuration considerations

n If both interfaces are configured, serial data goes out the UART until the SPI_SSEL signal is

asserted. After that, all serial communications operate on the SPI interface.

n If you enable only the UART, then the device only uses the UART and ignores SPI_SSEL. If you

only enable the SPI, then the device uses only the SPI.

n If you do not enable either serial port, the device does not support serial operations and all

communications must occur over-the-air. The device discards all data that would normally go to the serial port.

Force UART operation

If you configure a device with only the SPI enabled and no SPI master is available to access the SPI slave port, you can recover the device to UART operation by holding DIN / CONFIG low at reset time. DIN/CONFIG forces a default configuration on the UART at 9600 baud and brings up the device in Command mode on the UART port. You can then send the appropriate commands to the device to configure it for UART operation. If you write those parameters, the device comes up with the UART enabled on the next reset.

Select the SPI port

To force SPI mode, hold DOUT/DIO13 (pin 2) low while resetting the device until SPI_ATTN asserts. This causes the device to disable the UART and go straight into SPI communication mode. Once configuration is complete, the device queues a modem status frame to the SPI port, which causes the SPI_ATTN line to assert. The host can use this to determine that the SPI port is configured properly. This method forces the configuration to provide full SPI support for the following parameters:

n D1 (This parameter will only be changed if it is at a default of zero when the method is

invoked.)

n D2

n D3

n D4

n P2

As long as the host does not issue a WR command, these configuration values revert to previous values after a power-on reset. If the host issues a WR command while in SPI mode, these same parameters are written to flash. After a reset, parameters that were forced and then written to flash become the mode of operation.

If the UART is disabled and the SPI is enabled in the written configuration, then the device comes up in SPI mode without forcing it by holding DOUT low. If both the UART and the SPI are enabled at the time of reset, then output goes to the UART until the host sends the first input. If that first input comes on the SPI port, then all subsequent output goes to the SPI port and the UART is disabled. If the first input comes on the UART, then all subsequent output goes to the UART and the SPI is disabled.

When the master asserts the slave select (SPI_SSEL ) signal, SPI transmit data is driven to the output pin SPI_MISO, and SPI data is received from the input pin SPI_MOSI. The SPI_SSEL pin has to be asserted to enable the transmit serializer to drive data to the output signal SPI_MISO. A rising edge on SPI_SSEL causes the SPI_MISO line to be tri-stated such that another slave device can drive it, if so desired.

If the output buffer is empty, the SPI serializer transmits the last valid bit repeatedly, which may be either high or low. Otherwise, the device formats all output in API mode 1 format, as described in

Operate in API mode. The attached host is expected to ignore all data that is not part of a formatted

API frame.

XBee®-PRO 900HP/XSC RF Modules

Operation Serial port selection

Serial port selection

To enable the UART port, configure DIN and DOUT (P3 and P4 parameters) as peripherals. To enable the SPI port, enable SPI_MISO, SPI_MOSI, SPI_SSEL , and SPI_CLK (P5 through P9) as peripherals. If you enable both ports then output goes to the UART until the first input on SPI.

When both the UART and SPI ports are enabled on power-up, all serial data goes out the UART. As soon as input occurs on either port, that port is selected as the active port and no input or output is allowed on the other port until the next device reset.

If you change the configuration so that only one port is configured, then that port is the only one enabled or used. If the parameters are written with only one port enabled, then the port that is not enabled is not used even temporarily after the next reset.

If both ports are disabled on reset, the device uses the UART in spite of the wrong configuration so that at least one serial port is operational.

Serial receive buffer

When serial data enters the device through the DIN pin (or the MOSI pin), it stores the data in the serial receive buffer until the device can process it. Under certain conditions, the device may not be able to process data in the serial receive buffer immediately. If large amounts of serial data are sent to the device such that the serial receive buffer would overflow, then it discards new data. If the UART is in use, you can avoid this by the host side honoring CTS flow control.

Serial transmit buffer

When the device receives RF data, it moves the data into the serial transmit buffer and sends it out the UART or SPI port. If the serial transmit buffer becomes full and the system buffers are also full, then it drops the entire RF data packet. Whenever the device receives data faster than it can process and transmit the data out the serial port, there is a potential of dropping data.

UART flow control

You can use the RTS and CTS pins to provide RTS and/or CTS flow control. CTS flow control provides an indication to the host to stop sending serial data to the device. RTS flow control allows the host to signal the device to not send data in the serial transmit buffer out the UART. To enable RTS/CTS flow control, use the D6 and D7 commands.

Note Serial port flow control is not possible when using the SPI port.

CTS flow control

If you enable CTS flow control (D7 command), when the serial receive buffer is 17 bytes away from being full, the device de-asserts CTS (sets it high) to signal to the host device to stop sending serial data. The device reasserts CTS after the serial receive buffer has 34 bytes of space. See FT (Flow

Control Threshold) for the buffer size.

In either case, CTS is not re-asserted until the serial receive buffer has FT-17 or less bytes in use.

RTS flow control

If you send the D6 command to enable RTS flow control, the device does not send data in the serial transmit buffer out the DOUT pin as long as RTS is de-asserted (set high). Do not de-assert RTS for long periods of time or the serial transmit buffer will fill. If the device receives an RF data packet and

XBee®-PRO 900HP/XSC RF Modules

Operation UART flow control

the serial transmit buffer does not have enough space for all of the data bytes, it discards the entire RF data packet.

The UART Data Present Indicator is a useful feature when using RTS flow control. When enabled, the DIO1 line asserts (low asserted) when UART data is queued to be transmitted from the module. For more information, see D1 (DIO1/AD1).

If the device sends data out the UART when RTS is de-asserted (set high) the device could send up to five characters out the UART port after RTS is de-asserted.

XBee®-PRO 900HP/XSC RF Modules

SPI operation

SPI communications 42 SPI implementation 42 SPI signals 43 Full duplex operation 44 Low power operation 44 SPI and API mode 45 SPI parameters 45

XBee®-PRO 900HP/XSC RF Modules

SPI operation SPI communications

SPI communications

The XBee-PRO 900HP RF Module supports SPI communications in slave mode. Slave mode receives the clock signal and data from the master and returns data to the master. The following table shows the signals that the SPI port uses on the device.

Signal Function

SPI_MOSI (MasterOut,SlaveIn)

SPI_MISO(Master In,Slave Out)

SPI_SCLK(SerialClock)

SPI_SSEL (SlaveSelect)

SPI_ATTN (Attention) Alerts the master that slave has data queued to send. The XBee-PRO

In this mode:

n SPI clock rates up to 3.5 MHz are possible.

n Data is most significant bit (MSB) first.

n Frame Format mode 0 is used. This means CPOL= 0 (idle clock is low) and CPHA = 0 (data is

sampled on the clock’s leading edge).

n The SPI port only supports API Mode (AP = 1).

The following diagram shows the frame format mode 0 for SPI communications.

Inputs serial data from the master

Outputs serial data to the master

Clocks data transfers on MOSI and MISO

Enables serial communication with the slave

900HP RF Module asserts this pin as soon as data is available to send to the SPI master and it remains asserted until the SPI master has clocked out all available data.

SPI implementation

The XBee-PRO 900HP RF Module operates as a SPI slave only. This means an external master provides the clock and decides when to send data. The XBee-PRO 900HP RF Module supports an external clock rate of up to 3.5 Mb/s.

XBee®-PRO 900HP/XSC RF Modules

SPI operation SPI signals

The device transmits and receives data with the most significant bit first using SPI mode 0. This means the CPOL and CPHA are both 0. We chose Mode 0 because it is the typical default for most microcontrollers and simplifies configuring the master.

SPI signals

The specification for SPI includes the four signals: SPI_MISO, SPI_MOSI, SPI_CLK, and SPI_SSEL. Using only these four signals, the master cannot know when the slave needs to send and the SPI slave cannot transmit unless enabled by the master. For this reason, the SPI_ATTN signal is available. This allows the device to alert the SPI master that it has data to send. In turn, the SPI master asserts SPI_ SSEL and starts SPI_CLK unless these signals are already asserted and active respectively. This allows the XBee-PRO 900HP RF Module to send data to the master.

The following table names the SPI signals and specifies their pinouts. It also describes the operation of each pin.

Applicable

Signal name

Pin number

AT command Description

SPI_MISO (Master In, Slave out)

SPI_MOSI (Masterout,Slave in)

SPI_SSEL (Slave Select) (Master out, Slave in)

SPI_CLK (Clock) (Master out, Slave in)

SPI_ATTN (Attention) (Master in, Slave out)

4 P2 When SPI_SSEL is asserted (low) and SPI_CLK is

active, the device outputs the data on this line at the SPI_CLK rate. When SPI_SSEL is de-asserted (high), this output should be tri-stated such that another slave device can drive the line.

11 D4 The SPI master outputs data on this line at the

SPI_CLK rate after it selects the desired slave. When the device is configured for SPI operations, this pin is an input.

17 D3 The SPI master outputs a low signal on this line to

select the desired slave. When the device is configured for SPI operations, this pin is an input.

18 D2 The SPI master outputs a clock on this pin, and the

rate must not exceed the maximum allowed, 3.5 Mb/s. When you configure the device for SPI operations, this pin is an input.

19 D1 The device asserts this pin low when it has data to

send to the SPI master. When this pin is configured for SPI operations, it is an output (not tri-stated).

Note By default, the inputs have pull-up resistors enabled. See PR (Pull-up/Down Resistor Enable) to

disable the pull-up resistors. When the SPI pins are not connected but the pins are configured for SPI operation, the pull-ups are required for proper UART operation.

XBee®-PRO 900HP/XSC RF Modules

SPI operation Full duplex operation

Full duplex operation

SPI on the XBee-PRO 900HP RF Module requires that you use API mode (without escaping) to packetize data. By design, SPI is a full duplex protocol even when data is only available in one direction. This means that when a device receives data, it also transmits and that data is normally invalid. Likewise, when the device transmits data, invalid data is probably received. To determine whether or not received data is invalid, we packetize the data with API packets.

SPI allows for valid data from the slave to begin before, at the same time, or after valid data begins from the master. When the master is sending data to the slave and the slave has valid data to send in the middle of receiving data from the master, this allows a true full duplex operation where data is valid in both directions for a period of time. Not only must the master and the slave both be able to keep up with the full duplex operation, but both sides must honor the protocol as specified.

The following diagram illustrates the SPI interface while valid data is being sent in both directions.

Low power operation

Sleep modes generally work the same on SPI as they do on UART. However, due to the addition of SPI mode, there is an option of another sleep pin, as described below.

By default, Digi configures DIO8 (SLEEP_REQUEST) as a peripheral and during pin sleep it wakes the device and puts it to sleep. This applies to both the UART and SPI serial interfaces.

If SLEEP_REQUEST is not configured as a peripheral and SPI_SSEL is configured as a peripheral, then pin sleep is controlled by SPI_SSEL rather than by SLEEP_REQUEST. Asserting SPI_SSEL (pin 17) by driving it low either wakes the device or keeps it awake. Negating SPI_SSEL by driving it high puts the device to sleep.

Using SPI_SSEL to control sleep and to indicate that the SPI master has selected a particular slave device has the advantage of requiring one less physical pin connection to implement pin sleep on SPI. It has the disadvantage of putting the device to sleep whenever the SPI master negates SPI_SSEL (meaning time is lost waiting for the device to wake), even if that was not the intent.

If the user has full control of SPI_SSEL so that it can control pin sleep, whether or not data needs to be transmitted, then sharing the pin may be a good option in order to make the SLEEP_REQUEST pin available for another purpose.

If the device is one of multiple slaves on the SPI, then the device sleeps while the SPI master talks to the other slave, but this is acceptable in most cases.

If you do not configure either pin as a peripheral, then the device stays awake, being unable to sleep in SM1 mode.

XBee®-PRO 900HP/XSC RF Modules

SPI operation SPI and API mode

SPI and API mode

The SPI only operates in API mode 1. The SPIdoes not support Transparent mode or API mode 2 (with escaped characters). This means that the AP configuration only applies to the UART interface and is ignored while using the SPI.

SPI parameters

Most host processors with SPI hardware allow you to set the bit order, clock phase and polarity. For communication with all XBee-PRO 900HP RF Modules, the host processor must set these options as follows:

n Bit order: send MSB first

n Clock phase (CPHA):sample data on first (leading) edge

n Clock polarity (CPOL): first (leading) edge rises

All XBee-PRO 900HP RF Modules use SPI mode 0 and MSB first. Mode 0 means that data is sampled on the leading edge and that the leading edge rises. MSB first means that bit 7 is the first bit of a byte sent over the interface.

XBee®-PRO 900HP/XSC RF Modules

Modes

Serial modes 47 Modes of operation 49

XBee®-PRO 900HP/XSC RF Modules

Modes Serial modes

Serial modes

The firmware operates in several different modes. Two top-level modes establish how the device communicates with other devices through its serial interface: Transparent operating mode and API operating mode. Use the AP command to choose Serial mode. XBee-PRO 900HP RF Modules use Transparent operation as the default serial mode.

The following modes describe how the serial port sends and receives data.

Transparent operating mode

Devices operate in this mode by default. The device acts as a serial line replacement when it is in Transparent operating mode. The device queues all UART data it receives through the DIN pin for RF transmission. When a device receives RF data, it sends the data out through the DOUT pin. You can set the configuration parameters using Command mode.

Note Transparent operating mode is not available when using the SPI interface; see SPI operation.

The device buffers data in the serial receive buffer until one of the following causes the data to be packetized and transmitted:

n The device receives no serial characters for the amount of time determined by the RO

(Packetization Timeout) parameter. If RO = 0, packetization begins when a character is received.

n The device receives the Command Mode Sequence (GT + CC + GT). Any character buffered in

the serial receive buffer before the sequence is transmitted.

n The device receives the maximum number of characters that fits in an RF packet (100 bytes).

See NP (Maximum Packet Payload Bytes).

API operating mode

Application programming interface (API) operating mode is an alternative to Transparent mode. It is helpful in managing larger networks and is more appropriate for performing tasks such as collecting data from multiple locations or controlling multiple devices remotely. API mode is a frame-based protocol that allows you to direct data on a packet basis. It can be particularly useful in large networks where you need control over the operation of the radio network or when you need to know which node a data packet is from. The device communicates UART or SPI data in packets, also known as API frames. This mode allows for structured communications with serial devices.

The application programming interface (API) provides alternative means of configuring devices and routing data at the host application layer. A host application can send data frames to the device that contain address and payload information instead of using Command mode to modify addresses. The device sends data frames to the application containing status packets, as well as source and payload information from received data packets.

For more information, see API mode overview.

Comparing Transparent and API modes

The XBee-PRO 900HP RF Module can use its serial connection in two ways:Transparent mode or API operating mode. You can use a mixture of devices running API mode and transparent mode in a network.

The following table compares the advantages of transparent and API modes of operation:

XBee®-PRO 900HP/XSC RF Modules

Modes Serial modes

Feature Description

Transparent mode features

Simple interface All received serial data is transmitted unless the device is in Command

mode

Easy to support It is easier for an application to support Transparent operation and

Command mode

API mode features

Easy to manage data transmissions to multiple destinations

Transmitting RF data to multiple remote devices only requires the application to change the address in the API frame. This process is much faster than in Transparent mode where the application must enter Command mode, change the address, exit Command mode, and then transmit data.

Each API transmission can return a transmit status frame indicating

Because acknowledgments are sent out of the serial interface, this provides more information about the health of the RF network and can

be used to debug issues after the network has been deployed. the success or reason for failure

Received data frames

All received RF data API frames indicate the source address indicate the sender's address

Advanced addressing support

Advanced networking diagnostics

API transmit and receive frames can expose addressing fields including

source and destination endpoints, cluster ID, and profile ID

API frames can provide indication of I/O samples from remote devices,

and node identification messages.

Some network diagnostic tools such as

Trace Route, NACK, and Link Testing can only be performed in API mode.

Remote Configuration Set/read configuration commands can be sent to remote devices to

configure them as needed using the API

Simultaneous Commands

Query or set a configuration parameter while a pending command like ND

is in progress. This cannot be done in Command mode. It is available in

firmware versions 9009 or newer.

We recommend API mode when a device:

n Sends RF data to multiple destinations

n Sends remote configuration commands to manage devices in the network

n Receives RF data packets from multiple devices, and the application needs to know which

device sent which packet

API mode is required when:

n Receiving I/O samples from remote devices

n Using SPI for the serial port

If the conditions listed above do not apply (for example, a sensor node, router, or a simple application), then Transparent operation might be suitable. It is acceptable to use a mixture of devices running API mode and Transparent mode in a network.

XBee®-PRO 900HP/XSC RF Modules

Modes Modes of operation

Modes of operation

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:

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 DigiMesh data is transmitted from one node to another, the destination node transmits a network-level acknowledgment back across the established route to the source node. This acknowledgment packet indicates to the source node that the destination node received the data packet. If the source node does not receive a network acknowledgment, it retransmits the data.

For more information, see Data transmission and routing.

Receive mode

This is the default mode for the XBee-PRO 900HP RF Module. The device is in Receive mode when it is not transmitting data. If a destination node receives a valid RF packet, the destination node transfers the data to its serial transmit buffer.

Command mode

Command mode is a state in which the firmware interprets incoming characters as commands. It allows you to modify the device’s configuration using parameters you can set using AT

XBee®-PRO 900HP/XSC RF Modules

Modes Modes of operation

commands.When you want to read or set any parameter of the XBee-PRO 900HP RF Module using this mode, you have to send an AT command.Every AT command starts with the lettersATfollowed by the two characters that identify the command and then by some optional configuration values.

The operating modes of the XBee-PRO 900HP RF Module are controlled by the AP (API Mode) setting, butCommand mode is always available as a mode thedevice can enter while configured for any of the operating modes.

Command mode is available on the UART interface for all operating modes. You cannot use the SPI interface to enter Command mode.

Enter Command mode

To get a device to switch into Command mode, you must issue the following sequence:+++within one second. There must be at least one second preceding and following the+++sequence. Both the command character (CC) and the silence before and after the sequence (GT) are configurable. When the entrance criteria are met the device responds with OK\r on UART signifying that it has entered Command mode successfully and is ready to start processing AT commands.

If configured to operate in Transparent operating mode, when entering Command mode the XBeePRO 900HP RF Module knows to stop sending data and start accepting commands locally.

Note Do not press Return or Enter after typing+++because it interrupts the guard time silence and

prevents you from entering Command mode.

When the device is in Command mode, it listens for user input and is able to receive AT commands on the UART. IfCTtime (default is 10 seconds) passes without any user input, the device drops out of Command mode and returns to the previous operating mode. You can force the device to leave Command mode by sending CN (Exit Command Mode).

You can customize the command character, the guard times and the timeout in the device’s configuration settings. For more information, seeCC (Command Character),CT (Command Mode

Timeout)andGT (Guard Times).

Troubleshooting

Failure to enter Command mode is often due to baud rate mismatch. Ensure that the baud rate of the connection matches the baud rate of the device. By default, BD (Baud Rate) = 3 (9600 b/s).

There are two alternative ways to enter Command mode:

n A serial break for six seconds enters Command mode. You can issue the "break" command

from a serial console, it is often a button or menu item.

n Asserting DIN (serial break) upon power up or reset enters Command mode. XCTU guides you

through a reset and automatically issues the break when needed.

Both of these methods temporarily set the device's baud rate to 9600 and return anOKon the UART to indicate that Command mode is active. When Command mode exits, the device returns to normal operation at the baud rate that BDis set to.

Send AT commands

Once the device enters Command mode, use the syntax in the following figure to send AT commands. Every AT command starts with the lettersAT, which stands for "attention." TheATis followed by two characters that indicate which command is being issued, then by some optional configuration values.

To read a parameter value stored in the device’s register, omit the parameter field.

XBee®-PRO 900HP/XSC RF Modules

Modes Modes of operation

The preceding example changes NI (Node Identifier) to My XBee.

Multiple AT commands

You can send multiple AT commands at a time when they are separated by a comma in Command mode; for example,ATNIMy XBee,AC<cr>.

The preceding example changes theNI (Node Identifier) to My XBeeand makes the setting active through AC (Apply Changes).

Parameter format

Refer to the list of AT commands for the format of individual AT command parameters. Valid formats for hexidecimal values include with or without a leading0xfor exampleFFFFor0xFFFF.

Response to AT commands

When using AT commands to set parameters the XBee-PRO 900HP RF Module responds with OK<cr> if successful and ERROR<cr> if not.

For devices with a file system:

ATAP1<cr>

OK<cr>

When reading parameters, the device returns the current parameter value instead of anOKmessage.

ATAP<cr>

1<cr>

Apply command changes

Any changes you make to the configuration command registers using AT commands do not take effect until you apply the changes. For example, if you send theBDcommand to change the baud rate, the actual baud rate does not change until you apply the changes. To apply changes:

1. Send AC (Apply Changes).

2. Send WR (Write). or:

3. Exit Command mode.

Make command changes permanent

Send a WR (Write) command to save the changes. WR writes parameter values to non-volatile memory so that parameter modifications persist through subsequent resets.

Send as RE (Restore Defaults) to wipe settings saved using WR back to their factory defaults.

Note You still have to use WR to save the changes enacted with RE.

XBee®-PRO 900HP/XSC RF Modules

Modes Modes of operation

Exit Command mode

1. Send CN (Exit Command Mode) followed by a carriage return. or:

2. If the device does not receive any valid AT commands within the time specified byCT

(Command Mode Timeout), it returns to Transparent or API mode. The default Command mode

timeout is10seconds.

For an example of programming the device using AT Commands and descriptions of each configurable parameter, see AT commands.

Sleep mode

Sleep modes allow the device to enter states of low power consumption when not in use. The XBeePRO 900HP RF Module supports both pin sleep (Sleep mode entered on pin transition) and cyclic sleep (device sleeps for a fixed time).

Sleep modes allow the device to enter states of low power consumption when not in use. The device is almost completely off during sleep, and is incapable of sending or receiving data until it wakes up. XBee devices support both pin sleep, where the device enters sleep mode upon pin transition, and cyclic sleep, where the device sleeps for a fixed time. While asleep, nodes cannot receive RF messages or read commands from the UART port. For more information, see Sleep modes.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes

About sleep modes 54 Normal mode 54 Asynchronous pin sleep mode 55 Asynchronous cyclic sleep mode 55 Asynchronous cyclic sleep with pin wake up mode 55 Synchronous sleep support mode 55 Synchronous cyclic sleep mode 56 The sleep timer 56 Indirect messaging and polling 56 Sleeping routers 57 Diagnostics 65

XBee®-PRO 900HP/XSC RF Modules

Sleep modes About sleep modes

About sleep modes

A number of low-power modes exist to enable devices to operate for extended periods of time on battery power. Use the SM command to enable these sleep modes. The sleep modes are characterized as either:

n Asynchronous (SM = 1, 4, 5).

n Synchronous (SM = 7, 8).

The difference between a potential coordinator and a non-coordinator is that a non-coordinator node has its SO parameter set so that it will not participate in coordinator election and cannot ever be a sleep coordinator.

Asynchronous modes

n Do not use asynchronous sleep modes in a synchronous sleeping network, and vice versa.

n Use the asynchronous sleep modes to control the sleep state on a device by device basis.

n Do not use devices operating in asynchronous sleep mode to route data.

n We strongly encourage you to set asynchronous sleeping devices as end-devices using the CE

command. This prevents the node from attempting to route data.

Synchronous modes

Synchronous sleep makes it possible for all nodes in the network to synchronize their sleep and wake times. All synchronized cyclic sleep nodes enter and exit a low power state at the same time.

In DigiMesh networks, a device functions in one of three roles:

1. A sleep coordinator.

2. A potential coordinator.

3. A non-coordinator.

This forms a cyclic sleeping network.

n A device acting as a sleep coordinator sends a special RF packet called a sync message to

synchronize nodes.

n To make a device in the network a coordinator, a node uses several resolution criteria through

a process called nomination.

n The sleep coordinator sends one sync message at the beginning of each wake period. The

coordinator sends the sync message as a broadcast and every node in the network repeats it.

n You can change the sleep and wake times for the entire network by locally changing the

settings on an individual device. The network uses the most recently set sleep settings.

Normal mode

Set SM to 0 to enter Normal mode.

Normal mode is the default sleep mode. If a device is in this mode, it does not sleep and is always awake.

Use mains-power for devices in Normal mode.

A device in Normal mode synchronizes to a sleeping network, but does not observe synchronization data routing rules; it routes data at any time, regardless of the network's wake state.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Asynchronous pin sleep mode

When synchronized, a device in Normal mode relays sync messages that sleep-compatible nodes generate, but does not generate sync messages itself.

Once a device in Normal mode synchronizes with a sleeping network, you can put it into a sleepcompatible sleep mode at any time.

Asynchronous pin sleep mode

Set SM to 1 to enter asynchronous pin sleep mode.

Pin sleep allows the device to sleep and wake according to the state of the SLEEP_RQ pin (pin 9).

When you assert SLEEP_RQ (high), the device finishes any transmit or receive operations and enters a low-power state.

When you de-assert SLEEP_RQ (low), the device wakes from pin sleep.

When you enable indirect messaging polling see CE (Node Messaging Options), when the device wakes, it sends a poll to the parent node. For more information, see Indirect messaging and polling.

Asynchronous cyclic sleep mode

Set SM to 4 to enter asynchronous cyclic sleep mode.

Cyclic sleep allows the device to sleep for a specific time and wake for a short time to poll.

If the device receives serial or RF data while awake, it extends the time before it returns to sleep by the specific amount the ST command provides. Otherwise, it enters sleep mode immediately.

The ON_SLEEP line (pin pin 13) is asserted (high) when the device wakes, and is de-asserted (low) when the device sleeps.

If you use the D7 command to enable hardware flow control, the CTS pin asserts (low) when the device wakes and can receive serial data, and de-asserts (high) when the device sleeps.

When you enable indirect messaging polling see CE (Node Messaging Options), when the device wakes, it sends a poll to the parent node. For more information, see Indirect messaging and polling.

Asynchronous cyclic sleep with pin wake up mode

Set SM to 5 to enter asynchronous cyclic sleep with pin wake up mode.

(SM = 5) is similar to both the (SM = 1) and (SM = 4) modes. When the host asserts the SLEEP_ REQUEST pin, the device enters a cyclic sleep mode similar to (SM = 4). When the host de-asserts the SLEEP_REQUEST pin, the device immediately wakes up. The device will not sleep when the SLEEP_ REQUEST pin is de-asserted.

When you enable indirect messaging polling see CE (Node Messaging Options), when the device wakes, it sends a poll to the parent node. For more information, see Indirect messaging and polling.

Synchronous sleep support mode

Set SM to 7 to enter synchronous sleep support mode.

A device in synchronous sleep support mode synchronizes itself with a sleeping network, but does not sleep itself. At any time, the node responds to new nodes that attempt to join the sleeping network with a sync message. A sleep support node only transmits normal data when the other nodes in the sleeping network are awake.

Sleep support nodes are especially useful:

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Synchronous cyclic sleep mode

n When you use them as preferred sleep coordinator nodes.

n As aids in adding new nodes to a sleeping network.

Note Because sleep support nodes do not sleep, they should be mains powered.

Synchronous cyclic sleep mode

Set SM to 8 to enter synchronous cyclic sleep mode.

A device in synchronous cyclic sleep mode sleeps for a programmed time, wakes in unison with other nodes, exchanges data and sync messages, and then returns to sleep. While asleep, it cannot receive RF messages or receive data (including commands) from the UART port.

Generally, the network’s sleep coordinator specifies the sleep and wake times based on its SP and ST settings. The device only uses these parameters at startup until the device synchronizes with the network.

When a device has synchronized with the network, you can query its sleep and wake times with the OS and OW commands respectively.

If D9 = 1 (ON_SLEEP enabled) on a cyclic sleep node, the ON_SLEEP line asserts when the device is awake and de-asserts when the device is asleep.

If D7 = 1, the device de-asserts CTS while asleep.

A newly-powered, unsynchronized, sleeping device polls for a synchronized message and then sleeps for the period that the SP command specifies, repeating this cycle until it synchronizes by receiving a sync message. Once it receives a sync message, the device synchronizes itself with the network.

Note Configure all nodes in a synchronous sleep network to operate in either synchronous sleep

support mode or synchronous cyclic sleep mode. asynchronous sleeping nodes are not compatible with synchronous sleeping nodes.

The sleep timer

If the device receives serial or RF data in Asynchronous cyclic sleep mode and Asynchronous cyclic sleep with pin wake up modes (SM = 4 or SM = 5), it starts a sleep timer (time until sleep).

n If the device receives any data serially or by RF link, the timer resets.

n Use ST (Wake Time) to set the duration of the timer.

n When the sleep timer expires the device returns to sleep.

Indirect messaging and polling

Indirect messaging

Indirect messaging is a communication mode designed for communicating with asynchronous sleeping devices. A device can enable indirect messaging by making itself an indirect messaging coordinator with the CE command. An indirect messaging coordinator does not immediately transmit a P2MP unicast when it is received over the serial port. Instead the device holds onto the data until it is requested via a poll. On receiving a poll, the indirect messaging coordinator sends a queued data packet (if available) to the requestor.

Because it is possible for a polling device to be eliminated, a mechanism is in place to purge unrequested data packets. If the coordinator holds an indirect data packet for an indirect messaging

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

poller for more than 2.5 times its SP value, then the packet is purged. We suggest setting the SP of the coordinator to the same value as the highest SP time that exists among the pollers in the network. If the coordinator is in API mode, a TxStatus message is generated for a purged data packet with a status of 0x75 (INDIRECT_MESSAGE_UNREQUESTED).

An indirect messaging coordinator queues up as many data packets as it has buffers available. After the coordinator uses all of its available buffers, it holds transmission requests unprocessed on the serial input queue. After the serial input queue is full, the device de-asserts CTS (if hardware flow control is enabled). After receiving a poll or purging data from the indirect messaging queue the buffers become available again.

Indirect messaging only functions with P2MP unicast messages. Indirect messaging has no effect on P2MP broadcasts, directed broadcasts, repeater packets, or DigiMesh packets. These messages are sent immediately when received over the serial port and are not put on the indirect messaging queue.

Polling

Polling is the automatic process by which a node can request data from an indirect messaging coordinator. To enable polling on a device, configure it as an indirect messaging poller with the CE command and set its DH:DL registers to match the SH:SL registers of the device that will function as the Indirect Messaging Coordinator. When you enable polling, the device sends a P2MP poll request regularly to the address specified by the DH:DL registers. When the device sends a P2MP unicast to the destination specified by the DH:DL of a polling device, the data also functions as a poll.

When a polling device is also an asynchronous sleeping device, that device sends a poll shortly after waking from sleep. After that first poll is sent, the device sends polls in the normal manner described previously until it returns to sleep.

The 200 K data rate firmware sends polls at least every 100 ms when awake. The 10 K data rate firmware sends polls at least every 300 ms when awake.

Sleeping routers

The Sleeping Router feature of DigiMesh makes it possible for all nodes in the network to synchronize their sleep and wake times. All synchronized cyclic sleep nodes enter and exit a low power state at the same time. This forms a cyclic sleeping network. For more information, see Become a sleep

coordinator.

Sleep coordinator sleep modes in the DigiMesh network

In a synchronized sleeping network, one node acts as the sleep coordinator. During normal operations, at the beginning of a wake cycle the sleep coordinator sends a sync message as a broadcast to all nodes in the network. This message contains synchronization information and the wake and sleep times for the current cycle. All cyclic sleep nodes that receive a sync message remain awake for the wake time and then sleep for the specified sleep period.

The sleep coordinator sends one sync message at the beginning of each cycle with the current wake and sleep times. All router nodes that receive this sync message relay the message to the rest of the network. If the sleep coordinator does not hear a rebroadcast of the sync message by one of its immediate neighbors, then it re-sends the message one additional time.

If you change the SP or ST parameters, the network does not apply the new settings until the beginning of the next wake time. For more information, see Change sleep parameters.

A sleeping router network is robust enough that an individual node can go several cycles without receiving a sync message, due to RF interference, for example. As a node misses sync messages, the time available for transmitting messages during the wake time reduces to maintain synchronization accuracy. By default, a device reduces its active sleep time progressively as it misses sync messages.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

Synchronization messages

A sleep coordinator regularly sends sync messages to keep the network in sync. Unsynchronized nodes also send messages requesting sync information.

Sleep compatible nodes use Deployment mode when they first power up and the sync message has not been relayed. A sleep coordinator in Deployment mode rapidly sends sync messages until it receives a relay of one of those messages. Deployment mode:

n Allows you to effectively deploy a network.

n Allows a sleep coordinator that resets to rapidly re-synchronize with the rest of the network.

If a node exits deployment mode and then receives a sync message from a sleep coordinator that is in Deployment mode, it rejects the sync message and sends a corrective sync to the sleep coordinator.

Use the SO (sleep options) command to disable deployment mode. This option is enabled by default.

A sleep coordinator that is not in deployment mode sends a sync message at the beginning of the wake cycle. The sleep coordinator listens for a neighboring node to relay the sync. If it does not hear the relay, the sleep coordinator sends the sync one additional time.

A node that is not a sleep coordinator and has never been synchronized sends a message requesting sync information at the beginning of its wake cycle. Synchronized nodes which receive one of these messages respond with a synchronization packet.

If you use the SOcommand to configure nodes as non-coordinators, and if the non-coordinators go six or more sleep cycles without hearing a sync, they send a message requesting sync at the beginning of their wake period.

The following diagram illustrates the synchronization behavior of sleep compatible devices.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

Become a sleep coordinator

In DigiMesh networks, a device can become a sleep coordinator in one of four ways:

n Define a preferred sleep coordinator

n A potential sleep coordinator misses three or more sync messages

n Press the Commissioning Pushbutton twice on a potential sleep coordinator

n Change the sleep timing values on a potential sleep coordinator

Preferred sleep coordinator option

You can specify that a node always act as a sleep coordinator. To do this, set the preferred sleep coordinator bit (bit 0) in the SO command to 1.

A node with the sleep coordinator bit set always sends a sync message at the beginning of a wake cycle. To avoid network congestion and synchronization conflicts, do not set this bit on more than one node in the network.

A node that is centrally located in the network can serve as a good sleep coordinator, because it minimizes the number of hops a sync message takes to get across the network.

A sleep support node and/or a node that is mains powered is a good candidate to be a sleep coordinator.

CAUTION! Use the preferred sleep coordinator bit with caution. The advantages of using the option become weaknesses if you use it on a node that is not in the proper position or configuration. Also, it is not valid to have the sleep coordinator option bit set on more than one node at a time.

You can also use the preferred sleep coordinator option when you set up a network for the first time. When you start a network, you can configure a node as a sleep coordinator so it will begin sending sleep messages. After you set up the network, it is best to disable the preferred sleep coordinator bit.

Resolution criteria and selection option

There is an optional selection process with resolution criteria that occurs on a node if it loses contact with the network sleep coordinator. By default, this process is disabled. Use the SO command to enable this process. This process occurs automatically if a node loses contact with the previous sleep coordinator.

If you enable the process on any sleep compatible node, it is eligible to become the sleep coordinator for the network.

A sleep compatible node may become a sleep coordinator if it:

n Misses three or more sync messages.

n It is not configured as a non-coordinator by setting bit 1 of SO.

If such a node wins out in the selection process, it becomes the new network sleep coordinator.

It is possible for multiple nodes to declare themselves as the sleep coordinator. If this occurs, the firmware uses the following resolution criteria to identify the sleep coordinator from among the nodes using the selection process:

1. Newer sleep parameters always take priority over older sleep parameters. The age of the sleep parameters is determined by a sequence number that increments when an overriding

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

sync is sent.

2. Otherwise, the node with the preferred sleep coordinator bit set takes precedence.

3. Otherwise, a sleep support node—SM 7—takes priority over a node that is not a sleep support node—SM 8.

4. Otherwise, the node with highest serial number becomes the sleep coordinator.

Commissioning Pushbutton option

Use the Commissioning Pushbutton to select a device to act as the sleep coordinator.

If you enable the Commissioning Pushbutton functionality, you can immediately select a device as a sleep coordinator by pressing the Commissioning Pushbutton twice or by issuing the CB2 command. The device you select in this manner is still subject to the resolution criteria process.

Only potential sleep coordinator nodes honor Commissioning Pushbutton nomination requests. A node configured as a non-sleep coordinator ignores commissioning button nomination requests.

Overriding syncs

Any sleep compatible node in the network that does not have the non-coordinator sleep option set can send an overriding sync and become the network sleep coordinator. An overriding sync effectively changes the synchronization of all nodes in the network to the ST and SP values of the node sending the overriding sync. It also selects the node sending the overriding sync as the network sleep coordinator. While this is a powerful operation, it may be an undesired side effect because the current sleep coordinator may have been carefully selected and it is not desired to change it. Additionally the current wake and sleep cycles may be desired rather than the parameters on the node sending the overriding sync. For this reason, it is important to know what kicks off an overriding sync.

An overriding sync occurs whenever ST or SP is changed to a value different than OW or OS respectively. For example no overriding sync will occur if SP is changed from 190 to C8 if the network was already operating with OS at C8. On the other hand, if SP is changed from 190 to 190—meaning no change—and OS is C8, than an overriding sync will occur because the network parameters are being changed.

Even parameters that seem unrelated to sleep can kick off an overriding sync. These are NH, NN, RN, and MT. When any of these parameters are changed, they can affect network traversal time. If such changes cause the configured value of ST to be smaller than the value needed for network traversal, then ST is increased and if that increased value is different than OW, then an overriding sync will occur.

For most applications, we recommend configuring the NH, NN, RN, and MT network parameters during initial deployment only. The default values of NH and NN are optimized to work for most deployments. Additionally, it would be best to set ST and SP the same on all nodes in the network while keeping ST sufficiently large so that it will not be affected by an inadvertent change of NH, NN,

RN, or MT.

Sleep guard times

To compensate for variations in the timekeeping hardware of the various devices in a sleeping router network, the network allocates sleep guard times at the beginning and end of the wake period. The size of the sleep guard time varies based on the sleep and wake times you select and the number of sleep cycles that elapse since receiving the last sync message. The sleep guard time guarantees that a destination module will be awake when the source device sends a transmission. As a node misses more and more consecutive sync messages, the sleep guard time increases in duration and decreases the available transmission time.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

Auto-early wake-up sleep option

If you have nodes that are missing sync messages and could be going out of sync with the rest of the network, enabling an early wake gives the device a better chance to hear the sync messages that are being broadcast.

Similar to the sleep guard time, the auto early wake-up option decreases the sleep period based on the number of sync messages a node misses. This option comes at the expense of battery life.

Use the SO command to disable auto-early wake-up sleep. This option is enabled by default.

Select sleep parameters

Choosing proper sleep parameters is vital to creating a robust sleep-enabled network with a desirable battery life. To select sleep parameters that will be good for most applications, follow these steps:

1. Choose NN and NH.

Based on the placement of the nodes in your network, select the appropriate values for the NH (Network Hops) and NN (Network Delay Slots) parameters.

We optimize the default values of NH and NN to work for the majority of deployments. In most cases, we suggest that you do not modify these parameters from their default values. Decreasing these parameters for small networks can improve battery life, but take care to not make the values too small.

2. Calculate the Sync Message Propagation Time (SMPT).

This is the maximum amount of time it takes for a sleep synchronization message to propagate to every node in the network. You can estimate this number with the following formula: SMPT = NN*NH*(MT+1)*18 ms.

3. Select the duty cycle you want. The ratio of sleep time to wake time is the factor that has the greatest effect on the device’s power consumption. Battery life can be estimated based on the following factors:

n sleep period

n wake time

n sleep current

n RX current

n TX current

n battery capacity

4. Choose the sleep period and wake time.

The wake time must be long enough to transmit the desired data as well as the sync message. The ST parameter automatically adjusts upwards to its minimum value when you change other AT commands that affect it (SP, NN, and NH).

Use a value larger than this minimum. If a device misses successive sync messages, it reduces its available transmit time to compensate for possible clock drift. Budget a large enough ST time to allow for the device to miss a few sync messages and still have time for normal data transmissions.

Start a sleeping synchronous network

By default, all new nodes operate in normal (non-sleep) mode. To start a synchronous sleeping network, follow these steps:

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

1. Set SO to 1 to enable the preferred sleep coordinator option on one of the nodes.

2. Set its SM to a synchronous sleep compatible mode (7 or 8) with its SP and ST set to a quick cycle time. The purpose of a quick cycle time is to allow the network to send commands quickly through the network during commissioning.

3. Power on the new nodes within range of the sleep coordinator. The nodes quickly receive a sync message and synchronize themselves to the short cycle SP and ST set on the sleep coordinator.

4. Configure the new nodes to the sleep mode you want, either cyclic sleeping modes or sleep support modes.

5. Set the SP and ST values on the sleep coordinator to the values you want for the network.

6. In order to reduce the possibility of an unintended overriding sync, set SP and ST to the intended sleep/wake cycle on all nodes in the network. Be sure that ST is large enough to prevent it from being inadvertently increased by changing NN, NH, or MT.

7. Wait a sleep cycle for the sleeping nodes to sync themselves to the new SP and ST values.

8. Disable the preferred sleep coordinator option bit on the sleep coordinator unless you want a preferred sleep coordinator.

9. Deploy the nodes to their positions.

Alternatively, prior to deploying the network you can use the WR command to set up nodes with their sleep settings pre-configured and written to flash. If this is the case, you can use the Commissioning Pushbutton and associate LED to aid in deployment:

1. If you are going to use a preferred sleep coordinator in the network, deploy it first.

2. If there will not be a preferred sleep coordinator, select a node for deployment, power it on and press the Commissioning Pushbutton twice. This causes the node to begin emitting sync messages.

3. Verify that the first node is emitting sync messages by watching its associate LED. A slow blink indicates that the node is acting as a sleep coordinator.

4. Power on nodes in range of the sleep coordinator or other nodes that have synchronized with the network. If the synchronized node is asleep, you can wake it by pressing the Commissioning Pushbutton once.

5. Wait a sleep cycle for the new node to sync itself.

6. Verify that the node syncs with the network. The associate LED blinks when the device is awake and synchronized.

7. Continue this process until you deploy all of the nodes.

Add a new node to an existing network

To add a new node to the network, the node must receive a sync message from a node already in the network. On power-up, an unsynchronized, sleep compatible node periodically sends a broadcast requesting a sync message and then sleeps for its SP period. Any node in the network that receives this message responds with a sync. Because the network can be asleep for extended periods of time, and cannot respond to requests for sync messages, there are methods you can use to sync a new node while the network is asleep.

1. Power the new node on within range of a sleep support node. Sleep support nodes are always awake and able to respond to sync requests promptly.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Sleeping routers

2. You can wake a sleeping cyclic sleep node in the network using the Commissioning Pushbutton. Place the new node in range of the existing cyclic sleep node. Wake the existing node by holding down the Commissioning Pushbutton for two seconds, or until the node wakes. The existing node stays awake for 30 seconds and responds to sync requests while it is awake.

If you do not use one of these two methods, you must wait for the network to wake up before adding the new node.

Place the new node in range of the network with a sleep/wake cycle that is shorter than the wake period of the network.

The new node periodically sends sync requests until the network wakes up and it receives a sync message.

Change sleep parameters

To change the sleep and wake cycle of the network, select any sleep coordinator capable node in the network and change the SP and/or ST of the node to values different than those the network currently uses.

n If you use a preferred sleep coordinator or if you know which node acts as the sleep

coordinator, we suggest that you use this node to make changes to network settings.

n If you do not know the network sleep coordinator, you can use any node that does not have the

non-sleep coordinator sleep option bit set. For details on the bit, see SO (Sleep Options).

When you make changes to a node’s sleep parameters, that node becomes the network’s sleep coordinator unless it has the non-sleep coordinator option selected. It sends a sync message with the new sleep settings to the entire network at the beginning of the next wake cycle. The network immediately begins using the new sleep parameters after it sends this sync.

Changing sleep parameters increases the chances that nodes will lose sync. If a node does not receive the sync message with the new sleep settings, it continues to operate on its old settings. To minimize the risk of a node losing sync and to facilitate the re-syncing of a node that does lose sync, take the following precautions:

1. Whenever possible, avoid changing sleep parameters.

2. Enable the missed sync early wake up sleep option in the SO command. This option is enabled by default. This command tells a node to wake up progressively earlier based on the number of cycles it goes without receiving a sync. This increases the probability that the un-synced node will be awake when the network wakes up and sends the sync message.

Note Using this sleep option increases reliability but may decrease battery life. Nodes using this sleep

option that miss sync messages increase their wake time and decrease their sleep time during cycles where they miss the sync message. This increases power consumption.

When you are changing between two sets of sleep settings, choose settings so that the wake periods of the two sleep settings occur at the same time. In other words, try to satisfy the following equation:

(SP1+ ST1) = N * (SP2+ ST2)

where SP1/ST1and SP2/ST2are the desired sleep settings and N is an integer.

Rejoin nodes that lose sync

DigiMesh networks get their robustness from routing redundancies which may be available. We recommend architecting the network with redundant mesh nodes to increase robustness.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Diagnostics

If a scenario exists where the only route connecting a subnet to the rest of the network depends on a single node, and that node fails or the wireless link fails due to changing environmental conditions (a catastrophic failure condition), then multiple subnets may arise using the same wake and sleep intervals. When this occurs the first task is to repair, replace, and strengthen the weak link with new and/or redundant devices to fix the problem and prevent it from occurring in the future.

When you use the default DigiMesh sleep parameters, separated subnets do not drift out of phase with each other. Subnets can drift out of phase with each other if you configure the network in one of the following ways:

n If you disable the non-sleep coordinator bit in the SO command on multiple devices in the

network, they are eligible for the network to nominate them as a sleep coordinator. For more details, see SO (Sleep Options).

n If the devices in the network do not use the auto early wake-up sleep option.

If a network has multiple subnets that drift out of phase with each other, get the subnets back in phase with the following steps:

1. Place a sleep support node in range of both subnets.

2. Select a node in the subnet that you want the other subnet to sync with.

3. Use this node to slightly change the sleep cycle settings of the network, for example, increment ST.

4. Wait for the subnet’s next wake cycle. During this cycle, the node you select to change the sleep cycle parameters sends the new settings to the entire subnet it is in range of, including the sleep support node that is in range of the other subnet.

5. Wait for the out of sync subnet to wake up and send a sync. When the sleep support node receives this sync, it rejects it and sends a sync to the subnet with the new sleep settings.

6. The subnets will now be in sync. You can remove the sleep support node.

7. You can also change the sleep cycle settings back to the previous settings.

If you only need to replace a few nodes, you can use this method:

1. Reset the out of sync node and set its sleep mode to Synchronous Cyclic Sleep mode (SM = 8).

2. Set up a short sleep cycle.

3. Place the node in range of a sleep support node or wake a sleeping node with the Commissioning Pushbutton.

4. The out of sync node receives a sync from the node that is synchronized to the network. It then syncs to the network sleep settings.

Diagnostics

The following diagnostics are useful in applications that manage a sleeping router network:

Query sleep cycle

Use the OS and OW commands to query the current operational sleep and wake times that a device uses.

XBee®-PRO 900HP/XSC RF Modules

Sleep modes Diagnostics

Sleep status

Use the SS command to query useful information regarding the sleep status of the device. Use this command to query if the node is currently acting as a network sleep coordinator.

Missed sync messages command

Use the MS command to query the number of cycles that elapsed since the device received a sync message.

Sleep status API messages

When you use the SOcommand to enable this option, a device that is in API operating mode outputs modem status frames immediately after it wakes up and prior to going to sleep.

XBee®-PRO 900HP/XSC RF Modules

Networking methods

This section explains the basic layers and the three networking methods available on the XBee-PRO 900HP RF Modules, building from the simplest to the most complex.

The MAC and PHY layers 68 64-bit addresses 68 Make a unicast transmission 69 Make a broadcast transmission 69 Delivery methods 69

XBee®-PRO 900HP/XSC RF Modules

Networking methods The MAC and PHY layers

The MAC and PHY layers

The PHY layer defines the physical and electrical characteristics of the network. It is responsible for managing the hardware that modulates and demodulates the RF bits.

The MAC layer is responsible for sending and receiving RF frames. As part of each packet, there is a MAC layer data header that has addressing information as well as packet options. This layer implements packet acknowledgments (ACKs), packet tracking to eliminate duplicates, and so forth.

n When a device is transmitting, it cannot receive packets.

n When a device is not sleeping, it is either receiving or transmitting.

n There are no beacons or master/slave requirements in the design of the MAC/PHY.

The XBee-PRO 900HP RF Module uses a patented method for scanning and finding a transmission. When a device transmits, it sends out a repeated preamble pattern, a MAC header, optionally a network header, followed by packet data. A receiving device is able to scan all the channels to find a transmission during the preamble, then once it has locked into that channel it attempts to receive the whole packet.

The following table shows the AT commands related to the MAC/PHY layers.

AT command Function

CM The Channel Mask is a user-defined list of channels that the device operates on.

For additional information, see CM (Channel Mask).

HP Change HP (Preamble ID) to make it so a group of devices will not interfere with

another group of devices in the same vicinity. The advantage of changing this parameter is that a receiving device will not lock into a transmission of a transmitting device that does not have the same Preamble ID.

ID Change ID (Network ID) to further keep devices from interfering with each other. The

device matches this ID after it matches the preamble pattern and after it receives the MAC header. A unique network identifier distinguishes each network. For devices to communicate, they must be configured with the same network identifier. The ID parameter allows multiple networks to co-exist on the same physical channel.

PL Sets the transmit (TX) power level. You can reduce the power level from the maximum

to reduce current consumption or for testing. This comes at the expense of reduced radio range.

Specifies the number of times a sending device attempts to get an ACK from a destination device when it sends a unicast packet.

Specifies the number of times that a device repeatedly transmits a broadcast packet. This adds redundancy, which improves reliability.

64-bit addresses

We assign each device a unique IEEE 64-bit address at the factory. When a device is in API operating mode and it sends a packet, this is the source address that the receiving device returns.

XBee®-PRO 900HP/XSC RF Modules

Networking methods Make a unicast transmission

n Use the SH and SLcommands to read this address.

n The form of the address is: 0x0013A2XXXXXXXXXX.

n The first six digits are the Digi Organizationally Unique Identifier (OUI).

n The broadcast address is 0x000000000000FFFF.

Make a unicast transmission

To transmit to a specific device in Transparent operating mode:

n Set DH:DL to the SH:SL of the destination device.

To transmit to a specific device in API operating mode:

n In the 64-bit destination address of the API frame, enter the SH:SL address of the destination

device.

Make a broadcast transmission

To transmit to all devices in Transparent operating mode:

n Set DH:DL to 0x000000000000FFFF.

To transmit to all devices in API operating mode:

n Set the 64-bit destination address to 0x000000000000FFFF.

The scope of the broadcast changes based on the delivery method you choose.

Delivery methods

The TO (Transmit Options) command sets the default delivery method that the device uses when in Transparent mode. In API mode, the TxOptions field of the API frame overrides the TO command, if non-zero.

The XBee-PRO 900HP RF Module supports three delivery methods:

n Point-to-multipoint (TO = 0x40).

n Repeater (directed broadcast) (TO = 0x80).

n DigiMesh (TO = 0xC0).

Point to Point / Point to Multipoint (P2MP)

This delivery method does not use a network header, only the MAC header.

In P2MP, the sending devices always send all messages directly to the destination. Other nodes do not repeat the packet. The sending device only delivers a P2MP unicast directly to the destination device, which must be in range of the sending device.

The XBee-PRO 900HP RF Module uses patented technology that allows the destination device to receive unicast transmissions directed to it, even when there is a large amount of traffic. This works best if you keep broadcast transmissions to a minimum.

A sending node repeats a P2MP broadcast transmission MT+1 times, but the receiving nodes do not repeat it, so like a unicast transmission, the receiving device must be in range.

All devices that receive a P2MP broadcast transmission output the data through the serial port.

XBee®-PRO 900HP/XSC RF Modules

Networking methods Delivery methods

P2MP throughput

The following table shows the throughput for the 10 kb/s version, using a 115.2 kb/s serial data rate.

Configuration Data throughput

Point to point unicast, encryption disabled 8.8 kb/s

Point to point unicast, encryption enabled 8.7 kb/s

The following table shows the throughput for the 200 kb/s version, using a 115.2 kb/s serial data rate.

Configuration Data throughput

Point to point unicast, encryption disabled 105.5 kb/s

Point to point unicast, encryption enabled 105.4 kb/s

Digi made data throughput measurements setting the serial interface rate to 115200 b/s, and measuring the time to send 100,000 bytes from source to destination. During the test, no route discoveries or failures occurred.

Repeater/directed broadcast

All of the routers in a network receive and repeat directed broadcast transmissions. Because it does not use ACKs, the originating node sends the broadcast multiple times. By default a broadcast transmission is sent four times—the extra transmissions become automatic retries without acknowledgments. This results in all nodes repeating the transmission four times. Sending frequent broadcast transmissions can quickly reduce the available network bandwidth, so use broadcast transmissions sparingly.

MAC layer

The MAC layer is the building block that is used to build repeater capability. To implement Repeater mode, we use a network layer header that comes after the MAC layer header in each packet. In this network layer there is additional packet tracking to eliminate duplicate broadcasts.

In this delivery method, the device sends both unicast and broadcast packets out as broadcasts that are always repeated. All repeated packets are sent to every device. The devices that receive the broadcast send broadcast data out their serial port.

When a device sends a unicast, it specifies a destination address in the network header. Then, only the device that has the matching destination address sends the unicast out its serial port. This is called a directed broadcast.

Any node that has a CE parameter set to router rebroadcasts the packet if its BH (broadcast hops) or broadcast radius values are not depleted. If a node has already seen a repeated broadcast, it ignores the broadcast.

The NH parameter sets the maximum number of hops that a broadcast transmission is repeated. The device always uses the NH value unless you specify a BH value that is smaller.

By default the CE parameter is set to route all broadcasts. As such, all nodes that receive a repeated packet will repeat it. If you change the CE parameter, you can limit which nodes repeat packets, which helps dense networks from becoming overly congested while packets are being repeated.

Transmission timeout calculations for Repeater/directed broadcast mode are the same as for DigiMesh broadcast transmissions.

XBee®-PRO 900HP/XSC RF Modules

Networking methods Delivery methods

DigiMesh networking

A mesh network is a topology in which each node in the network is connected to other nodes around it. Each node cooperates in transmitting information. Mesh networking provides these important benefits:

n Routing. With this technique, the message is propagated along a path by hopping from node to

node until it reaches its final destination.

n Ad-hoc network creation. This is an automated process that creates an entire network of

nodes on the fly, without any human intervention.

n Self-healing. This process automatically figures out if one or more nodes on the network is

missing and reconfigures the network to repair any broken routes.

n Peer-to-peer architecture. No hierarchy and no parent-child relationships are needed.

n Quiet protocol. Routing overhead will be reduced by using a reactive protocol similar to AODV.

n Route discovery. Rather than maintaining a network map, routes will be discovered and

created only when needed.

n Selective acknowledgments. Only the destination node will reply to route requests.

n Reliable delivery. Reliable delivery of data is accomplished by means of acknowledgments.

n Sleep modes. Low power sleep modes with synchronized wake are supported with variable

sleep and wake times.

With mesh networking, the distance between two nodes does not matter as long as there are enough nodes in between to pass the message along. When one node wants to communicate with another, the network automatically calculates the best path.

A mesh network is also reliable and offers redundancy. For example, If a node can no longer operate because it has been removed from the network or because a barrier blocks its ability to communicate, the rest of the nodes can still communicate with each other, either directly or through intermediate nodes.

Note Mesh networks use more bandwidth for administration and therefore have less available for

payloads.

XBee®-PRO 900HP/XSC RF Modules

Networking methods Delivery methods

Related command: MR

In the same manner as the repeater delivery method, DigiMesh builds on P2MP and repeater modes. In DigiMesh, broadcasts always use the repeater delivery method, but unicasts use meshing technologies.

In the DigiMesh network layer, there are additional network layer ACKs and NACKs. Mesh networking allows messages to be routed through several different nodes to a final destination. DigiMesh firmware allows manufacturers and system integrators to bolster their networks with the self-healing attributes of mesh networking. In the event that one RF connection between nodes is lost (due to power-loss, environmental obstructions, and so on) critical data still reaches its destination due to the mesh networking capabilities embedded inside the modules. If you disable network ACKs, the network never heals.

Data transmission and routing

This section provides information on data transmission, routing, throughput, and transmission timeouts.

Unicast addressing

When devices transmit using DigiMesh unicast, the network uses retries and acknowledgments (ACKs)for reliable data delivery. In a retry and acknowledgment scheme, for every data packet that a device sends, the receiving device must send an acknowledgment back to the transmitting device to let the sender know that the data packet arrived at the receiver. If the transmitting device does not receive an acknowledgment then it re-sends the packet. It sends the packet a finite number of times before the system times out.

The MR (Mesh Network Retries) parameter determines the number of mesh network retries. The sender device transmits RF data packets up to MR + 1 times across the network route, and the receiver transmits ACKs when it receives the packet. If the sender does not receive a network ACK within the time it takes for a packet to traverse the network twice, the sender retransmits the packet.

MAC retries and acknowledgments are used for transmissions between adjacent nodes in the route. NWK retries and acknowledgments are used across the entire route.

To send unicast messages while in Transparent operating mode, set the DH and DL on the transmitting device to match the corresponding SH and SL parameter values on the receiving device.

Routing

A device within a mesh network determines reliable routes using a routing algorithm and table. The routing algorithm uses a reactive method derived from Ad-hoc On-demand Distance Vector (AODV). The firmware uses an associative routing table to map a destination node address with its next hop. A device sends a message to the next hop address, and the message either reaches its destination or forwards to an intermediate router that routes the message on to its destination.

If a message has a broadcast address, it is broadcast to all neighbors, then all routers that receive the message rebroadcast the message MT+1 times. Eventually, the message reaches the entire network.

Packet tracking prevents a node from resending a broadcast message more than MT+1 times. This means that a node that relays a broadcast will only relay it after it receives it the first time and it will discard repeated instances of the same packet.

Route discovery

Route discovery is a process that occurs when:

XBee®-PRO 900HP/XSC RF Modules

Networking methods Delivery methods

1. The source node does not have a route to the requested destination.

2. A route fails. This happens when the source node uses up its network retries without receiving an ACK.

Route discovery begins by the source node broadcasting a route request (RREQ). We call any router that receives the RREQ and is not the ultimate destination, an intermediate node.

Intermediate nodes may either drop or forward a RREQ, depending on whether the new RREQ has a better route back to the source node. If so, the node saves, updates and broadcasts the RREQ.

When the ultimate destination receives the RREQ, it unicasts a route reply (RREP) back to the source node along the path of the RREQ. It does this regardless of route quality and regardless of how many times it has seen an RREQ before.

This allows the source node to receive multiple route replies. The source node selects the route with the best round trip route quality, which it uses for the queued packet and for subsequent packets with the same destination address.

DigiMesh throughput

Throughput in a DigiMesh network can vary due to a number of variables, including:

n The number of hops.

n If you enable or disable encryption.

n Sleeping end devices.

n Failures and route discoveries.

The following table shows the results of our empirical testing of throughput performance in a robust operating environment (low interference).

The results apply to the 200 kb/s version with a 115.2 kb/s serial data rate.

Configuration Data throughput

Mesh unicast, 1 hop, encryption disabled 91.0 kb/s

Mesh unicast, 3 hop, encryption disabled 32.5 kb/s

Mesh unicast, 6 hop, encryption disabled 16.7 kb/s

Mesh unicast, 1 hop, encryption enabled 89.3 kb/s

Mesh unicast, 3 hop, encryption enabled 32.2 kb/s

Mesh unicast, 6 hop, encryption enabled 16.1 kb/s

Note We made the data throughput measurements by setting the serial interface rate to 115200 b/s,

and measuring the time to send 100,000 bytes from source to destination. During the test, no route discoveries or failures occurred.

Transmission timeouts

When a device in API operating mode receives a Transmit Request (0x10, 0x11) frame, or a device in Transparent operating mode meets the packetization requirements (RO, RB), the time required to route the data to its destination depends on:

XBee®-PRO 900HP/XSC RF Modules

Networking methods Delivery methods

n A number of configured parameters.

n Whether the transmission is a unicast or a broadcast.

n If the route to the destination address is known.

Timeouts or timing information is provided for the following transmission types:

n Broadcast transmission

n Unicast transmission on a known route

n Unicast transmission on an unknown route

n Unicast transmission on a broken route

Note The timeouts in this documentation are theoretical timeouts and are not precisely accurate.

Your application should pad the calculated maximum timeouts by a few hundred milliseconds. When you use API operating mode, use Extended Transmit Status - 0x8B as the primary method to determine if a transmission is complete.

Unicast one hop time

unicastOneHopTime is a building block of many of the following calculations. It represents the amount of time it takes to send a unicast transmission between two adjacent nodes. The amount of time depends on the %H parameter.

Transmit a broadcast

All of the routers in a network must relay a broadcast transmission.

The maximum delay occurs when the sender and receiver are on the opposite ends of the network.

The NH and %H parameters define the maximum broadcast delay as follows:

BroadcastTxTime = NH * NN * %8

Unless BH < NH, in which case the formula is:

BroadcastTxTime = BH * NN * %8

Transmit a unicast with a known route

When a device knows a route to a destination node, the transmission time is largely a function of the number of hops and retries. The timeout associated with a unicast assumes that the maximum number of hops is necessary, as specified by the NH command.

You can estimate the timeout in the following manner:

knownRouteUnicastTime=2*NH*MR*unicastOneHopTime

Transmit a unicast with an unknown route

If the transmitting device does not know the route to the destination, it begins by sending a route discovery. If the route discovery is successful, then the transmitting device transmits data. You can estimate the timeout associated with the entire operation as follows:

unknownRouteUnicastTime=BroadcastTxTime+ (NH*unicastOneHopTime)+knownRouteUnicastTime

Transmit a unicast with a broken route

If the route to a destination node changes after route discovery completes, a node begins by attempting to send the data along the previous route. After it fails, it initiates route discovery and, when the route discovery finishes, transmits the data along the new route. You can estimate the timeout associated with the entire operation as follows:

XBee®-PRO 900HP/XSC RF Modules

Networking methods Delivery methods

brokenRouteUnicastTime=BroadcastTxTime+(NH*unicastOneHopTime)+ (2*knownRouteUnicastTime)

XBee®-PRO 900HP/XSC RF Modules

AT commands

Special commands 77 MAC/PHY commands 78 Diagnostic commands 81 Network commands 84 Addressing commands 86 Addressing discovery/configuration commands 89 Security commands 92 Serial interfacing commands 92 I/O settings commands 95 I/O sampling commands 104 Sleep commands 107 Diagnostic - sleep status/timing commands 109 Command mode options 111 Firmware commands 112

XBee®-PRO 900HP/XSC RF Modules

AT commands Special commands

Special commands

The following commands are special commands.

AC (Apply Changes)

Immediately applies new settings without exiting Command mode.

Parameter range

N/A

Default

N/A

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

RE (Restore Defaults)

Restore device parameters to factory defaults.

Parameter range

N/A

Default

N/A

WR (Write)

Writes parameter values to non-volatile memory so that parameter modifications persist through subsequent resets.

Note Once you issue a WR command, do not send any additional characters to the device until after

you receive the OK response.

Parameter range

N/A

Default

N/A

XBee®-PRO 900HP/XSC RF Modules

AT commands MAC/PHY commands

MAC/PHY commands

The following Binary commands are MAC/PHY commands.

AF (Available Frequencies)

You can query this read-only command to return a bitfield of the frequencies that are available in the device’s region of operation. This command returns a bitfield. Each bit corresponds to a physical channel.

Note that the least significant bit in the bitmask selects the channel in the lowest frequency in the range.

Channels for these data rates are spaced 400 kHz apart.

Bit 0 – 902.400 MHz

Bit 1 – 902.800 MHz

Bit 31 – 914.800 MHz

Bit 63 – 927.600 MHz

Parameter range

0x1FFFFFF – 0x00FFFFFFFFFFFFFFFF

Default

Region Bitfield Channels

United States/Canada 0x00FFFFFFFFFFFFFFFF 0-63

Australia 0x00FFFFFFFE00000000 33-63

Brazil 0x00FFFFFFFE00000FFF 0-11, 33-63

Singapore 0x00FFE00000000000 63-52

CM (Channel Mask)

CM allows you to selectively enable or disable channels used for RF communication. This is useful to

avoid using frequencies that experience unacceptable levels of RF interference, or to operate two networks of radios on separate frequencies.

This command is a bitfield. Each bit in the bitfield corresponds to a frequency as defined in the AF (Available Frequencies) command. When you set a bit in CM and the corresponding bit in AF is 1, then the device can choose that channel as an active channel for communication.

A minimum of MF channels must be made available for the device to communicate on. You can use the MF command to query the minimum number of channels required for operation. If a CM setting would result in less than MF active channels being enabled, then the device returns an error. If there are

XBee®-PRO 900HP/XSC RF Modules

AT commands MAC/PHY commands

more active channels enabled than required by MF, then the device uses the first MF frequencies; higher active frequencies may be unused in favor of lower ones.

Exactly MF (Minimum Frequency Count) number of channels must be made available for the device to communicate on.

All devices in a network must use an identical set of active channels in order to communicate. Separate networks that are in physical range of each other should use different HP (Preamble Patterns) and/or ID (Network IDs) to avoid receiving data from the other network.

You may find the ED (Energy Detect) command useful when choosing what channels to enable or disable.

Note Channel 19 (910.000 MHz) is disabled by default. This channel has approximately 2 dBm worse

receiver sensitivity than other channels. We suggest that you do not use this channel.

Parameter range

0x1FFFFFF – 0x00FFFFFFFFFFFFFFFF

Default

0xFFFFFFFFFFF7FFFF

MF (Minimum Frequency Count)

You can query this read-only command to determine the minimum number of channels that you must enable with the CM command for proper operation in the device's region of operation.

Parameter range

1 - 50

Default

United States/Canada: 25

Australia: 25

Brazil: 25

Singapore: 11

HP (Preamble ID)

The preamble ID for which the device communicates. Only devices with matching preamble IDs can communicate with each other. Different preamble IDs minimize interference between multiple sets of devices operating in the same vicinity. When receiving a packet, the device checks this before the network ID, as it is encoded in the preamble, and the network ID is encoded in the MAC header.

Note When using devices certified for use in Singapore, HP settings of 1, 2, or 3 have reduced

performance compared to the other settings. Avoid these settings in this region.

Parameter range

0 - 7

Default

XBee®-PRO 900HP/XSC RF Modules

AT commands MAC/PHY commands

ID (Network ID)

Set or read the user network identifier.

Devices must have the same network identifier to communicate with each other.

Devices can only communicate with other devices that have the same network identifier and channel configured.

When receiving a packet, the device check this after the preamble ID. If you are using Original equipment manufacturer (OEM) network IDs, 0xFFFF uses the factory value.

Parameter range

0 - 0x7FFF

Default

0x7FFF

MT(Broadcast Multi-Transmits)

Set or read the number of additional MAC-level broadcast transmissions. All broadcast packets are transmitted MT+1 times to ensure they are received.

Parameter range

0 - 5

Default

PL (TX Power Level)

Sets or displays the power level at which the device transmits conducted power. Power levels are approximate.

PL= 4 is calibrated and the remaining power levels are approximate.

Parameter range

Setting Power level

0 +7 dBm (5 mW)

1 +15 dBm (32 mW)

2 +18 dBm (63 mW)

3 +21 dBm (125 mW)

4 +24 dBm (250 mW)

Default

XBee®-PRO 900HP/XSC RF Modules

AT commands Diagnostic commands

RR (Unicast Mac Retries)

Set or read the maximum number of MAC level packet delivery attempts for unicasts. If RR is nonzero, the sent unicast packets request an acknowledgment from the recipient. Unicast packets can be retransmitted up to RR times if the transmitting device does not receive a successful acknowledgment.

Parameter range

0 - 0xF

Default

0x0A (decimal 10)

ED (Energy Detect)

Starts an energy detect scan. This command accepts an argument to specify the time in milliseconds to scan all channels. The device loops through all the available channels until the time elapses. It returns the maximal energy on each channel, a comma follows each value, and the list ends with a carriage return. The values returned reflect the energy level that ED detects in -dBm units.

Parameter range

0 - 0xFF

Default

0xA

Diagnostic commands

The following commands are diagnostic commands.

BC (Bytes Transmitted)

The number of RF bytes transmitted. The firmware counts every byte of every packet, including MAC/PHY headers and trailers. The purpose of this count is to estimate battery life by tracking time spent performing transmissions.

This number rolls over to 0 from 0xFFFF.

You can reset the counter to any unsigned 16-bit value by appending a hexadecimal parameter to the command.

Parameter range

0 - 0xFFFF

Default

DB (Last Packet RSSI)

Reports the RSSI in -dBm of the last received RF data packet. DB returns a hexadecimal value for the dBm measurement.

For example, if DB returns 0x60, then the RSSI of the last packet received was -96 dBm.

XBee®-PRO 900HP/XSC RF Modules

AT commands Diagnostic commands

DB only indicates the signal strength of the last hop. It does not provide an accurate quality measurement for a multihop link.

If the XBee-PRO 900HP RF Module has been reset and has not yet received a packet, DB reports 0.

This value is volatile (the value does not persist in the device's memory after a power-up sequence).

Parameter range

0 - 0xFF [read-only]

Default

ER (Received Error 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

ERcommand.

Parameter range

0 - 0xFFFF

Default

GD (Good Packets Received)

This count increments when a device receives a good frame with a valid MAC header on the RF interface. Received MAC ACK packets do not increment this counter. Once the number reaches 0xFFFF, it does not count further events.

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).

Parameter range

0 - 0xFFFF

Default

EA (MAC ACK Failure Count)

This count increments whenever a MAC ACK timeout occurs on a MAC-level unicast. 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. This value is volatile (the value does not persist in the device's memory after a power-up sequence).

Parameter range

0 - 0xFFFF

Default

XBee®-PRO 900HP/XSC RF Modules

AT commands Diagnostic commands

TR (Transmission Failure Count)

This count increments whenever a MAC transmission attempt exhausts all MAC retries without ever receiving a MAC acknowledgment message from the destination node. Once the number reaches 0xFFFF, it does not count further events.

To reset the counter to any 16-bit value, append a hexadecimal parameter to the command.

Parameter range

0 - 0xFFFF

Default

UA (MAC Unicast Transmission Count)

This count increments whenever a MAC unicast transmission occurs that requests an ACK. Once the number reaches 0xFFFF, it does not count further events.

You can reset the counter to any 16-bit unsigned value by appending a hexadecimal parameter to the command.

Parameter range

0 - 0xFFFF

Default

%H (MAC Unicast One Hop Time)

The MAC unicast one hop time timeout in milliseconds. If you change the MAC parameters it can change this value.

Parameter range

[read-only]

Default

0xCF

0x267

%8 (MAC Broadcast One Hop Time)

The MAC broadcast one hop time timeout in milliseconds. If you change MAC parameters, it can change this value.

Parameter range

[read-only]

Default

0x1BE

XBee®-PRO 900HP/XSC RF Modules

AT commands Network commands

Network commands

The following commands are network commands.

CE (Node Messaging Options)

The routing and messaging mode bit field of the device.

A routing device repeats broadcasts. Indirect Messaging Coordinators do not transmit point-tomultipoint unicasts until an Indirect Messaging Poller requests them. Setting a device as an Indirect Messaging Poller causes it to regularly send polls to its Indirect Messaging Coordinator. Nodes can also be configured to route, or not route, multi-hop packets.

Bit Description

Bit 0 Indirect Messaging Coordinator enable. All point-to-multipoint unicasts will be held

until requested by a polling end device.

Bit 1 Disable routing on this node. When set, this node will not propagate broadcasts or

become an intermediate node in a DigiMesh route. This node will not function as a repeater.

Bit 2 Indirect Messaging Polling enable. Periodically send requests for messages held by the

node’s coordinator.

Note Bit 0 and Bit 2 cannot be set at the same time.

Parameter range

0 - 6

Default

BH (Broadcast Hops)

The maximum transmission hops for broadcast data transmissions.

If you set BH greater than NH, the device uses the value of NH. Both variants of firmware support this command.

Parameter range

0 - 0x20

Default

NH (Network Hops)

Sets or displays the maximum number of hops across the network. This parameter limits the number of hops. You can use this parameter to calculate the maximum network traversal time.

You must set this parameter to the same value on all nodes in the network.

Both variants are supported.

XBee®-PRO 900HP/XSC RF Modules

AT commands Network commands

Parameter range

1 - 0x20

Default

NN (Network Delay Slots)

Set or read the maximum random number of network delay slots before rebroadcasting a network packet.

Parameter range

1 - 0x05

Default

MR (Mesh Unicast Retries)

Set or read the maximum number of network packet delivery attempts. If MR is non-zero, the packets a device sends request a network acknowledgment, and can be resent up to MR+1 times if the device does not receive an acknowledgment.

Changing this value dramatically changes how long a route request takes.

We recommend that you set this value to 1.

If you set this parameter to 0, it disables network ACKs. Initially, the device can find routes, but a route will never be repaired if it fails.

Note This command is supported in the 200k variant only.

Parameter range

0 - 7

Default

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

XBee®-PRO 900HP/XSC RF Modules

AT commands Addressing commands

Parameter range

0 - 0xFF [slots]

Default

0 (no delay slots inserted)

Addressing commands

SH (Serial Number High)

Displays the upper 32 bits of the unique IEEE 64-bit extended address assigned to the XBee-PRO in the factory.

The 64-bit source address is always enabled. This value is read-only and it never changes.

Parameter range

0 - 0xFFFFFFFF [read-only]

Default

Set in the factory

SL (Serial Number Low)

Displays the lower 32 bits of the unique IEEE 64-bit RF extended address assigned to the XBee-PRO in the factory.

The device's serial number is set at the factory and is read-only.

Parameter range

0 - 0xFFFFFFFF [read-only]

Default

Set in the factory

DH (Destination Address High)

Set or read the upper 32 bits of the 64-bit destination address. When you combine DH with DL, it defines the destination address that the device uses for transmissions in Transparent mode.

Parameter range

0 - 0xFFFFFFFF

Default

DL (Destination Address Low)

Set or display the lower 32 bits of the 64-bit destination address. When you combine DH with DL, it defines the destination address that the device uses for transmissions in Transparent mode.

XBee®-PRO 900HP/XSC RF Modules

AT commands Addressing commands

Parameter range

0 - 0xFFFFFFFF

Default

0x0000FFFF

TO (Transmit Options)

The bitfield that configures the transmit options for Transparent mode.

Parameter range

0 - 0xFF

Bit field:

Bit Meaning Description

6,7 Delivery method

5 Reserved <set this bit to 0>

4 Reserved <set this bit to 0>

3 Trace route Enable a Trace Route on all DigiMesh API packets

2 NACK Enable a NACK messages on all DigiMesh API packets

1 Disable RD Disable Route Discovery on all DigiMesh unicasts

0 Disable ACK Disable acknowledgments on all unicasts

Example 1: Set TO to 0x80 to send all transmissions using repeater mode.

Example 2: Set TO to 0xC1 to send transmissions using DigiMesh, with network acknowledgments

disabled.

n Bits 6 and 7 cannot be set to DigiMesh on the 10k build.

n Bits 4 and 5 must be set to 0.

n Bits 1, 2, and 3 cannot be set on the 10k build.

Default

0x40 (10k product)

0xC0 (200k product)

b’00 = <invalid option> b’01 = Point-multipoint b'10 = Directed Broadcast (0x80) b’11 = DigiMesh (not available in the 10k product)

NI (Node Identifier)

Stores the node identifier string for a device, which is a user-defined name or description of the device. This can be up to 20 ASCII characters.

XBee®-PRO 900HP/XSC RF Modules

AT commands Addressing commands

n XCTU prevents you from exceeding the string limit of 20 characters for this command. If you

are using another software application to send the string, you can enter longer strings, but the software on the device returns an error.

Use the ND (Network Discovery) command with this string as an argument to easily identify devices on the network.

The DN command also uses this identifier.

Parameter range

A string of case-sensitive ASCII printable characters from 0 to 20 bytes in length. A carriage return or a comma automatically ends the command.

Default

0x20 (an ASCII space character)

NT (Node Discover Time)

Sets the amount of time a base node waits for responses from other nodes when using the ND

(Network Discover), DN (Discover Node), and FN (Find Neighbors) commands. When a discovery is

performed, the broadcast transmission includes the NT value to provide all remote devices with a response timeout. Remote devices wait a random time, less than NT, before sending their response to avoid collisions.

The N? command should be used to determine how long the actual discovery timeout will be based on current device configuration.

Parameter range

0x20 - 0x2EE0 (x 100 ms)

Default

0x82 (13 seconds)

NO (Node Discovery Options)

Use NOto suppress or include a self-response to ND (Node Discover) commands. When NO bit 1 = 1, a device performing a Node Discover includes a response entry for itself.

Use NOto suppress or include certain data in the ND (Node Discovery) response.

Parameter range

0 - 0x07 (bit field)

Bit field

Option Description

0x01

0x02

Append the DD (Digi Device Identifier) value to ND responses or API node identification frames.

Local device sends ND or FN (Find Neighbors) response frame when the ND is issued.

0x04

XBee®-PRO 900HP/XSC RF Modules

Append the RSSI of the last hop to ND, FN, and responses or API node identification frames.

AT commands Addressing discovery/configuration commands

Default

0x0

CI (Cluster ID)

The application layer cluster ID value. The device uses this value as the cluster ID for all data transmissions.

Parameter range

0 - 0xFFFF

Default

0x11 (Transparent data cluster ID)

DE (Destination Endpoint)

Sets or displays the application layer destination ID value. The value is used as the destination endpoint for all data transmissions. The default value (0xE8) is the Digi data endpoint.

Parameter range

0 - 0xFF

Default

0xE8

SE (Source Endpoint)

Sets or displays the application layer source endpoint value. The value is used as the source endpoint for all data transmissions. The default value (0xE8) is the Digi data endpoint.

This command only affects outgoing transmissions in transparent mode (AP = 0).

0xE8 is the Digi data endpoint used for outgoing data transmissions.

0xE6 is the Digi device object endpoint used for configuration and commands.

Parameter range

0 - 0xFF

Default

0xE8

Addressing discovery/configuration commands

AG (Aggregator Support)

The AG command sends a broadcast through the network that has the following effects on nodes that receive the broadcast:

n The receiving node establishes a DigiMesh route back to the originating node, if there is space

in the routing table.

XBee®-PRO 900HP/XSC RF Modules

AT commands Addressing discovery/configuration commands

n The DH and DL of the receiving node update to the address of the originating node if the AG

parameter matches the current DH/DL of the receiving node.

n API-enabled devices with updated DH and DL send an Aggregate Addressing Update frame

(0x8E) out the serial port.

Note The AG command is only available on products that support DigiMesh.

Parameter range

Any 64-bit address

Default

N/A

DN (Discover Node)

Resolves an NI (Node identifier) string to a physical address (case sensitive).

The device returns an ERROR message if it is given without a destination node (that is without a parameter) or if the given destination node does not respond within N? milliseconds. If an ERROR is received, the device does not exit Command mode.

The following events occur after DN discovers the destination node:

When DN is sent in Command mode:

1. The device sets DL and DH to the extended (64-bit) address of the device with the matching NI string.

2. The receiving device returns OK (or ERROR).

3. The device exits Command mode to allow for immediate communication. If an ERROR is received, the device does not exit Command mode.

When DN is sent as an API frame, the receiving device returns 0xFFFE followed by its 64-bit extended addresses in an API Command Response frame.

Parameter range

20-byte ASCII string

Default

N/A

ND (Network Discover)

Discovers and reports all devices found in the network. For each discovered device, the following information is returned:

SH<CR> (4 bytes)

SL<CR> (4 bytes)

DB<CR> (Contains the detected signal strength of the response in negative dBm units)

NI <CR> (variable, 0-20 bytes plus 0x00 character)

DEVICE_TYPE<CR> (1 byte: 0 = Coordinator, 1 = Router, 2 = End Device)

STATUS<CR> (1 byte: reserved)

PROFILE_ID<CR> (2 bytes)

XBee®-PRO 900HP/XSC RF Modules

AT commands Addressing discovery/configuration commands

MANUFACTURER_ID<CR> (2 bytes)

DIGI DEVICE TYPE<CR> (4 bytes. Optionally included based on NO settings.)

RSSI OF LAST HOP<CR> (1 byte. Optionally included based on NO settings.)

After (NT * 100) milliseconds, the command ends by returning a <CR>. ND also accepts NI (Node

Identifier) as a parameter (optional). In this case, only a device that matches the supplied identifier

responds.

If you send ND through a local API frame, the device returns each response as a separate AT_CMD_ Response packet. The data consists of the bytes listed above without the carriage return delimiters. The NI string ends in a 0x00 null character.

Parameter range

20-byte printable ASCIIstring

Default

N/A

FN (Find Neighbors)

Discovers and reports all devices found within immediate (1 hop) RF range. FN reports the following information for each device it discovers:

MY<CR> (always 0xFFFE)

SH<CR>

SL<CR>

NI<CR> (Variable length)

PARENT_NETWORK ADDRESS<CR> (2 bytes) (always 0xFFFE)

DEVICE_TYPE<CR> (1 byte: 0 = Coordinator, 1 = Router, 2 = End Device)

STATUS<CR> (1 byte: reserved)

PROFILE_ID<CR> (2 bytes)

MANUFACTURER_ID<CR> (2 bytes)

DIGI DEVICE TYPE<CR> (4 bytes. Optionally included based on NO (Node Discovery Options) settings.)

RSSI OF LAST HOP<CR> (1 byte. Optionally included based on NO (Node Discovery Options) settings.)

<CR>

If you send the FN command in Command mode, after (NT*100) ms + overhead time, the command ends by returning a carriage return, represented by <CR>.

If you send the FN command through a local AT Command (0x08) or remote AT command (0x17) API frame, each response returns as a separate AT Command Response (0x88) or Remote Command Response (0x97) frame, respectively. The data consists of the bytes in the previous list without the carriage return delimiters. The NI string ends in a 0x00 null character.

FN accepts a NI (Node Identifier) as an argument.

Parameter range

0 to 20 ASCII characters

Default

N/A

XBee®-PRO 900HP/XSC RF Modules

AT commands Security commands

Security commands

The following AT commands are security commands.

EE (Security Enable)

Enables or disables Advanced Encryption Standard (AES) encryption.

Set this command parameter the same on all devices in a network.

Parameter range

0 - 1

Parameter Description

0 Encryption Disabled

1 Encryption Enabled

Default

KY (AES Encryption Key)

Sets the network security key value that the device uses for encryption and decryption.

This command is write-only. If you attempt to read KY, the device returns an OK status.

Set this command parameter the same on all devices in a network.

The value passes in as hex characters when you set it from AT command mode, and as binary bytes when you set it in APImode.

Parameter range

128-bit value

Default

N/A

Serial interfacing commands

The following AT commands are serial interfacing commands.

BD (Baud Rate)

Values from 0 - 8 select preset standard rates.

Values at 0x39 and above select the actual baud rate if the host supports it.

Parameter range

Standard baud rates: 0x0 - 0x8

Non-standard baud rates: 0x100 to 0x6ACFC0

XBee®-PRO 900HP/XSC RF Modules

AT commands Serial interfacing commands

Value Description

0x1 2,400 b/s

0x2 4,800 b/s

0x3 9,600 b/s

0x4 19,200 b/s

0x5 38,400 b/s

0x6 57,600 b/s

0x7 115,200 b/s

0x8 230,400 b/s

Default

0x03 (9600 b/s)

NB (Parity)

Set or read the serial parity settings for UART communications.

Parameter range

0x00 - 0x02

Parameter Description

0x00 No parity

0x01 Even parity

0x02 Odd parity

Parameter Description

0 No parity

1 Even parity

2 Odd parity

Default

0x00

SB (Stop Bits)

Sets or displays the number of stop bits in the data packet.

Parameter range

0 - 1

XBee®-PRO 900HP/XSC RF Modules

AT commands Serial interfacing commands

Parameter Configuration

0 One stop bit

1 Two stop bits

Default

RO (Packetization Timeout)

Set or read the number of character times of inter-character silence required before transmission begins when operating in Transparent mode.

Set RO to 0 to transmit characters as they arrive instead of buffering them into one RF packet.

Parameter range

0 - 0xFF (x character times)

Default

FT (Flow Control Threshold)

Set or display the flow control threshold.

The device de-asserts CTS and/or send XOFF when FT bytes are in the UART receive buffer. It reasserts CTS when less than FT-16 bytes are in the UART receive buffer.

Parameter range

0x11 - 0x16F bytes

Default

0x13F

AP (API Mode)

Set or read the API mode setting. The device can format the RF packets it receives into API frames and send them out the serial port.

Parameter range

0 - 2

Parameter Description

Transparent mode, API mode is off. All UART input and output is raw data and the device uses the RO parameter to delineate packets.

1 API Mode Without Escapes. The device packetizes all UART input and output data in

API format, without escape sequences.

XBee®-PRO 900HP/XSC RF Modules

AT commands I/O settings commands

Parameter Description

2 API Mode With Escapes. The device is in API mode and inserts escaped sequences to

allow for control characters. The device passes XON, XOFF, Escape, and the 0x7E delimiter as data.

Default

AO (API Options)

The API data frame output format for RF packets received. This parameter applies to both the UARTand SPI interfaces.

Use AO to enable different API output frames.

Parameter range

0, 1

Parameter Description

0 API Rx Indicator - 0x90, this is for standard data frames.

1 API Explicit Rx Indicator - 0x91, this is for Explicit Addressing data frames.

Default

I/O settings commands

The following AT commands are I/O settings commands.

CB (Commissioning Pushbutton)

Use CB to simulate commissioning pushbutton presses in software.

Set the parameter value to the number of button presses that you want to simulate. For example, send CB1 to perform the action of pressing the Commissioning Pushbutton once.

See Commissioning pushbutton and associate LED.

See Commissioning pushbutton.

Parameter range

0 - 4

Default

N/A

D0 (DIO0/AD0)

Sets or displays the DIO0/AD0 configuration (pin 20).

XBee®-PRO 900HP/XSC RF Modules

AT commands I/O settings commands

Parameter range

0 - 5

Parameter Description

0 Disabled

1 Commissioning Pushbutton

2 ADC

3 Digital input

4 Digital output, low

5 Digital output, high

Default

D1 (DIO1/AD1)

Sets or displays the DIO1/AD1 configuration (pin 19).

Parameter range

0 - 6

Parameter Description

0 Disabled

1 Commissioning button

2 ADC

3 Digital input

4 Digital output, low

5 Digital output, high

6 UART Data Present Indicator

6 PTI_EN

Default

SPI_ATTN

D2 (DIO2/AD2)

Sets or displays the DIO2/AD2 configuration (pin 18).

XBee®-PRO 900HP/XSC RF Modules

AT commands I/O settings commands

Parameter range

0 - 5

0 - 1

Parameter Description

0 Disabled

2 ADC

3 Digital input

4 Digital output, low

5 Digital output, high

Default

SPI_CLK

D3 (DIO3/AD3)

Sets or displays the DIO3/AD3 configuration (pin 17).

Parameter range

0 - 5

Parameter Description

0 Disabled

1 SPI slave select

2 ADC

3 Digital input

4 Digital output, low

5 Digital output, high

Default

D4 (DIO4)

Sets or displays the DIO4 configuration (pin 11).

Parameter range

0, 1, 3 - 5

XBee®-PRO 900HP/XSC RF Modules

AT commands I/O settings commands

Parameter Description

0 Disabled

2 N/A

3 Digital input

4 Digital output, low

5 Digital output, high

Default

SPI_MOSI

D5 (DIO5/ASSOCIATED_INDICATOR)

Sets or displays the DIO5/ASSOCIATED_INDICATOR configuration (pin 15).

Parameter range

0, 1, 3 - 5

Parameter Description

0 Disabled

Associate LED indicator - blinks when associated

2 N/A

3 Digital input

4 Digital output, default low

5 Digital output, default high

Default

D6 (DIO6/RTS)

Sets or displays the DIO6/RTS configuration (pin 16).

Parameter range

0, 1, 3 - 5

Parameter Description

0 Disabled

RTS flow control

XBee®-PRO 900HP/XSC RF Modules

AT commands I/O settings commands

Parameter Description

2 N/A

3 Digital input

4 Digital output, low

5 Digital output, high

Default

D7 (DIO7/CTS)

Sets or displays the DIO7/CTS configuration (pin 12).

Parameter range

0, 1, 3 - 7

Parameter Description

0 Disabled

2 N/A

3 Digital input

4 Digital output, low

5 Digital output, high

6 RS-485 Tx enable, low Tx (0 V on transmit, high when idle)

7 RS-485 Tx enable high, high Tx (high on transmit, 0 V when idle)

Default

0x1

CTSflow control

D8 (DIO8/SLEEP_REQUEST)

Sets or displays the DIO8/SLEEP_REQUEST configuration (pin 9).

Parameter range

0, 1, 3 - 5

Parameter Description

0 Disabled

1 Sleep request

XBee®-PRO 900HP/XSC RF Modules

AT commands I/O settings commands

Parameter Description

2 N/A

3 Digital input

4 Digital output, low

5 Digital output, high

Default

D9 (DIO9/ON_SLEEP)

Sets or displays the DIO9/ON_SLEEP configuration (pin 13).

Parameter range

0, 1, 3 - 5

Parameter Description

0 Disabled

2 N/A

3 Digital input

4 Digital output, low

5 Digital output, high

Default

ON/SLEEP output

P0 (DIO10/RSSI/PWM0 Configuration)

Sets or displays the PWM0/RSSI/DIO10 configuration ().

Sets or displays the DIO10/PWM0 configuration (pin 6).

Parameter range

0 - 5

Parameter Description

0 Disabled

1 RSSI PWM0 output

2 PWM0 output

XBee®-PRO 900HP/XSC RF Modules

100

Digi XBee-PRO 900HP User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

About the XBee-PRO 900HP RF Module

User guide structure

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

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

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

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

SPI operation

SPI communications

SPI implementation

SPI signals

Full duplex operation

Low power operation

SPI and API mode

SPI parameters

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

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