XBee-PRO 900HP/XSC RF Modules Guide Datasheet by Digi

View All Related Products | Download PDF Datasheet
XBee-PRO 900HP/XSC RF Modules
S3 and S3B
User Guide
Revision history—90002173
Revision Date Description
R May
Removed the Warranty section and added a link. Updated the SY command
information. Corrected the GT parameter range. Added Mexico IFETEL
S October
Replaced the Programmable bootloader section with the Programmable XBee
SDK section. Updated the indoor range spec. Corrected the SPand ST
parameter default values.
T May
Added note on range estimation. Changed ICto ISED.
U July
Added the 0x00, 0x80 and 0x89 frames for the 900HP.
V June
Added FCC publication 996369 related information.
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.
© 2018 Digi International Inc. All rights reserved.
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.
To view product warranty information, go to the following website:
Customer support
Gather support information: Before contacting Digi technical support for help, gather the following
Product name and model
Product serial number (s)
Firmware version
XBee-PRO 900HP/XSC RF Modules 2
Operating system/browser (if applicable)
Logs (from time of reported issue)
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.
To provide feedback on this document, email your comments to
Include the document title and part number (XBee-PRO 900HP/XSC RF Modules, 90002173 T) in the
subject line of your email.
XBee-PRO 900HP/XSC RF Modules 3
About the XBee-PRO 900HP RF Module
User guide structure 13
Technical specifications
Performance specifications 16
Power requirements 16
General specifications 17
Networking specifications 17
Regulatory conformity summary 17
Serial communication specifications 18
UART pin assignments 18
SPI pin assignments 18
GPIO specifications 18
Secondary processor specifications 19
Mechanical drawings 22
Pin signals 23
Design notes 25
Power supply design 25
Board layout 25
Antenna performance 25
Recommended pin connections 26
Module operation for the programmable variant 27
Programmable XBee SDK 29
Configure the XBee-PRO 900HP RF Module
Software libraries 31
Configure the device using XCTU 31
Over-the-air firmware updates 31
Distribute the new application 31
Verify the new application 32
Install the application 32
XBee Multi Programmer 33
XBee-PRO 900HP/XSC RF Modules 4
XBee-PRO 900HP/XSC RF Modules 5
Basic operational design 35
Serial interface 35
UART data flow 35
Serial data 36
Configuration considerations 36
Select the serial port 36
Force UART operation 37
Select the SPI port 37
Serial port selection 38
Serial receive buffer 38
Serial transmit buffer 38
UART flow control 38
CTS flow control 38
RTS flow control 38
SPI operation
SPI communications 41
SPI implementation 41
SPI signals 42
Full duplex operation 42
Low power operation 43
SPI and API mode 43
SPI parameters 44
Serial modes 46
Transparent operating mode 46
API operating mode 46
Comparing Transparent and API modes 46
Modes of operation 48
Idle mode 48
Transmit mode 48
Receive mode 48
Command mode 48
Sleep mode 51
Sleep modes
About sleep modes 53
Asynchronous modes 53
Synchronous modes 53
Normal mode 53
Asynchronous pin sleep mode 54
Asynchronous cyclic sleep mode 54
Asynchronous cyclic sleep with pin wake up mode 54
Synchronous sleep support mode 54
Synchronous cyclic sleep mode 55
The sleep timer 55
Indirect messaging and polling 55
XBee-PRO 900HP/XSC RF Modules 6
Indirect messaging 55
Polling 56
Sleeping routers 56
Sleep coordinator sleep modes in the DigiMesh network 56
Synchronization messages 57
Become a sleep coordinator 59
Select sleep parameters 61
Start a sleeping synchronous network 61
Add a new node to an existing network 62
Change sleep parameters 63
Rejoin nodes that lose sync 63
Diagnostics 64
Query sleep cycle 64
Sleep status 64
Missed sync messages command 65
Sleep status API messages 65
Networking methods
The MAC and PHY layers 67
64-bit addresses 67
Make a unicast transmission 68
Make a broadcast transmission 68
Delivery methods 68
Point to Point / Point to Multipoint (P2MP) 68
Repeater/directed broadcast 69
DigiMesh networking 70
AT commands
Special commands 76
AC (Apply Changes) 76
FR (Force Reset) 76
RE (Restore Defaults) 76
WR (Write) 76
MAC/PHY commands 77
AF (Available Frequencies) 77
CM (Channel Mask) 77
MF (Minimum Frequency Count) 78
HP (Preamble ID) 78
ID (Network ID) 78
MT(Broadcast Multi-Transmits) 79
PL (TX Power Level) 79
RR (Unicast Mac Retries) 79
ED (Energy Detect) 80
Diagnostic commands 80
BC (Bytes Transmitted) 80
DB (Last Packet RSSI) 80
ER (Received Error Count) 81
GD (Good Packets Received) 81
EA (MAC ACK Failure Count) 81
TR (Transmission Failure Count) 81
UA (MAC Unicast Transmission Count) 82
%H (MAC Unicast One Hop Time) 82
XBee-PRO 900HP/XSC RF Modules 7
%8 (MAC Broadcast One Hop Time) 82
Network commands 82
CE (Node Messaging Options) 82
BH (Broadcast Hops) 83
NH (Network Hops) 83
NN (Network Delay Slots) 84
MR (Mesh Unicast Retries) 84
RN (Delay Slots) 84
Addressing commands 85
SH (Serial Number High) 85
SL (Serial Number Low) 85
DH (Destination Address High) 85
DL (Destination Address Low) 85
TO (Transmit Options) 86
NI (Node Identifier) 86
NT (Node Discover Time) 87
NO (Node Discovery Options) 87
CI (Cluster ID) 87
DE (Destination Endpoint) 88
SE (Source Endpoint) 88
Addressing discovery/configuration commands 88
AG (Aggregator Support) 88
DN (Discover Node) 89
ND (Network Discover) 89
FN (Find Neighbors) 90
Security commands 90
EE (Security Enable) 90
KY (AES Encryption Key) 91
Serial interfacing commands 91
BD (Baud Rate) 91
NB (Parity) 92
SB (Stop Bits) 92
RO (Packetization Timeout) 92
FT (Flow Control Threshold) 93
AP (API Mode) 93
AO (API Options) 93
I/O settings commands 94
CB (Commissioning Pushbutton) 94
D0 (DIO0/AD0) 94
D1 (DIO1/AD1) 95
D2 (DIO2/AD2) 95
D3 (DIO3/AD3) 96
D4 (DIO4) 96
D6 (DIO6/RTS) 97
D7 (DIO7/CTS) 97
P0 (DIO10/RSSI/PWM0 Configuration) 99
P1 (DIO11/PWM1 Configuration) 99
P2 (DIO12 Configuration) 100
P3 (DIO13/DOUT) 100
P4 (DIO14/DIN) 101
PD (Pull Up/Down Direction) 101
PR (Pull-up/Down Resistor Enable) 101
XBee-PRO 900HP/XSC RF Modules 8
M0 (PWM0 Duty Cycle) 102
M1 (PWM1 Duty Cycle) 102
LT command 102
RP (RSSI PWM Timer) 103
I/O sampling commands 103
AV (Analog Voltage Reference) 103
IC (DIO Change Detection) 103
IF (Sleep Sample Rate) 104
IR (I/O Sample Rate) 104
IS (Force Sample) 105
TP (Board Temperature) 105
%V (Voltage Supply Monitoring) 106
Sleep commands 106
SM (Sleep Mode) 106
SO (Sleep Options) 106
SN (Number of Sleep Periods) 107
SP (Sleep Period) 107
ST (Wake Time) 108
WH (Wake Host Delay) 108
Diagnostic - sleep status/timing commands 108
SS (Sleep Status) 108
OS (Operating Sleep Time) 109
OW (Operating Wake Time) 109
MS (Missed Sync Messages) 109
SQ (Missed Sleep Sync Count) 110
Command mode options 110
CC (Command Character) 110
CN (Exit Command Mode) 110
CT (Command Mode Timeout) 111
GT (Guard Times) 111
Firmware commands 111
VL (Version Long) 111
VR (Firmware Version) 111
HV (Hardware Version) 111
HS (Hardware Series) 112
DD (Device Type Identifier) 112
NP (Maximum Packet Payload Bytes) 112
CK (Configuration CRC) 112
Operate in API mode
API mode overview 115
API frame format 115
API operation (AP parameter = 1) 115
API operation-with escaped characters (AP parameter = 2) 115
Data bytes that need to be escaped: 116
Length 116
Frame data 116
API serial exchanges 117
AT commands 117
Transmit and Receive RF data 118
Remote AT commands 118
Device Registration 119
Calculate and verify checksums 119
Example 119
XBee-PRO 900HP/XSC RF Modules 9
Frame descriptions
Legacy TX Request frame - 0x00 121
AT Command frame - 0x08 122
AT Command - Queue Parameter Value frame - 0x09 124
Transmit Request frame - 0x10 126
Explicit Addressing Command frame - 0x11 129
Remote AT Command Request frame - 0x17 132
Legacy RX Indicator frame - 0x80 134
AT Command Response frame - 0x88 136
TX Status frame - 0x89 138
Modem Status frame - 0x8A 139
Transmit Status frame - 0x8B 140
Route Information Packet frame - 0x8D 142
Aggregate Addressing Update frame - 0x8E 145
Receive Packet frame - 0x90 147
Explicit Rx Indicator frame - 0x91 149
I/O Data Sample Rx Indicator frame - 0x92 152
Node Identification Indicator frame - 0x95 154
Remote Command Response frame - 0x97 157
Advanced application features
Remote configuration commands 160
Send a remote command 160
Apply changes on remote devices 160
Remote command responses 160
Network commissioning and diagnostics 160
Configure devices 160
Network link establishment and maintenance 161
Place devices 162
Device discovery 162
Link reliability 163
Commissioning pushbutton and associate LED 165
I/O line monitoring 168
I/O samples 168
Queried sampling 168
Periodic I/O sampling 171
Detect digital I/O changes 171
General Purpose Flash Memory
General Purpose Flash Memory 173
Access General Purpose Flash Memory 173
General Purpose Flash Memory commands 174
PLATFORM_INFO (0x80) 174
ERASE (0x01) 175
WRITE (0x02) and ERASE_THEN_WRITE (0x03) 176
READ (0x04) 177
READ_RESPONSE (0x84) 178
XBee-PRO 900HP/XSC RF Modules 10
Work with flash memory 180
XSC firmware
XBee-PRO XSC RF Module overview 182
Pin signals 182
Electrical characteristics 183
Timing specifications 184
XBee-PRO XSC specifications
Performance specifications 188
Power requirements 188
Networking specifications 189
General specifications 189
Antenna options 189
Regulatory conformity summary 190
XBee-PRO XSC RF Module operation
Serial communications 192
UART-interfaced data flow 192
Serial data 192
Flow control 192
Data In (DIN) buffer and flow control 193
Data Out (DO) buffer and flow control 194
Operating modes 194
Idle mode 194
Transmit mode 195
Receive mode 195
Sleep mode 195
Command mode 198
Configuration and commands
Programming examples 203
Connect the device to a PC 203
Send binary commands 203
Example 203
Special commands 204
FR (Force Reset) 204
PL (TX Power Level) 204
Command mode options 204
AT (Guard Time After) 205
BT (Guard Time Before) 205
CC (Command Sequence Character) 205
CD (DO3 Configuration) 206
CN (Exit Command Mode) 206
CT (Command Mode Timeout) 207
E0 (Echo Off) 207
E1 (Echo On) 207
XBee-PRO 900HP/XSC RF Modules 11
PC (Power-up to Transparent operating mode) 208
Networking and security commands 208
AM (Auto-set MY) 208
MD (RF Mode) 209
MY (Source Address) 209
Network commands 210
DT (Destination Address) 210
HP (Preamble ID) 210
HT (Time before Wake-up Initializer) 211
MK command 211
RN (Delay Slots) 212
RR (Unicast Mac Retries) 212
SY (Time Before Initialization) 213
TT (Streaming Limit) 214
Serial interfacing commands 214
BD (Interface Data Rate) 214
CS (DO2 Configuration) 215
FL (Software Flow Control) 216
FT (Flow Control Threshold) 217
NB (Parity) 217
PK command 217
RB (Packetization Threshold) 218
RO (Packetization Timeout) 218
RT (DI2 Configuration) 219
Diagnostic commands 219
ER (Receive Count Error) 219
GD (Receive Good Count) 220
RE (Restore Defaults) 220
RP (RSSI PWM Timer) 221
RZ (DI Buffer Size) 221
RS (RSSI) 222
SH (Serial Number High) 222
SL (Serial Number Low) 223
TR (Transmission Failure Count) 223
VR (Firmware Version - Short) 223
Sleep commands 224
FH (Force Wakeup Initializer) 224
HT (Time before Wake-up Initializer) 224
LH (Wakeup Initializer Timer) 225
PW (Pin Wakeup) 225
SM (Sleep Mode) 226
ST (Wake Time) 227
Network configurations
Network topologies 229
Point-to-point networks 229
Point-to-multipoint networks 229
Peer to peer networks 230
Addressing 231
Address recognition 232
Basic communications 232
Streaming mode (default) 232
Repeater mode 233
Acknowledged mode 237
XBee-PRO 900HP/XSC RF Modules 12
S3B hardware certifications
Agency certifications - United States 241
United States (FCC) 241
OEM labeling requirements 241
XBee-PRO 900HP and XBee-PRO XSC 241
FCC notices 241
Limited modular approval 242
Fixed base station and mobile applications 242
Portable applications and SAR testing 243
RF exposure statement 243
FCC-approved antennas (900 MHz) 244
Antennas approved for use with the XBee-PRO 900HP RF Module 244
FCC publication 996369 related information 251
ISED (Innovation, Science and Economic Development Canada) 253
Labeling requirements 253
Contains IC: 1846A-XB900HP 253
Transmitters for detachable antennas 253
Detachable antenna 253
Brazil ANATEL 254
Mexico IFETEL 254
IDA (Singapore) certification 254
Labeling 254
Frequency band 255
Antenna gain 255
Legacy S3B hardware certifications
Agency certifications - United States 257
United States (FCC) 257
OEM labeling requirements 257
XBee PRO S3 257
XBee PRO S3B 257
FCC notices 258
Limited modular approval 258
Fixed base station and mobile applications 259
Portable applications and SAR testing 259
RF exposure statement 259
ISED (Innovation, Science and Economic Development Canada) 260
Labeling requirements 260
Contains IC: 1846A-XB900HP 260
Contains IC: 1846A-XBEEXSC or Contains IC: 1846A-XBPS3B 260
Antenna options: 900 MHz antenna listings 261
Transmitters with detachable antennas 266
Detachable antenna 267
Brazil ANATEL 268
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:
nOne Energy Micro EFM®32G230F128 microcontroller
nOne Analog Devices ADF7023 radio transceiver
nOne RF power amplifier
nOne NXP MC9S08QE32®microcontroller, only in the programmable version of the XBee
User guide structure
This user guide contains documentation for two RF protocols: XStream Compatible (XSC) and 900HP.
The XSC firmware is provided for customers who need compatibility with existing networks that need
to be 9XStream compatible. Customers who do not require this compatibility should not use the XSC
firmware, but rather the newer 900HP firmware.
The XSC firmware section at the back of this user guide contains documentation for the XSC firmware
only. All other firmware documentation in the user guide is applicable to the 900HP firmware only. For
more information about XSC firmware see the XSC firmware section.
The XBee-PRO 900HP RF Module is not backward compatible with the legacy XBee-PRO 900 (Part
Number: XBP09-DP…) or XBee-PRO DigiMesh 900 (Part Number: XBP09-DM…) RF Modules.
The following table describes how to use this user guide based on the Digi part number for the
XBee-PRO 900HP/XSC RF Modules 13
About the XBee-PRO 900HP RF Module User guide structure
XBee-PRO 900HP/XSC RF Modules 14
Digi Part
Numbers FCC ID
S31XSC XSC Legacy S3B hardware
XBP9B-XC*T-001 (revision G
and earlier)
XBP9B-XC*T-002 (revision G
and earlier)
XBP9B-XC*T-021 (revision F
and earlier)
XBP9B-XC*T-022 (revision F
and earlier)
S3B XSC XSC Legacy S3B hardware
XBP9B-XC*T-001 (revision H
and later)
XBP9B-XC*T-002 (revision H
and later)
XBP9B-XC*T-021 (revision G
and later)
XBP9B-XC*T-022 (revision G
and later)
all other part numbers
beginning XBP9B-XC...
S3B 900HP XSC /
1The S3 hardware variant is a legacy design that is obsolete. New and old designs should use the S3B hardware
Technical specifications
Performance specifications 16
Power requirements 16
General specifications 17
Networking specifications 17
Regulatory conformity summary 17
Serial communication specifications 18
GPIO specifications 18
Secondary processor specifications 19
XBee-PRO 900HP/XSC RF Modules 15
Technical specifications Performance specifications
XBee-PRO 900HP/XSC RF Modules 16
Performance specifications
This table describes the performance specifications for the devices.
Note Range figure estimates are based on free-air terrain with limited sources of interference. Actual
range will vary based on transmitting power, orientation of transmitter and receiver, height of
transmitting antenna, height of receiving antenna, weather conditions, interference sources in the
area, and terrain between receiver and transmitter, including indoor and outdoor structures such as
walls, trees, buildings, hills, and mountains.
Specification Value
Ideal RF line-of-sight
10 kb/s: up to 9 miles (15.5 km)
200 kb/s: up to 4 miles (6.5 km)
(with 2.1 dB dipole antennas)
Transmit power output 24 dBm (250 mW) (software selectable)
RF data rate (high) 200 kb/s
RF data rate (low) 10 kb/s
Serial UART interface Complementary metal–oxide–semiconductor (CMOS) Serial universal
asynchronous receiver/transmitter (UART), baud rate stability of <1%
Serial interface data
rate (software
9600-230400 baud
Receiver sensitivity
-101 dBm, high data rate
-110 dBm, low data rate
Power requirements
The following table describes the power requirements for the XBee-PRO 900HP RF Module.
Specification Value
Supply voltage 2.1 to 3.6 VDC1
Transmit current PL = 4: 215 mA typical, (290 mA max)
PL = 3: 160 mA typical
PL = 2: 120 mA typical
PL = 1: 95 mA typical
PL = 0: 60 mA typical
Idle/receive current 29 mA typical at 3.3 V (35 mA max)
Sleep current 2.5 µA (typical)
1Supply voltages of less than 3.0 V may reduce performance. Output power and receiver sensitivity may
Technical specifications General specifications
XBee-PRO 900HP/XSC RF Modules 17
General specifications
The following table describes the general specifications for the devices.
Specification Value
Operating frequency band1902 to 928 MHz (software selectable channels)
Dimensions 3.29 cm x 2.44 cm x 0.546 cm (1.297" x 0.962" x 0.215)
Dimensions do not include connector/antenna or pin lengths
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,
Analog-to-digital converter
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
64 channels available
Addressing options Personal Area Network identifier (PAN ID), Preamble ID, and
64-bit addresses
Encryption 128 bit Advanced Encryption Standard (AES)
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
1Supply voltages of less than 3.0 V may reduce performance. Output power and receiver sensitivity may
Technical specifications Serial communication specifications
XBee-PRO 900HP/XSC RF Modules 18
Country Approval
Australia RCM
Brazil ANATEL 3727-12-1209
Singapore License No. DA105737 (XB900HP
Mexico IFETEL (XB900HP only)
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
CTS / DIO7 12
RTS / DIO6 16
SPI pin assignments
SPI pins Device pin number
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.
Technical specifications Secondary processor specifications
XBee-PRO 900HP/XSC RF Modules 19
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 VDD
High Schmitt switching threshold 0.7 x VDD
Input pull-up resistor value 40 kΩ
Input pull-down resistor value 40 kΩ
Output voltage for logic 0 0.05 x VDD
Output voltage for logic 1 0.95 x VDD
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:
Itotal = Ir2 + Irx = 14 mA + 9 mA = 23 mA
where Ir2 is the runtime current of the secondary processor and Irx is the receive current of the
primary processor.
Optional secondary processor specification
Add these numbers to power requirement
(add to RX, TX, and sleep currents
depending on mode of operation)
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
2.4 to 3.6 VDC
Technical specifications Secondary processor specifications
XBee-PRO 900HP/XSC RF Modules 20
Optional secondary processor specification
Add these numbers to power requirement
(add to RX, TX, and sleep currents
depending on mode of operation)
Minimum reset pulse for programmable variant 100 nS
Minimum reset pulse to radio 50 nS
Voltage reference (VREF) range 1.8 VDC to VCC
Mechanical drawings 22
Pin signals 23
Design notes 25
XBee-PRO 900HP/XSC RF Modules 21
XBee-PRO (sideview) XBeeiPRO (sideview) " [37m 1' 3,2117 if ,, [#:14an 6'12?” 09% in ‘— [2438 mm] 0.299 in [7.59 mm] — 0.304 in 0257 'n [7.72 mm] [6'53 mm] I l . . i I I . . Shield/bottom side - I 1.297 in : : [32 94 mm] I l . . I I 0.284 in ' [7.22 mm -0866 in [2200 mm]
Hardware Mechanical drawings
XBee-PRO 900HP/XSC RF Modules 22
Mechanical drawings
The following figures show the mechanical drawings for the XBee-PRO 900HP RF Module. The
drawings do not show antenna options.
0.960 0,866 ) P|N11 ( 3 g: D: 0. "I E E PIN 10 v ° (0375) T: T: m m ; : ,i T: :5 g : ; PIN1 F0 n "1‘. v v_ :9 ' l V 11M ,9, A A N m .. o' 2 3 O O (0013) V “ XBee hardware dimensions [0.304) 0.435 ( 0.500 ) XBee .210" SHORTER THAN XBEe-PRO PIN 10 \ Om 5.? P|N1 96 (0.040) Xflee hardware (side View)
Hardware Pin signals
XBee-PRO 900HP/XSC RF Modules 23
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
state Description
1 VCC Power supply
Hardware Pin signals
XBee-PRO 900HP/XSC RF Modules 24
Pin # Name Direction
state Description
2 DOUT/DIO13 Both Output GPIO/UART data out
Both Input GPIO/UART data in
4 DIO12/SPI_
Both Output GPIO/SPI slave out
5 RESET Input Device reset. Drive low to reset the device. 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.
6 DIO10/PWM0 Both GPIO/RX signal strength indicator
7 DIO11/PWM1 Both GPIO/pulse width modulator
8 Reserved Disabled Do not connect
Both Input GPIO/pin sleep control line (DTR on the
development board)
10 GND Ground
11 DIO4/SPI_MOSI Both GPIO/SPI slave in
12 CTS/DIO7 Both Output GPIO/clear-to-send flow control
Output Output GPIO/module status indicator
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_
Both GPIO/analog input/SPI slave select
18 AD2/DIO2/SPI_
Both GPIO/analog input /SPI clock
19 AD1/DIO1/SPI_
Both GPIO/analog input /SPI attention
20 AD0/DIO0 Both GPIO/analog input
Hardware Design notes
XBee-PRO 900HP/XSC RF Modules 25
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
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:
nMetal poles
nMetal studs
nStructure beams
nConcrete, 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:
nVentilation ducts
Hardware Design notes
XBee-PRO 900HP/XSC RF Modules 26
nMicrowave ovens
nTall electrolytic capacitors
Use the following additional guidelines for optimal antenna performance:
nDo not place XBee modules with the chip antenna inside a metal enclosure.
nDo not place any ground planes or metal objects above or below the antenna.
nFor 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.
or with 32k lash an
Hardware Design notes
XBee-PRO 900HP/XSC RF Modules 27
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
0000000000 Programmable XBee—PRO S3B _0000000000
Hardware Design notes
XBee-PRO 900HP/XSC RF Modules 28
Hardware Design notes
XBee-PRO 900HP/XSC RF Modules 29
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
To use the SDK, you must also download CodeWarrior. The download links are:
nCodeWarrior IDE: http://ftp1.digi.com/support/sampleapplications/40003004_B.exe
nProgrammable 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
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.
Configure the XBee-PRO 900HP RF Module
Software libraries 31
Configure the device using XCTU 31
Over-the-air firmware updates 31
XBee Multi Programmer 33
XBee-PRO 900HP/XSC RF Modules 30
Configure the XBee-PRO 900HP RF Module Software libraries
XBee-PRO 900HP/XSC RF Modules 31
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:
nXBee Java library
nXBee 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. XBee-
PRO 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
Configure the XBee-PRO 900HP RF Module Over-the-air firmware updates
XBee-PRO 900HP/XSC RF Modules 32
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.
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:
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.
Configure the XBee-PRO 900HP RF Module XBee Multi Programmer
XBee-PRO 900HP/XSC RF Modules 33
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:
nEach XBee Multi Programmer board allows you to program up to six devices simultaneously.
Connect more boards to increase the programming concurrency.
nDifferent 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.
Basic operational design 35
Serial interface 35
UART data flow 35
Configuration considerations 36
Serial port selection 38
UART flow control 38
XBee-PRO 900HP/XSC RF Modules 34
Host Serial Interface UART SPI Transparent AT Command API Mode Mode Mode Command Handler Packet Handler MAC/PHY Layer (Point-Multipoint) Antenna
Operation Basic operational design
XBee-PRO 900HP/XSC RF Modules 35
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:
nLogic and voltage compatible universal asynchronous receiver/transmitter (UART).
nLevel translator to any serial device, for example, through an RS-232 or USB interface board.
nSPI, 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.
CMOS Logic (3.0- 3.6V) I—II—I CMOS Logic (3. 0- 3. 6V) DIN (data In) DIN (data in) [TS Us DD («La—m Out) DD (dita out) ' Microcontroller Module Module Microcontroller WEI Sllmfiflm N (am) We mm I I I I I a o a \ I I I I I I I I I I I UART Signal Sigm' ° V“ I I I I I I I I I I I Valuge I T I I I I I I I I I sun Imnw) «op-Imam
Operation Configuration considerations
XBee-PRO 900HP/XSC RF Modules 36
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:
nHow do you select the serial port? For example, should you use the UART or the SPI port?
nIf you use the SPI port, what data format should you use in order to avoid processing invalid
characters while transmitting?
nWhat 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.
ve gort, yo igurat edtoe vailablet m o.
Operation Configuration considerations
XBee-PRO 900HP/XSC RF Modules 37
nIf 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.
nIf 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.
nIf 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:
nD1 (This parameter will only be changed if it is at a default of zero when the method is
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
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.
DOUT (P ouldfle [DMD tLehflt (om seirts fl°_w he_se
Operation Serial port selection
XBee-PRO 900HP/XSC RF Modules 38
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
Operation UART flow control
XBee-PRO 900HP/XSC RF Modules 39
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.
SPI operation
SPI communications 41
SPI implementation 41
SPI signals 42
Full duplex operation 42
Low power operation 43
SPI and API mode 43
SPI parameters 44
XBee-PRO 900HP/XSC RF Modules 40
Frame Format nSSEL \ MISODm 5cm" _/_\_/_\_/_\_/_\_/\_/_\_/_\_/_\_ MOSH" X RXl7] X RX[6] X RX[5]X RX[4] X RXISJ X RXIZ] X RXHI X RXIOIX TX[7] X we] X m5] X TX[4] X TXIGJ X TXIZI X TX[1] X TXIOI X )—
SPI operation SPI communications
XBee-PRO 900HP/XSC RF Modules 41
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
Inputs serial data from the master
In,Slave Out)
Outputs serial data to the master
Clocks data transfers on MOSI and MISO
Enables serial communication with the slave
SPI_ATTN (Attention) Alerts the master that slave has data queued to send. The XBee-PRO 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.
In this mode:
nSPI clock rates up to 3.5 MHz are possible.
nData is most significant bit (MSB) first.
nFrame Format mode 0 is used. This means CPOL= 0 (idle clock is low) and CPHA = 0 (data is
sampled on the clocks leading edge).
nThe SPI port only supports API Mode (AP =1).
The following diagram shows the frame format mode 0 for SPI communications.
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.
0 send allow puts th
SPI operation SPI signals
XBee-PRO 900HP/XSC RF Modules 42
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.
Signal name
command Description
(Master In, Slave
4P2 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.
(Slave Select)
(Master out, Slave
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.
(Master out, Slave
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
(Master in, Slave
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.
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
”05‘ I (Don’t Care Valid Invalid Don’t Care ”'50 ‘ Don't Care Invalid Valid Invalid Dan’tCare \ nSSeI \ T configure m sertin ponS
SPI operation Low power operation
XBee-PRO 900HP/XSC RF Modules 43
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.
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 operation SPI parameters
XBee-PRO 900HP/XSC RF Modules 44
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
nBit order: send MSB first
nClock phase (CPHA):sample data on first (leading) edge
nClock 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.
Serial modes 46
Modes of operation 48
XBee-PRO 900HP/XSC RF Modules 45
Modes Serial modes
XBee-PRO 900HP/XSC RF Modules 46
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:
nThe 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
nThe device receives the Command Mode Sequence (GT +CC +GT). Any character buffered in
the serial receive buffer before the sequence is transmitted.
nThe 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
The following table compares the advantages of transparent and API modes of operation:
Modes Serial modes
XBee-PRO 900HP/XSC RF Modules 47
Feature Description
Transparent mode features
Simple interface All received serial data is transmitted unless the device is in Command
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
the success or reason
for failure
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.
Received data frames
indicate the sender's
All received RF data API frames indicate the source address
Advanced addressing
API transmit and receive frames can expose addressing fields including
source and destination endpoints, cluster ID, and profile ID
Advanced networking
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
We recommend API mode when a device:
nSends RF data to multiple destinations
nSends remote configuration commands to manage devices in the network
nReceives RF data packets from multiple devices, and the application needs to know which
device sent which packet
API mode is required when:
nReceiving I/O samples from remote devices
nUsing 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.
Modes Modes of operation
XBee-PRO 900HP/XSC RF Modules 48
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:
nTransmit mode (serial data in the serial receive buffer is ready to be packetized).
nReceive mode (valid RF data received through the antenna).
nCommand 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