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