17-01-2013, 10:52 AM
XBee™/XBee-PRO™ OEM RF Modules
Mounting Considerations
The XBee/XBee-PRO RF Module was designed to mount into a receptacle (socket) and therefore does not require any soldering when mounting it to a board. The XBee Development Kits contain RS-232 and USB interface boards which use two 20-pin receptacles to receive modules.
RF Module Operation
Serial Communications
The XBee/XBee-PRO OEM RF Modules interface to a host device through a logic-level asynchro¬nous serial port. Through its serial port, the module can communicate with any logic and voltage compatible UART; or through a level translator to any serial device (For example: Through a Max-Stream proprietary RS-232 or USB interface board).
Transparent Operation
By default, XBee/XBee-PRO RF Modules operate in Transparent Mode. When operating in this mode, the modules act as a serial line replacement - all UART data received through the DI pin is queued up for RF transmission. When RF data is received, the data is sent out the DO pin.
Serial-to-RF Packetization
Data is buffered in the DI buffer until one of the following causes the data to be packetized and transmitted:
1. No serial characters are received for the amount of time determined by the RO (Packetiza-tion Timeout) parameter. If RO = 0, packetization begins when a character is received.
2. The maximum number of characters that will fit in an RF packet (100) is received.
3. The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in the DI buffer before the sequence is transmitted.
If the module cannot immediately transmit (for instance, if it is already receiving RF data), the serial data is stored in the DI Buffer. The data is packetized and sent at any RO timeout or when 100 bytes (maximum packet size) are received.
If the DI buffer becomes full, hardware or software flow control must be implemented in order to prevent overflow (loss of data between the host and module).
API Operation
API (Application Programming Interface) Operation is an alternative to the default Transparent Operation. The frame-based API extends the level to which a host application can interact with the networking capabilities of the module.
When in API mode, all data entering and leaving the module is contained in frames that define operations or events within the module.
Transmit Data Frames (received through the DI pin (pin 3)) include:
• RF Transmit Data Frame
• Command Frame (equivalent to AT commands) Receive Data Frames (sent out the DO pin (pin 2)) include:
• RF-received data frame
• Command response
• Event notifications such as reset, associate, disassociate, etc.
The API provides alternative means of configuring modules and routing data at the host applica¬tion layer. A host application can send data frames to the module that contain address and payload information instead of using command mode to modify addresses. The module will send data frames to the application containing status packets; as well as source, RSSI and payload informa¬tion from received data packets.
The API operation option facilitates many operations such as the examples cited below:
-> Transmitting data to multiple destinations without entering Command Mode -> Receive success/failure status of each transmitted RF packet -> Identify the source address of each received packet
API Support
I/O data is sent out the UART using an API frame. All other data can be sent and received using Transparent Operation [refer to p10] or API framing if API mode is enabled (AP > 0).
API Operations support two RX (Receive) frame identifiers for I/O data:
• 0x82 for RX (Receive) Packet: 64-bit address I/O
• 0x83 for RX (Receive) Packet: 16-bit address I/O
The API command header is the same as shown in the “RX (Receive) Packet: 64-bit Address” and “RX (Receive) Packet: 64-bit Address” API types [refer to p58]. RX data follows the format described in the I/O Data Format section [p12].
Applicable Commands: AP (API Enable)
Sleep Support
When an RF module wakes, it will always do a sample based on any active ADC or DIO lines. This allows sampling based on the sleep cycle whether it be Cyclic Sleep (SM parameter = 4 or 5) or Pin Sleep (SM = 1 or 2). To gather more samples when awake, set the IR (Sample Rate) parameter.
For Cyclic Sleep modes: If the IR parameter is set, the module will stay awake until the IT (Sam¬ples before TX) parameter is met. The module will stay awake for ST (Time before Sleep) time.
Applicable Commands: IR (Sample Rate), IT (Samples before TX), SM (Sleep Mode), IC (DIO Change Detect)
2.2.4. DIO Pin Change Detect
When “DIO Change Detect” is enabled (using the IC command), DIO lines 0-7 are monitored. When a change is detected on a DIO line, the following will occur:
1. An RF packet is sent with the updated DIO pin levels. This packet will not contain any ADC samples.
2. Any queued samples are transmitted before the change detect data. This may result in receiving a packet with less than IT (Samples before TX) samples.
Note: Change detect will not affect Pin Sleep wake-up. The D8 pin (DTR/Sleep_RQ/DI8) is the only line that will wake a module from Pin Sleep. If not all samples are collected, the module will still enter Sleep Mode after a change detect packet is sent.
Mounting Considerations
The XBee/XBee-PRO RF Module was designed to mount into a receptacle (socket) and therefore does not require any soldering when mounting it to a board. The XBee Development Kits contain RS-232 and USB interface boards which use two 20-pin receptacles to receive modules.
RF Module Operation
Serial Communications
The XBee/XBee-PRO OEM RF Modules interface to a host device through a logic-level asynchro¬nous serial port. Through its serial port, the module can communicate with any logic and voltage compatible UART; or through a level translator to any serial device (For example: Through a Max-Stream proprietary RS-232 or USB interface board).
Transparent Operation
By default, XBee/XBee-PRO RF Modules operate in Transparent Mode. When operating in this mode, the modules act as a serial line replacement - all UART data received through the DI pin is queued up for RF transmission. When RF data is received, the data is sent out the DO pin.
Serial-to-RF Packetization
Data is buffered in the DI buffer until one of the following causes the data to be packetized and transmitted:
1. No serial characters are received for the amount of time determined by the RO (Packetiza-tion Timeout) parameter. If RO = 0, packetization begins when a character is received.
2. The maximum number of characters that will fit in an RF packet (100) is received.
3. The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in the DI buffer before the sequence is transmitted.
If the module cannot immediately transmit (for instance, if it is already receiving RF data), the serial data is stored in the DI Buffer. The data is packetized and sent at any RO timeout or when 100 bytes (maximum packet size) are received.
If the DI buffer becomes full, hardware or software flow control must be implemented in order to prevent overflow (loss of data between the host and module).
API Operation
API (Application Programming Interface) Operation is an alternative to the default Transparent Operation. The frame-based API extends the level to which a host application can interact with the networking capabilities of the module.
When in API mode, all data entering and leaving the module is contained in frames that define operations or events within the module.
Transmit Data Frames (received through the DI pin (pin 3)) include:
• RF Transmit Data Frame
• Command Frame (equivalent to AT commands) Receive Data Frames (sent out the DO pin (pin 2)) include:
• RF-received data frame
• Command response
• Event notifications such as reset, associate, disassociate, etc.
The API provides alternative means of configuring modules and routing data at the host applica¬tion layer. A host application can send data frames to the module that contain address and payload information instead of using command mode to modify addresses. The module will send data frames to the application containing status packets; as well as source, RSSI and payload informa¬tion from received data packets.
The API operation option facilitates many operations such as the examples cited below:
-> Transmitting data to multiple destinations without entering Command Mode -> Receive success/failure status of each transmitted RF packet -> Identify the source address of each received packet
API Support
I/O data is sent out the UART using an API frame. All other data can be sent and received using Transparent Operation [refer to p10] or API framing if API mode is enabled (AP > 0).
API Operations support two RX (Receive) frame identifiers for I/O data:
• 0x82 for RX (Receive) Packet: 64-bit address I/O
• 0x83 for RX (Receive) Packet: 16-bit address I/O
The API command header is the same as shown in the “RX (Receive) Packet: 64-bit Address” and “RX (Receive) Packet: 64-bit Address” API types [refer to p58]. RX data follows the format described in the I/O Data Format section [p12].
Applicable Commands: AP (API Enable)
Sleep Support
When an RF module wakes, it will always do a sample based on any active ADC or DIO lines. This allows sampling based on the sleep cycle whether it be Cyclic Sleep (SM parameter = 4 or 5) or Pin Sleep (SM = 1 or 2). To gather more samples when awake, set the IR (Sample Rate) parameter.
For Cyclic Sleep modes: If the IR parameter is set, the module will stay awake until the IT (Sam¬ples before TX) parameter is met. The module will stay awake for ST (Time before Sleep) time.
Applicable Commands: IR (Sample Rate), IT (Samples before TX), SM (Sleep Mode), IC (DIO Change Detect)
2.2.4. DIO Pin Change Detect
When “DIO Change Detect” is enabled (using the IC command), DIO lines 0-7 are monitored. When a change is detected on a DIO line, the following will occur:
1. An RF packet is sent with the updated DIO pin levels. This packet will not contain any ADC samples.
2. Any queued samples are transmitted before the change detect data. This may result in receiving a packet with less than IT (Samples before TX) samples.
Note: Change detect will not affect Pin Sleep wake-up. The D8 pin (DTR/Sleep_RQ/DI8) is the only line that will wake a module from Pin Sleep. If not all samples are collected, the module will still enter Sleep Mode after a change detect packet is sent.