WARNING: This device complies with Part 15 of the FCC Rules. Operation is subject to the
following two conditions: (1) this device may not cause harmful interference and (2)
this device must accept any interference received, including interference that may
cause undesired operation.
LABELING R EQUIREMENTS
WARNING: The Original Equipment Manufacturer (OEM) must ensure that FCC labeling
requirements are met. This includes a clearly visible label on the outside of the
OEM enclosure specifying "Contains Transmitter Module, FCC ID: OUR24XSTREAM" as well as the FCC Notice above.
ANTENNA WARNING
WARNING: This device has been tested with Reverse Polarity SMA and MMCX connectors with
the antennas listed below. When integrated in the OEMs product, these fixed
antennas require installation preventing end-users from replacing them with nonapproved antennas. Any antenna not in the following table must be tested to comply
with FCC Section 15.203 for unique antenna connectors and Section 15.247 for
emissions.
4
24XStream™ Wireless OEM Module Manual v2.8
APPROVED ANTENNA LIST & A NTENNA SPEARATION DISTANCES
WARNING: This equipment is approved only for mobile and base station transmitting
devices, separation distances of (i) 20 centimeters or more for antennas with gains < 6
dBi or (ii) 2 meters or more for antennas with gains > 6 dBi should be maintained
between the antenna of this device and persons during operation. To ensure
compliance, operation at distances closer than this is not recommended.
The preceding statement must be included as a CAUTION statement in
manuals for OEM products to alert users on FCC RF Exposure compliance.
The 24XStream-192/96 modules are 100-milliwatt frequency hopping wireless modules that
allow wireless communication between equipment using a standard asynchronous serial data
stream. The module is half-duplex and can sustain a continuous data stream at the specified data
rate. Boasting excellent sensitivity and range, the 24XStream module is perfect for applications
such as Supervisory Control and Data Acquisition (SCADA), remote meter reading, home
automation, security, instrument monitoring, point of sale systems (POS), and countless other
applications. The 24XStream operates within the 2.4 GHz Band under Part 15 of the FCC Rules
and Regulations and is FCC approved. A regulated 5-volt supply is required for operation.
Features
• Frequency Hopping Spread Spectrum (FHSS) technology
• Noise and interference resistance
• Excellent sensitivity and range
• Several low power modes down to 1 microamp
• Standard serial digital interface
• Networking and addressing
• Simple AT command interface
Simple Product Integration
• Easy to integrate; no knowledge of RF required
• Interfaces to any microcontroller’s UART or PC Serial Port (using the MaxStream
interface board)
• Small size
• Exceptional data transfer performance
• FCC approved, no further licensing or approval necessary
Data leaving the module that is sent to the
host
Data entering the 24XStream module to be
transmitted over the air
Command mode enable
(See “Binary Command Mode” section for details.)
high
high
high
high
I PUReset modulelow
7RXLEDOIndicates good RF data receptionhigh
8
___
TX/PWR
O
PWR - Indicates module powered onhigh
___
TX - Asserted during transmission
low
Hold low during power up or reset - forces
9
_______
CONFIG
I PU*
ASCII command mode. DO NOT TIE TO
MICROPROCESSOR!
(See “Serial Port Operation” section for details.)
low
10VCC I+5 VDC11GND-Signal ground-
PU – 10kÙ Pull-Up Resistor
PD – 10kÙ Pull-Down Resistor
Frequency Range2.40 to 2.4835 GHz, unlicensed ISM Band
TypeFrequency Hopping Spread Spectrum Transceiver
Frequency ControlDirect FM
Transport ProtocolVarious Monitoring and Addressing Modes – see “Networking and
Channel CapacityHops through 25 channels. Features 7 different hop sequences.
Serial Data InterfaceAsynchronous CMOS (TTL) signals, 5V levels
Serial Interface Baud RateConfigurable from 2400-57600
Data Throughput9600 bps19200 bps
Performance
Channel Data Rate10k20k
Transmit Power Output63 mW63 mW
Rx Sensitivity-105 dBm–102 dBm
Range*Indoor: 150’ to 375’
Addressing” section
bps
*1200 bps available
Outdoor: 1.4mi. with dipole, over
12 mi. with high gain antenna
Configurable from 2400-57600
bps
Indoor: 106’ to 265’
Outdoor: 1 mi. with dipole, over
8.5 miles with high gain antenna
Power Requirements
Supply Voltage5 VDC +/-0.25V
Current ConsumptionTx – 240 mA nominal, Rx – 70 mA nominal
Power Down mode –1 microamp
Other cyclic power-down modes available – see “Low Power Modes” section
Physical Properties
Board Size1.6” x 2.85” x .35” (4.06 x 6.86 x .89) cm
Weight0.8oz (24g)
Connectors11 pin and 4 pin 0.1” spaced male Berg type headers
Operating TemperatureStandard: 0ºC to 70ºC
Industrial version: -40ºC to 85ºC available
Antennas
Antenna ConnectorMMCX Female or Reverse Polarity SMA Male
Approved AntennasIntegral wire antenna (factory installed)
1/4 wave flexible monopole
1/2 wave flexible dipole, SMA
¼ Wave Antenna MMCX½ Wave Antenna MMCX½ Wave Antenna SMA
A09-QBMM-3-P6IA09-HBMM-7-P6IA09-HASM-675
Module Part Numbers
• ‚ƒ„…
•• Operating Frequency
X09 – 900 MHz
X24 – 2.4 GHz
‚‚ Over-Air Baud Rate
009 – 9600-baud
019 – 19200-baud
ƒƒ Wire Antenna
W – Wire Antenna
N – No Wire Antenna
„„ Connector
M – MMCX Connector
S – SMA Connector
…… Temperature Rating
C – Commercial. Certified for
operation from 0º to 70º C.
I – Industrial. Conformal coated.
Certified for -40º to 85º C.
T – 100% Tested. Conformal
coated. 100% tested -40º to 85º C.
X24-009NM9600-baud, no wire mount antenna, MMCX connector
X24-009WM9600-baud, wire mount antenna, MMCX connector
X24-009NS9600-baud, no wire mount antenna, SMA connector
X24-009WS9600-baud, wire mount antenna, SMA connector
X24-019NM19200-baud, no wire mount antenna, MMCX connector
X24-019WM19200-baud, wire mount antenna, MMCX connector
X24-019NS19200-baud, no wire mount antenna, SMA connector
X24-019WS19200-baud, wire mount antenna, SMA connector
A24-P6NF6.32.40 – 2.50GHzN Female3.5” x 2.6”Wall Mount Panel
A24-P12NF122.40 – 2.485GHzN Female9.4” x 8.5”4 Element Panel
A24-P13NF12.82.40 – 2.50GHzN Female12.1”Planar Array
NOTE: If using an external antenna, the wire antenna should be removed from the 24XStream module.
Frequency Range
(MHz)
Yagi Antennas
Base Station Antennas
Dipole Antennas
2.40 – 2.50GHzMMCX
Feed
Connector
Plug
Other
LengthDescription
6”½ wave dipole
* dBd relates the dB gain of an antenna to the gain of a dipole antenna. For example, an antenna with 6dBd has 6dB
more gain than a dipole antenna, which translates to twice the range of a dipole.
The 24XStream modules come equipped with a CMOS-level asynchronous serial port. Through
this serial port, the 24XStream can communicate directly with any device having a UART
interface, or with a PC, or other RS-232 port, via the MaxStream interface board. By connecting
the 24XStream to a host device’s serial port, the host device becomes empowered to
communicate wirelessly with ease. To transmit, the host device simply sends serial data to the
24XStream and the 24XStream converts the data to spread spectrum FCC-approved wireless data.
When this spread spectrum data is detected by the receiving 24XStream module, the data is
checked for integrity and then sent to a receiving device via the serial port. This is shown in
Figure 3 below.
a.
b.
Figure 3 – Diagram of data flow from a microcontroller or PC (or any RS-232 device) through a pair
of 24XStream wireless modules to receiving microcontroller or PC. (Note: When connecting the
24XStream to an RS-232 device, the MaxStream Interface Board adjusts voltage levels between the
RS-232 device and the MaxStream wireless module.)
Serial Pins
Figure 3 above shows 4 data lines needed to interface from a microcontroller or RS-232 device to
the 24XStream modules. These four lines represent DI (Data In), DO (Data Out), *CTS, and
RTS/CMD (request to send/command mode). (All low-asserted pins are distinguished with a line
over the top of the pin name, or a ‘*’ symbol prefacing the pin name.) While the DI and DO pins
are indispensable in almost all cases, the *CTS and RTS/CMD may not be needed under certain
conditions. The following includes a brief description of each of these pins and under what
conditions the pins must be used. A brief explanation of the *CONFIG pin is also provided.
Data enters the 24XStream the DI pin as an asynchronous serial signal. The serial signal is idle
(high) when no data is being transmitted. Each data packet consists of a start bit (low), 8 data
bits, and a stop bit (high) as shown below in Figure 4.
The 24XStream modules transfer exactly 8-bits over the air. The start and stop bits from the
UART signal are not actually transmitted, but are regenerated on the receiving module before
they are sent out the serial port. This allows for the following data configurations to be sent:
• 8-bit, no parity, 1 stop bit
• 7-bit, even parity, 1 stop bit
• 7-bit, odd parity, 1 stop bit
• 7-bit, no parity, 2 stop bits
Since the 24XStream is half-duplex, it can only transmit or receive at a given time. Thus, once
the first byte is detected on the DI pin, the 24XStream immediately begins transmitting the
incoming data unless over-the-air data is already being received. In this case, the data on the DI
pin is stored in the data buffer until data is no longer being received at the antenna. If the
24XStream receives a lengthy sequence of data, the data buffer could reach its capacity (132
bytes) in which case the *CTS signal will need to be implemented (see *CTS section below).
Also, the 9600 and 19200-baud modules allow the incoming serial data to be transferred at a rate
of 2400-57600 bits/second. Serial data can be transferred to the module at a rate equal to or less
than the module’s over-the-air baud rate without any problems. However, if the serial interface
rate is set to exceed the module’s baud rate (9600 or 19200 bps respectively), *CTS must be
implemented since the data buffer may become full.
DO (Data Out) – Pin 3 (Output)
Data received from over-the-air transmissions is checked for errors and then sent to the DO pin.
____
CTS – Pin 1 (Output)
___
The CTS pin (clear to send) informs the host device whether or not serial data can be sent to the
24XStream module. When *CTS is low, serial data can be sent to the 24XStream module. All
incoming serial data is stored in a data buffer until the next data packet is transmitted (over-theair). The data buffer can hold up to 132 bytes of data. Once the data buffer contains 115 bytes,
the 24XStream module drives the *CTS signal high (de-asserts it) to alert the host device to stop
sending serial data. *CTS remains high until less than 98 bytes are in the buffer.
There are three cases in which the data buffer may become full.
1) Since the 9600 and 19200-baud modules support serial interface rates from 2400-57600
bits/second, the serial data rate could be configured at a higher rate than the module’s
over-the-air baud rate. If this happens, long serial data streams can cause the data buffer
to become momentarily full, causing *CTS to de-assert.
2) Since the 24XStream modules are half-duplex, they can either receive or transmit at a
given time. If a long string of over-the-air data is received, serial data could arrive at the
buffer and cause it to become full if the module is unable to transmit the data.
3) If any module in a network (see “Networking and Addressing”) is transmitting data, all
other modules in the network will not transmit until they finish receiving data. Thus, if
they receive serial data, their data buffers could become full.
In some applications, where none of these conditions will occur, the *CTS signal need not be
monitored.
RTS/CMD – Pin 5 (Input)
RTS
The RTS signal (request to send) is not implemented for flow control with the 24XStream
modules. All received data (over-the-air) is sent out the serial port regardless of the RTS signal.
CMD
The 24XStream comes with a variety of configurable settings including power-saving modes and
network addressing options. This pin can be used as one way to manually configure the
24XStream module as described in the “Command Mode” section. When this pin is driven high
(asserted), incoming serial data (on the DI pin) is interpreted as commands instead of data. See
the “Command Mode” section for more information.
*CONFIG – Pin 9 (Input)
The (low-asserted) *CONFIG pin is used to force the module to enter AT Command Mode.
When asserted, the serial port baud rate is temporarily set to match the default baud rate of the
24XStream module. This assures that the module will transition into AT Command Mode at a
known baud rate. Upon entering AT Command Mode, all configured parameters, including the
baud rate, remain in their saved state and can be modified as described in the “AT Command
NOTE: DO NOT tie the *CONFIG pin to an external device as it may cause problems with
module operation. The *CONFIG pin should be tied to an external switch and used manually to
enter AT Command Mode only when AT Command Mode cannot be entered under the normal
procedure (see “AT Command Mode” section).
The 24XStream wireless module features several modes of operation that allow the module to be
responsive to data and yet utilize minimum power. The figure below shows these modes and is
followed by a comprehensive look into each mode and the necessary conditions for the
24XStream module to transition from one mode to another.
Idle Mode
The 24XStream module operates in Idle Mode when there is no data being transmitted or
received. The module will transition to Transmit Mode once data is presented on the DI pin. If
valid data is detected at the antenna, the module will switch from Idle Mode to Receive Mode.
When no longer transmitting or receiving, the module returns to Idle Mode.
Transmit Mode
When the first byte arrives in the data buffer through the DI pin, the module leaves Idle Mode and
transitions to Transmit Mode. This transition happens instantaneously from the moment the first
byte of data arrives in the data buffer. In Transmit Mode, a header is sent out and is then
followed by the first data packet, which has a CRC (cyclic redundancy check) attached (see “Data
Validity” section below for more information). The first data packet contains all bytes that
accumulated in the data buffer while the header was being sent. After the first data packet is sent,
if more data is available in the buffer, another header will be sent, followed by another data
packet. This second data packet (and all subsequent data packets) will consist of data that
accumulated in the buffer while the previous data packet and header were being sent out (see
Figure 5b below). The size of each data packet can vary up to 64 bytes. This progression is
shown in Figure 5a.
Figure 5a – Transmit Mode description. Figure 5b – Generation of data packets.
Data Validity
To verify data integrity, a 16-bit cyclic redundancy check (CRC) is computed for the transmitted
data and attached to the end of each data packet before transmission. The receiver will then
compute the CRC on all incoming data. Any received data that has an invalid CRC is discarded.
Transmission Latency
The time required to send a packet of data depends on the number of bytes being sent, and the
baud rate. In addition, the modules have a synchronization timer option that can be manually
configured using the SY command as discussed in the “24XStream Command Table”. Modifying
this parameter can significantly change the transmission latency. See the “Timing Diagrams”
section for more information on transmission latencies.
A Note About Headers
As noted in Figure 5, data packets are always prefaced by a header. The header contains
information that is used by all receivers (within range) to synchronize their hopping patterns to
the transmitter. The length of the header can be reduced in some applications by eliminating the
synchronization information. See “Timing Diagrams” for more information.
Receive Mode
If over-the-air data is present at the RF receiver when the module is in Idle Mode, it will
transition to Receive Mode and start receiving packets. Once a packet is received, it goes through
a CRC (cyclic redundancy check) to ensure that the data was transmitted correctly. If the CRC
data bits on the incoming packet are invalid, the packet is discarded. If the CRC is valid, the
packet is sent to the serial port via the DO pin. This process is shown in Figure 6 below.
The module will remain in Receive Mode until an error is detected in the received data, or no
more data is detected, at which point, the module transitions to Idle Mode. If serial data was
stored in the data buffer while the module was in Receive Mode, the data will be transmitted after
the module returns to Idle Mode.
Sleep Mode
Sleep Mode enables the 24XStream module to go into a low-power state where minimal power is
consumed when the module is not in use. Once in Sleep Mode, the module will not transmit or
receive data until it first returns to Idle Mode. To enter Sleep Mode, the module must be inactive
(no data transmission or reception) for a user-defined period of time (specified by the ST
command). After this time elapses, the module transitions to Sleep Mode. By default, Sleep
Mode is disabled and must be enabled using the SM command.
The 24XStream features several Sleep Mode settings, each of which makes use of different
mechanisms to enter or leave Sleep Mode. The following table lists the different Sleep Mode
settings and the requirements to transition to and from Sleep Mode for each setting.
after a user-defined
period of module
inactivity (no
transmitting or
receiving of data).
Set by ST command.
Cyclic SleepAutomatic transition
after a user-defined
period of module
inactivity (no
transmitting or
receiving of data).
Set by ST command.
Return to Idle
Mode
Sleep CurrentConfigure these
Commands
50 mA
-
Low on SLEEP pin.<2 uASM
Any serial byte
1 mASM, ST
received on DI pin.
Periodically returns
to Idle Mode
0.5 Cyclic:
Min: 60ìA
Max: 40mA
Avg: 7.4mA
2.0 Cyclic:
Min: 60ìA
Max: 35.7mA
Avg: 2.07mA
8.0 Cyclic:
Min: 60ìA
Max: 35.56mA
Avg: 630 ìA
1.0 Cyclic:
Min: 60ìA
Max: 35.7mA
Avg: 4mA
4.0 Cyclic:
Min: 60ìA
Max: 35.7mA
Avg: 1.1mA
SM, ST, LH, HT
-
The following sections describe how each setting operates.
Pin Sleep (SM=1)
After enabling the Pin Sleep setting, the SLEEP pin (Pin 2) controls whether the 24XStream is
active or in Sleep Mode. If SLEEP is low, the module is fully operational. Once SLEEP is
driven high (asserted), the module transitions to Sleep Mode and remains in its lowest powerconsuming state until the SLEEP pin is de-asserted. The 24XStream requires 85 ms to transition
from Sleep Mode to Idle Mode. The SLEEP pin is only active if the module is set up to operate
in this mode; otherwise the pin is ignored. (See the ‘SM’ command in the “24XStream
Command Table” for more information.) Once in Pin Sleep Mode, the *CTS pin (Pin 1) is driven
high (de-asserted) to indicate that data should not be sent to the module during this time. The
TX/PWR pin (Pin 8) is driven low (de-asserted) when the module is in Pin Sleep Mode.
Serial Port Sleep (SM=2)
If this state is enabled, the module goes into Sleep Mode after a user-defined period of inactivity
(no transmitting or receiving of data). This period of time can be changed by modifying the ST
command. When the module is in Serial Port Sleep Mode, the TX/PWR pin (Pin 8) is deasserted. The module will return to Idle Mode once a character is received on the DI pin.
Cyclic Sleep (SM=3-7)
If the Cyclic Sleep setting is enabled, the 24XStream module goes into Sleep Mode after a userdefined period of inactivity (no transmission or reception on the RF channel). This user-defined
period can be set by adjusting the ST parameter (see the ‘ST’ command in “24XStream
Command Table”). The module remains in Sleep Mode for a user-defined period of time ranging
from 0.5 seconds to 8 seconds (adjustable using ‘SM’ command as described in “24XStream
Command Table” section). After this period of time, the module returns to Idle Mode and listens
for a valid data packet. If no valid data packet is found on any channel, the module returns to
Sleep Mode. If a data packet is found, the module transitions into Receive Mode and receives the
incoming packets until another ST inactivity time out. When the module is awake, it requires 100
milliseconds to search for a valid data packet.
While the module is in its low-power state, the *CTS pin (Pin 1) is driven high (de-asserted) to
indicate that data should not be sent to the module during this time. When the module awakens to
listen for data, the *CTS pin is asserted, and any data received on the DI pin will be transmitted.
The TX/PWR pin (Pin 8) is driven low (de-asserted) when the module is in Cyclic Sleep Mode.
It is asserted each time the module cycles into Idle Mode to listen for valid data packets, and then
de-asserts if the module returns to Sleep Mode.
A Note About Cyclic Scanning
Each RF packet consists of a header and data as shown previously in Figure 5b. Since the header
contains the channel synchronization information, the module must wake up during the header
portion of a packet in order to synchronize with the transmitter and receive the data. To ensure
that the 24XStream module can detect the header, a long header can be sent periodically during a
transmission. This long header repeats the synchronization information for a period of time
defined by the ‘LH’ command.
By default the long header is turned off, and must be enabled in order to communicate with a
module operating in Cyclic Sleep Mode. To enable the long header, the LH parameter must be
set to a value greater than the time of cyclic sleep to ensure accurate detection by the receiver(s).
For example, if the 24XStream is set to wake up from Sleep Mode every four seconds and check
for a packet, a transmitter would need to send a long header that is just over four seconds in
length to guarantee that the receiving module will detect the packet. (The exact timing
requirements can be found in the Timing Diagrams section.) This concept of long header length
versus Sleep Mode timing is displayed in Figure 7 below.
Figure 7a – The length of the long header is
not as long as the period of Cyclic Sleep. It is
possible for the receiver to wake and miss the
header (and the data packet) in this scenario.
Figure 7b – The length of the long header
exceeds the period of Cyclic Sleep. The
receiver is guaranteed to detect and receive the
data packet.
The long header is only sent with the initial transmitted packet after a user-defined period of
inactivity (no serial data received and no over-the-air transmitting or receiving). This period of
inactivity must be adjusted using the ‘HT’ command as described in the “24XStream Command
Table”. Sending the long header assures that the receiver will detect the new transmission and
will be able to receive the data as long as the header length slightly exceeds the cyclic sleep time.
Command Mode allows several features, including the power-down and addressing options, to be
configured. These adjustable parameters offer greater flexibility to designers in configuring the
module to fit specific design criteria. There are three ways to enter Command Mode:
1) Assert RTS/CMD and send a binary command.
2) Send the sequence “+++” to send AT commands.
3) Assert (low) the *CONFIG pin and turn the power switch off and back on. (Do not tie
*CONFIG pin to microprocessor. See “Serial Port Operation” section for details.)
Once in Command Mode, the configurable parameters can be adjusted using either AT
commands or Binary commands, as explained below. Any parameters that are changed while in
Command Mode must be saved to non-volatile memory using the WR command, or else they will
reset to their stored value upon reset or power-up.
The following sections contain a description of the AT and Binary Command Modes along with
some examples. In these examples, sent or received ASCII characters are marked in quotations.
The quotation marks should not be included when sending commands to the 24XStream modules.
Carriage Returns (ASCII character 13) will be denoted as <CR>. Also, Binary values are
represented in this document with “<” and “>” characters and are not sent as part of the actual
command. All binary values are represented as hexadecimal values (HEX) in these examples,
denoted by an “H” after the number. The actual Binary Command values must all be sent in
binary with the least significant byte (LSB) sent first followed by the most significant byte (MSB)
if the value is larger than one byte.
AT Commands
AT commands can be sent to the module using ASCII commands and parameters. A special
break sequence is used so that the module will transition into AT Command Mode. The default
sequence for entering AT Command Mode is:
- No characters sent for 1 second. (Time modified by “BT” command)
- Send 3 plus characters “+++” within 1 second. (Character modified by “CC” command)
- No characters sent for 1 second. (Time modified by “AT” command)
The 24XStream module will respond by sending an “OK<CR>”.
All AT commands are sent as follows:
“AT”2-Character
ASCII
Command
The ASCII command consists of “AT” followed by two alpha-numeric bytes, and the parameter
is a number represented as ASCII hexadecimal characters (0-9, A-F). The ASCII commands and
parameters are not case-sensitive. The optional space can be any non-alpha-numeric character.
After executing a recognized AT command, the module responds with an OK<CR>. If an
unrecognized command or a command with a bad parameter is received, the module will respond
with an ERROR<CR>. The modified value will be reset upon module power-down or reset
unless the “WR” command is issued to save the parameter to non-volatile memory.
To query the current value of a particular command, send the corresponding AT command
without any parameters (carriage return is still sent). The response will be the current value of
that command reported as a hexadecimal number.
The following example demonstrates basic AT Command functionality in the 24XStream
module.
Example:
This example will change the user-defined Module Address to 1A0D (HEX) and check the
current value of the SM command. It will also write the new Module Address to non-volatile
memory.
SendResponse
“+++”“OK<CR>”
“ATDT 1A0D<CR>”“OK<CR>”
“ATSM<CR>”“0”
“ATWR<CR>” (write to non-volatile memory)“OK<CR>”
“ATCN<CR>” (exit AT Command Mode)
Exiting AT Command Mode
There are two ways to exit the AT command mode and return to Idle Mode. If no valid AT
commands are received within the time specified by the AT Command Timeout parameter (CT
command), the module will return to Idle Mode automatically. Alternatively, the AT command
mode can be exited by sending the CN command.
Binary Commands
Binary command bytes are organized as follows:
<Command><Parameters>
– 1 byte – 2 bytes
When sending a Binary command to the 24XStream, the Command byte must be sent while the
RTS/CMD pin (Pin 5) is asserted. RTS/CMD can be de-asserted 100 microseconds after the stop
bit of the Command byte has been sent. It does not matter whether RTS/CMD is asserted when
the Parameter bytes are sent. The command will execute when all the parameters associated with
the command have been sent. If all parameters haven’t been received within 0.5 seconds the
module will return to Idle Mode. Note that when parameters are sent, they are always two bytes
long with the least significant byte sent first. When they are read, they are 1 or 2 bytes long as
indicated in the Command Table below.
Binary Command Mode allows multiple commands to be sent in sequence. When the RTS/CMD
pin is asserted, all incoming serial data will be interpreted as commands. Commands can be sent
in sequences of commands and their associated parameters. If RTS/CMD remains asserted, all
received commands will be executed by the 24XStream module. All modified parameters must
be stored in non-volatile memory by sending the WR command (08H with no parameters) before
powering down or resetting the module or the changes will be lost.
Commands can be queried for their current value by sending the command logically ORed with
the value 80H (hexadecimal) with RTS/CMD asserted. When this binary value is sent (with no
parameters) the current value of the command will be sent back, through the DO pin.
NOTE: For the 24XStream module to recognize a Binary command, the RT command must be
issued from AT Command Mode to enable binary programming. If binary programming is not
enabled, the module will not recognize when the RTS/CMD pin is asserted and will therefore not
recognize Binary Commands.
Example:
This example will set Sleep Mode to the Pin Sleep setting and store the new Sleep Mode value to
non-volatile memory. (Again, the RT command must be issued in AT Command Mode to enable
binary programming before Binary Command Mode will work.)
LH12Transmit header timeTime in tenths of seconds for
# Bytes
Returned
11
Factory
the long header.
Range: 0 – 0xFF
FH13Force header on next transmitNANANA
RE14Restore default configurationNANANA
Default
ER15Set Receive Error CountValue of error count. This
20
value is reset to 0 after every
reset it is not non-volatile
GD16Set Receive Good CountValue of good count. This
20
value is reset to 0 after every
reset it is not non-volatile
HP17Set Network number. Each
network uses a different hop
sequence. Seven different network
numbers are available.
Use this parameter to operate
independent networks of
24XStream modules in the
same vicinity.
10
Range: 0 – 6H
MK18Set Module Address MaskAddress mask. Only bits set to
1 are used in the address
2FF
FF
comparison. A global address
is an address that has the same
bits set as the address mask.
CC19Set command sequence character.Number for the command
12B
character.
Range: 20H –7FH
VR20Firmware versionNA2NA
BD21
V4.08
Set Serial Baud RateNumber corresponding to
Serial Port baud rate. Baud
rate doesn’t take affect until
ATCN command is issued. If
the baud command is issued in
binary mode it must be stored
(ATWR) and new baud rate
will take affect after reset.
1 – Binary commands are sent
when RTS/CMD is asserted.
Default
SY23
V4.12
Set Sync Timer. This time
represents the time that the
transmitter and receiver stay in
sync after receiving or sending
data. Setting this parameter to 20
(0x14) will allow any module to
transmit within the next 2 seconds
utilizing a header of 8ms instead of
35ms. Use this parameter to
reduce communication latency and
turn-around time.
The 24XStream modules utilize three levels of addressing to communicate between modules.
This networking hierarchy is depicted in Figure 8 below. Only modules with the matching
addresses are able to communicate. The three methods of addressing are: Vendor Identification
number, Networks and Module Addresses.
Figure 8 – Layout of a typical network configuration. The 24XStream features a powerful set of
networking and addressing options allowing the functionalities of complex networking systems.
Vendor Identification Number (VID)
For network security, a unique Vendor Identification number (VID) can be requested. The VID
is programmed into the 24XStream module at the factory and is stored in permanent memory.
This number can only be changed at the factory. Only modules with matching VID numbers can
communicate together. The VID addressing ensures that modules with a given VID are immune
to either transmissions or receptions with 24XStream modules with a different VID in the same
vicinity. To request a unique VID number, contact MaxStream to obtain a VID Request Form.
Networks
Within each VID, there are seven available networks. Each network utilizes a different pseudorandom hopping sequence to navigate through the shared hopping channels. In the event that two
modules from different networks collide on a channel, because they hop in a different sequence,
the two modules will jump to separate channels on the next hop. Using networks, multiple
module pairs can operate in the same vicinity with minimal interference from each other. The
network parameter is user settable using the “HP” command as described in the “24XStream
Module Addresses and Module Address Masks provide another level of addressing among
24XStream modules. Each module in a network can be configured with a 16-bit Module Address
to establish selective communications within a network. This address is set to one of 65535
values using the “DT” command. The default Module Address is 0000H.
All modules with the same Module Address can transmit and receive data among themselves.
Any modules on a network with different Module Addresses will still detect and listen to the data
in order to maintain network synchronization. However, they will not send the data out to their
serial ports if their Module Addresses don’t match the Module Address of the transmitter. (The
Module Address Mask can be used to provide exceptions to this rule as described in the following
section.
Module Address Mask
The Module Address Mask can be used as an additional method to facilitate communication
among modules. The Module Address Mask can also be set to one of 65535 possible values
using the “MK” command. The default value is FFFFH.
All transmitted data packets contain the Module Address of the transmitting module. When a
transmitted packet is received by a module, the Transmitter Module Address (contained in the
packet) is logically “ANDed” (bitwise) with the Receiver Module Address Mask. If the resulting
value matches the Receiver Module Address, or if it matches the Receiver Module Address Mask,
the packet is accepted. Otherwise, the packet is discarded. (When performing this comparison,
any “0” values in the Receiver Module Address Mask are treated as “don’t care” values and are
ignored.)
Packets with a Transmitter Module Address of FFFFH will be received by all modules as shown
below in Figure 10. A Transmitter Module Address that matches the Module Address Mask is
called a Global Address.
Figure 10 – Demonstration of Module Address comparison at receiver. FFFFH logically “ANDed”
with any Module Address Mask will equal the Module Address Mask.
The following example helps illustrate the manner in which Module Addresses are checked.
Example
Consider a Module (Module A) with Module Address of 00FFH and Module Address Mask
F0F0H as shown in Figure 11 below.
There are three different ways that Module A can receive packets from other modules.
1) This module could receive packets from other modules with a Transmitter Module
Address of 00FFH.
2) Since the Receiver Module Address Mask is set to F0F0H, logically “
with the Receiver Module Address yields “0XFX” (HEX) where the ‘X’ values can be
anything. Thus, by setting the Module Address Mask to F0F0H, this module could
receive packets from any module with a “0XFX” Module Address.
3) The module can also receive packets from any module with a Module Address that
matches the Module Address Mask of the module (F0F0H). However, since the Module
Address Mask of Module A (in this example) contains two ‘0’ values, these are don’t
care values. Hence, Module A could receive packets from any module having a
Transmitter Module Address (Global Address) of “FXFX”.
IMPORTANT: The 24XStream module has been certified as a module by the FCC for
integration into OEM products without further certification being necessary (as per FCC section
2.1091.) The OEM must satisfy the following requirements in order to comply with FCC
regulations:
1) The system integrator must ensure that the external label provided with this device is
placed on the outside of the final product.
2) In order to comply with the FCC RF exposure requirements, the 24XStream may be used
only with Approved Antennas that have been tested with this module and a minimum
separation distance of 20 cm must be maintained from the antenna to any nearby persons.
The OEM must also include a statement in the final product manual, informing users of
the requirement to maintain 20 cm separation from the antenna to any nearby persons. If
the OEM integrates the 24XStream into their final product, where the final product
utilizes a non-approved antenna or is classified as a portable device per FCC Section
2.1093 (less than 20 cm separation distance between the antenna to any nearby persons),
the OEM is responsible for obtaining a separate authorization on the final product.
Warranty
The 24XStream module from MaxStream is warranted against defects in materials and
manufacturing for a period of 90 days from the date of purchase. In the event of a product failure
due to materials or workmanship, MaxStream will repair or replace the defective product. For
warranty service, return the defective product to MaxStream for prompt repair or replacement.
MaxStream, its suppliers, and its licensors shall in no event be liable for any damages arising
from the use of or inability to use this product. This includes business interruption, loss of
business information, or other losses that may arise from the use of this product.
Use this development kit to experience the extended range
and ease of use of the MaxStream 24XStream module. This
module transmits data at either 9600 or 19200 bits per second
(see FCC label on module shield) in the license-free 2.4 GHz
ISM band. See how simple it is to communicate with the
module using asynchronous serial communications by
following the instructions below.
Contents:
224XStream Frequency Hopping modules
2Interface Boards
29 VDC power supplies
2 DB-9 straight through serial cables
1Null modem adapter
13.5" floppy disk containing file RAT.TXT
Figure 1 – MaxStream PC Interface
Board
Requirements:
2 computers with an available comm port and Windows 95/98 or
NT.
Instructions:
1. Assemble and Connect Interface Boards to computers.
a. Connect the modules to the Interface Boards by fitting
the 4 and 11-pin connectors into their respective female
headers.
b. Attach the male sides of one of the DB-9 Connecting
Cables to the female DB-9 jacks on the Interface
Boards.
c. Attach the female side of a DB-9 connecting cable to an
available RS-232 port on the back of Computer 1.
Connect Module 2 to Computer 2 in the same fashion.
d. Plug power supplies into the Interface Boards. Turn the
switch on. The red LEDs on the Interface Boards will
illuminate to show the boards are powered.
e. Refer to figure 1 for completed assembly.
2. Run and configure HyperTrm.exe on both computers
a. Open the folder on the Start Menu found under
following: Bits per second: 19200; Data bits: 8; Parity: None; Stop Bits: 1 and FlowControl: Hardware (See figure 3). Click OK. (Set the Bits per second to 9600 if you are
using 24XStream-96 modules)
e. Both computers are now set up and ready to communicate.
3. Test Connection
a. Place cursor in HyperTerminal window of Computer 1 and type a message. Notice that
text appears only in the window of Computer 2 and text typed on Computer 2 appears
only on Computer 1. This text is being transferred over the air by the 24XStream
modules.
b. Transfer the file RAT.TXT
i. On Computer 1: Select Transfer menu ->
Send File(or try right-clicking in the
HyperTerminal window). Insert the disk into
the A: drive and enter Filename:A:\RAT.TXT Select Protocol: Ymodem (See
figure 4). Press Send.
ii. On Computer 2: Select Transfer menu ->
Receive File. Select a folder in which to
place the file and select Protocol: Ymodem
(see figure 5). Press Receive.
iii. The file will begin to transfer and any errors
or retries will be accounted for. Touch the
antennas and move the modules around to
notice that errors or retries do occur under
certain circumstances.
iv. When the transfer completes, open
RAT.TXT on Computer 2 and observe the
pattern of text, it will be easy to see if any
characters were lost or corrupted.
v. Any file can be transferred this way. Use either Xmodem or Ymodem protocol.
Both computers must have the same settings.
c. Try range testing by distancing the two computers from each other. The modules can
send and receive data up to 10 miles line of sight using gain antennas.
Figure 4 – Send File Dialogue
Box
Figure 5 – Receive File
Dialogue Box
4. Problems (Trouble Shooting)
a. Can’t find the HyperTerminal on your computer?
i. Search your hard drive for HyperTrm.exeii. Download a free version from http://www.hilgraeve.com
b.Power LED doesn’t illuminate when battery clip is attached?
i. Replace the battery.
c.Cannot connect to the comm port or communication not working?
i. Try selecting another comm port by selecting Properties under the File menu.ii. If necessary test the comm ports with a null modem cable (cross RX and TX)
between the two computers to verify operation of comm ports.
d. Characters are getting scrambled?
i. Verify that both comm ports are set match the baud rate of the modules being
tested. Probably 9600 baud or 19200 bits per second. Look for the baud rate on
the FCC sticker, 96 or 192 respectively.
can be used to customize and configure the
24XStream module to meet specific needs.
AT commands are sent via a serial
communications program such as
HyperTerminal.
Binary commands – Another set of
commands used to configure the 24XStream
module. Binary commands are sent with
RTS/CMD asserted. The RT command
must be used to enable binary programming
prior to using binary commands. Multiple
Binary commands can be issued sequentially
while RTS/CMD is asserted.
Clear to send – See “CTS pin”.
CMOS logic – Logic levels used by the
24XStream module. (0-5V)
Command Mode – A mode of operation
wherein the configurable parameters of the
24XStream module can be manually
adjusted. Both Binary and AT command
modes are available.
Command table – Table containing all 23
currently implemented commands. This
table lists all of the adjustable parameters
along with a brief description of each.
CRC – See “Cyclic redundancy check”.
CTS pin – The low-asserted Clear To Send
pin (Pin 1) provides flow control for the
24XStream module. When CTS is asserted
(low), serial data can be sent to the module
for transmission. If the module is unable to
transmit the data, CTS may de-assert (high)
once the data buffer nears capacity to
prevent buffer overflow.
Cyclic redundancy check (CRC) – Used
by the 24XStream module to ensure data
integrity during transmission. A CRC is
computed on the bits to be transmitted overthe-air and sent with each data packet. The
CRC is recomputed by the receiver and
compared with the original CRC bits. The
packet is valid if the receiver CRC matches
the CRC computed by the transmitter.
Cyclic sleep – Sleep Mode setting in which
the module enters a low-power state and
awakens periodically to determine if any
transmissions are being sent.
Data buffer – Collects incoming serial data
prior to over-the-air data transmission. The
data buffer can hold up to 132 bytes at a
given time. When the buffer fills to 115
bytes, the Clear To Send (CTS) pin is deasserted to stop the flow of incoming serial
data.
Data packets – A grouping of data to be
sent over-the-air. Each data packet contains
a header and data that is collected from the
data buffer. The size of the packets varies up
to 64 bytes depending on how many bytes of
data are in the data buffer.
Data validity – Comparing received data
with transmitted data to ensure accurate
transmission. Data validity is verified by
performing a CRC check.
DI pin – All incoming serial data enters the
24XStream module on the Data In pin (Pin
4).
DO pin – All received over-the-air data
leaves the 24XStream module through the
Data Out pin (Pin 3) and can then be sent to
a microcontroller or RS-232 device.
FCC – The Federal Communications
Commission (FCC) is the US government
agency responsible for regulating radio
communications standards in the US.
Flow control – Method of determining
when serial data can be sent to the module
for over-the-air transmission. Flow control
is used to prevent buffer overflow. This can
be implemented in hardware and/or
software. Hardware flow control is
implemented in the 24XStream module
using the *CTS pin.
Frequency Hopping Spread Spectrum
(FHSS) – Method employed by the
24XStream module which involves
transmitting data over several different
channels in a specific channel hopping
sequence known by the transmitter and the
receiver(s).
Half-duplex – Radios that operate in halfduplex are able to either transmit data or
receive data at a given time, but cannot do
both simultaneously. The 24XStream is
half-duplex. When one module is
transmitting, all modules (with the same
VID) within range listen to the transmission
and will only transmit once the transmission
is complete.
Hardware flow control – See “Flow
control”.
Headers – Information that prefaces the
data bits in transmitted data packets. The
header contains information used by the
receiver(s) to synchronize to the transmitter.
HyperTerminal – A serial communications
program useful for communicating with the
24XStream module and configuring userdefined operating parameters through AT
commands.
Idle Mode – A mode of operation in which
the 24XStream module is neither
transmitting nor receiving. In Idle Mode,
the module can transition to Receive Mode
if over-the-air data is detected, Transmit
Mode if serial data is presented on the DI
pin, or Command Mode if either Binary or
AT command mode is invoked.
Industrial Temperature – Temperature
tested version of 24XStream modules
extending beyond normal operating
specifications (0ºC to 70ºC). These modules
are tested for a temperature range from
-40ºC to 85ºC.
Integration – The simple process of
dropping the 24XStream module into an
application in place of a serial cable.
Interface board – An optional board
available with the 24XStream module that
converts RS-232 level data into CMOS logic
levels. The interface board is especially
useful for developing with the 24XStream
module.
Long header – A lengthy header (length
determined by LH command) sent out to
ensure that modules running in a cyclic
sleep mode can detect the header when they
awake and synchronize to the transmission.
Low-power modes – See “Sleep Mode”.
Module Addresses – Provides a layer of
addressing among modules. Modules with
the same Module Addresses can
communicate together.
Module Address Masks – Provide a layer
of filtering to received (over-the-air) data
packets. The address (of the transmitting
module) is logically “ANDed” with the
Module Address Mask of the receiver. The
resulting value must match the Module
Address of the receiver for the packet to be
received. All “0” values are not compared.
Networks – Provides a layer above Module
Addresses for communicating between
modules. Each network has a unique
hopping sequence that allows modules on
the same network to remain synchronized to
each other.
Pin layout – Describes the layout and
functionality of all pins on the 24XStream
module.
Pin sleep – This Sleep Mode setting puts the
24XStream into a minimal power state when
the SLEEP pin is asserted. It remains in Pin
sleep until the SLEEP pin is de-asserted.
This setting must be enabled using the SM
command.
Power-saving modes – See “Sleep Mode”.
Receive Mode – A mode of operation that
receives over-the-air data and transmits all
valid data packets out to the serial port. The
module must be in Idle Mode to transition to
Receive Mode.
RS-232 logic – Standard logic levels
implemented in all RS-232 devices.
RTS/CMD – The RTS/CMD pin (Pin 5) is
used primarily to configure Binary
commands (CMD). RTS (Request to Send)
flow control is not implemented in the
24XStream module.
Sensitivity – A measurement specification
that describes how weak a signal can be (in
dBm) and still be detected by the receiver.
Serial data – Data that enters the
24XStream module through its serial port.
Serial port sleep – A Sleep Mode setting
wherein the module runs in a low power
state until data is detected on the DI pin.
This setting must be enabled using the SM
command.
Sleep Mode – A mode of operation in which
the 24XStream enters a low powerconsuming state. Several Sleep Mode
settings are available and can be configuredusing the SM command.SLEEP pin – If Pin Sleep is enabled, theSLEEP pin (Pin 2) determines if the moduleis in Sleep Mode or Idle Mode. See “Pin
Standby Mode – See “Idle Mode”.
Start bit – A low UART signal sent to
signify the beginning of an eight-bit data
sequence.
Stop bit – The last bit in a UART data
sequence. The stop bit is high and indicates
the end of an eight-bit data sequence.
Synchronization – Synchronization is used
to ensure that the transmitter and receiver
are in sync with each other and following
the same channel hopping sequence.
Transmission Latency – Time required to
send a packet of data. This value is
dependent on the number of bytes being sent
and the baud rate of the module.
Transmit Mode – Mode of operation in
which over-the-air data can be transmitted
from a module to other modules.
Transmitter. See “Serial port”.
VID – The Vendor Identification number
(VID) allows modules with the same VID to
communicate among themselves. Any
module with a different VID will not receive
their data transmissions.