Linx HumPRO Series Instruction Manual

HumPROTM Series
RF Transceiver Module
Data Guide

Table of Contents
1 Description
1 Features
2 Ordering Information
2 Absolute Maximum Ratings
3 Electrical Specications
5 Typical Performance Graphs
10 Pin Assignments
10 Pin Descriptions
12 Pre-Certied Module Pin Assignments
13 Module Dimensions
14 Theory of Operation
15 Module Description
16 Overview
18 Addressing Modes
19 Automatic Addressing
20 Acknowledgements and Assured Delivery
20 Compatibility with the 250 Series
21 Address Register Use
21 Networking
22 Transmitting Packets
23 Receiving Packets
26 Exception Engine
28 Carrier Sense Multiple Access (CSMA)
28 Using the Buffer Empty (BE) Line
29 Using the Command Response (CRESP) Line
30 Using the CMD Line
30 External Amplier Control
31 AES Encryption
32 Restore Factory Defaults
Warning: Some customers may want Linx radio frequency (“RF”)
products to control machinery or devices remotely, including machinery
or devices that can cause death, bodily injuries, and/or property
damage if improperly or inadvertently triggered, particularly in industrial
settings or other applications implicating life-safety concerns (“Life and
Property Safety Situations”).
NO OEM LINX REMOTE CONTROL OR FUNCTION MODULE
SHOULD EVER BE USED IN LIFE AND PROPERTY SAFETY
SITUATIONS. No OEM Linx Remote Control or Function Module
should be modified for Life and Property Safety Situations. Such
modification cannot provide sufficient safety and will void the product’s
regulatory certification and warranty.
Customers may use our (non-Function) Modules, Antenna and
Connectors as part of other systems in Life Safety Situations, but
only with necessary and industry appropriate redundancies and
in compliance with applicable safety standards, including without
limitation, ANSI and NFPA standards. It is solely the responsibility of any
Linx customer who uses one or more of these products to incorporate
appropriate redundancies and safety standards for the Life and
Property Safety Situation application.
Do not use this or any Linx product to trigger an action directly
from the data line or RSSI lines without a protocol or encoder/
decoder to validate the data. Without validation, any signal from
another unrelated transmitter in the environment received by the module
could inadvertently trigger the action.
All RF products are susceptible to RF interference that can prevent
communication. RF products without frequency agility or hopping
implemented are more subject to interference. This module does have
a frequency hopping protocol built in, but the developer should still be
aware of the risk of interference.
Do not use any Linx product over the limits in this data guide.
Excessive voltage or extended operation at the maximum voltage could
cause product failure. Exceeding the reflow temperature profile could
cause product failure which is not immediately evident.
Do not make any physical or electrical modifications to any Linx
product. This will void the warranty and regulatory and UL certifications
and may cause product failure which is not immediately evident.
!

––
1
Description
The HumPROTM Series is a frequency hopping
spread spectrum (FHSS) transceiver designed
for the reliable transfer of digital data. It has a
very fast lock time so that it can quickly wake
up, send data and go back to sleep, saving
power in battery-powered applications. The
module is available in the 915MHz frequency
band.
The module has several features that increase the data transfer reliability. It
ensures that no other modules are transmitting before it begins transmitting
data. Automatic acknowledgements ensure that the remote side received
valid data. Multiple hopping patterns enable several systems to operate
in proximity without interference. A standard UART interface is used for
module configuration and data transfer. A few simple serial commands are
all that are needed for configuration.
All modules have a unique 32-bit serial number that can be used as an
address. Source and destination addressing support point-to-point and
broadcast links. Address masking by the receiving module allows for
creating subnets. Other network topologies can also be implemented.
Housed in a tiny compact reflow-compatible SMD package, the transceiver
requires no external RF components except an antenna, which greatly
simplifies integration and lowers assembly costs. Versions are available that
have obtained FCC and Industry Canada modular certification.
Features
• FHSS Algorithm
• Fast Lock (<30ms at 115kbps)
• Low power modes
• FCC and IC Pre-certified version
• Simple UART interface
• No external RF components
required
• No production tuning required
• Tiny PLCC-32 footprint
HumPROTM Series
RF Transceiver Module
Data Guide
Figure 1: Package Dimensions
Revised 12/3/14
0.45"
(11.43)
0.55"
(13.97)
0.07"
(1.78)
32 Using the Low Power Features
34 The Command Data Interface
36 Writing to Registers
37 Reading from Registers
38 The Command Data Interface Command Set
75 Typical Applications
76 Usage Guidelines for FCC Compliance
76 Additional Testing Requirements
77 Information to the user
78 Product Labeling
78 FCC RF Exposure Statement
78 Antenna Selection
80 Power Supply Requirements
80 Antenna Considerations
81 Interference Considerations
82 Pad Layout
83 Microstrip Details
84 Board Layout Guidelines
85 Helpful Application Notes from Linx
86 Production Guidelines
86 Hand Assembly
86 Automated Assembly
88 General Antenna Rules
90 Common Antenna Styles
92 Regulatory Considerations
94 Notes

–– – –
23
HumPROTM Series Transceiver Specifications
Parameter Symbol Min. Typ. Max. Units Notes
Power Supply
Operating Voltage VCC 2.0 3.6 VDC
TX Supply Current lCCTX
900MHz at +10dBm 40.5 41.5 mA 1,2
900MHz at 0dBm 22 24 mA 1,2
RX Supply Current lCCRX 23.5 24.5 mA 1,2,3
Power-Down Current lPDN 0.7 6 µA 1,2
RF Section
Operating Frequency Band FCMHz
HUM-900-PRO 902 928 MHz
Number of hop channels
@ 19.2kbps RF Rate 50/64
@ 152.34kbps RF Rate 26/32
Channel spacing
@ 19.2kbps RF Rate 375.9 kHz
@ 152.34kbps RF Rate 751.81 kHz
20 dB OBW
@ 19.2kbps RF Rate 64 kHz
@ 152.34kbps RF Rate 315 kHz
Receiver BW
@ 19.2kbps RF Rate 102 kHz
@ 152.34kbps RF Rate 232 kHz
FSK deviation
@ 19.2kbps RF Rate ± 19.2 kHz
@ 152.34kbps RF Rate ± 51 kHz
Scan time / channel (avg)
@ 19.2kbps RF Rate 1.2 ms
@ 152.34kbps RF Rate 0.335 ms
FHSS Lock time
@ 19.2kbps RF Rate 63 ms
@ 152.34kbps RF Rate 26 ms
Modulation 2FSK
Data Encoding 6/7 RLL
Number of Hop Sequences 6
Electrical SpecicationsOrdering Information
Figure 2: Ordering Information
Warning: This product incorporates numerous static-sensitive
components. Always wear an ESD wrist strap and observe proper ESD
handling procedures when working with this device. Failure to observe
this precaution may result in module damage or failure.
Absolute Maximum Ratings
Supply Voltage Vcc −0.3 to +3.9 VDC
Any Input or Output Pin −0.3 to VCC + 0.3 VDC
RF Input 0 dBm
Operating Temperature −40 to +85 ºC
Storage Temperature −40 to +85 ºC
Exceeding any of the limits of this section may lead to permanent damage to the device.
Furthermore, extended operation at these maximum ratings may reduce the life of this
device.
Absolute Maximum Ratings
Figure 3: Absolute Maximum Ratings
Ordering Information
Part Number Description
HUM-***-PRO HumPROTM Series Data Transceiver
HUM-***-PRO-CAS HumPROTM Series Data Transceiver with Castellation Connection
HUM-***-PRO-UFL HumPROTM Series Data Transceiver with u.FL Connector
EVM-***-PRO HumPROTM Series Carrier Board
MDEV-***-PRO HumPROTM Series Master Development System
EVAL-***-PRO HumPROTM Series Basic Evaluation Kit
*** = Frequency; 900MHz

–– – –
45
HumPROTM Series Transceiver Specifications
Parameter Symbol Min. Typ. Max. Units Notes
Output
Logic Low, RFACTV, BE VOLM 0.3*VCC VDC 1,9
Logic High, RFACTV, BE VOHM 0.7*VCC VDC 1,9
Logic Low VOL 0.3*VCC 1,10
Logic High VOH 0.7*VCC 1,10
CRESP Hold Time 10 Bits 11
Flash (Non-Volatile) Memory Specifications
Flash Write Cycles 22,000 cycles 12
HumPROTM Series Transceiver Specifications
Parameter Symbol Min. Typ. Max. Units Notes
Receiver Section
Spurious Emissions –47 dBm
IF Frequency 304.7 kHz
Receiver Sensitivity 5
HUM-900-PRO @min rate –98 –101 dBm 5
HUM-900-PRO @max rate –91 –94 dBm 5
RSSI Dynamic Range 85 dB
CSMA RSSI Threshold –70 dBm
Transmitter Section
Output Power PO
HUM-900-PRO +8.5 +9.5 dBm 6
Harmonic Emissions PH–41 dBc 6
Output Power Range
HUM-900-PRO PH–5 9 dB 6
Antenna Port
RF Impedance RIN 50 Ω4
Environmental
Operating Temp. Range −40 +85 ºC 4
Timing
Module Turn-On Time
Via VCC 51.7 129.5 ms 4
Via POWER_DOWN 4 ms 4
Via Standby 4 ms 4
Serial Command Response
Volatile R/W 0.4 5 ms 8
NV Update 2.2 31.5 ms 8
Factory Reset 107 ms 8
Channel Dwell Time 400 ms
CMD low to trigger TX with
option TXnCMD tTXnCMD 2 ms
Interface Section
UART Data rate 9,600 115,200 bps
Input
Logic Low VIL 0.3*VCC VDC
Logic High VIH 0.7*VCC VDC
1. Measured at 3.3V VCC
2. Measured at 25ºC
3. Input power < -60dBm
4. Characterized but not tested
5. PER = 5%
6. Into a 50-ohm load
7. No RF interference
8. From end of command to start of
response
9. 60mA source/sink
10. 6mA source/sink
11. End of CMD_DATA_OUT stop bit to
change in CRESP
12. Number of register write operations
Figure 4: Electrical Specifications
Typical Performance Graphs
Figure 5: HumPROTM Series Transceiver Max Output Power vs. Supply Voltage - HUM-900-PRO
8.5
9.0
9.5
10.0
10.5
11.0
2.0 2.5 3.3 3.6
TX Output Power (dBm)
Supply Voltage (V)
85°C
25°C
-40°C

–– – –
67
15
20
25
30
35
40
-5
059
Supply Current (mA)
TX Output Power (dBm)
85°C
25°C
-40°C
Figure 6: HumPROTM Series Transceiver Average Current vs. Transmitter Output Power at 2.5V - HUM-900-PRO
20
22
24
26
28
30
32
34
36
38
40
-5
059
Supply Current (mA)
TX Output Power (dBm)
85°C
25°C
-40°C
Figure 7: HumPROTM Series Transceiver Average TX Current vs. Transmitter Output Power at 3.3V -HUM-900-PRO
36.50
37.00
37.50
38.00
38.50
39.00
39.50
40.00
2V 2.5V 3.3V
3.6V
Supply Current (mA)
Supply Voltage (V)
85°C
25°C
-40°C
Figure 9: HumPROTM Series Transceiver TX Current vs. Supply Voltage at Max Power - HUM-900-PRO
22.00
22.20
22.40
22.60
22.80
23.00
23.20
23.40
2V 2.5V 3.3V 3.6V
Supply Current (mA)
Supply Voltage (V)
85°C
25°C
-40°C
Figure 8: HumPROTM Series Transceiver TX Current vs. Supply Voltage at 0dBm - HUM-900-PRO

–– – –
89
22.5
22.7
22.9
23.1
23.3
23.5
23.7
23.9
24.1
24.3
24.5
2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6
Supply Current (mA)
Supply Voltage (V)
85°C
25°C
-40°C
Figure 10: HumPROTM Series Transceiver RX Scan Current vs. Supply Voltage, 9.6kbps - HUM-900-PRO
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
2.5 3.3 3.6
Standby Current (µA)
Supply Voltage (V)
-40°C
25°C
85°C
Figure 12: HumPROTM Series Transceiver Standby Current Consumption vs. Supply Voltage - HUM-900-PRO
-105.00
-95.00
-85.00
-75.00
-65.00
-55.00
-45.00
-35.00
-25.00
-15.00
-100.00 -90.00 -80.00 -70.00 -60.00 -50.00 -40.00 -30.00 -20.00 -10.00
0.00
RSSI Reading (dBm)
Input Power (dBm)
-40°C 25°C
85°C
Figure 13: HumPROTM Series Transceiver RSSI Voltage vs. Input Power - HUM-900-PRO
21
21.2
21.4
21.6
21.8
22
22.2
22.4
22.6
22.8
23
2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6
Supply Current (mA)
Supply Voltage (V)
85°C
25°C
-40°C
Figure 11: HumPROTM Series Transceiver RX Scan Current vs. Supply Voltage, 115.2kbps - HUM-900-PRO
Current consumption while the module is scanning for a transmission. The current is
approximately 0.5mA higher when receiving data at 9.6kbps.
Current consumption while the module is scanning for a transmission. The current is
approximately 2mA higher when receiving data at 115.2kbps.

–– – –
10 11
Pin Assignments
30
31
32
1
2
3
4
20
19
18
17
16
15
14
56789 10 11 12 13
29 28 27 26 25 24 23 22 21
ANT
GND
GND
GND
GND
GND
GND
BE
RFACTV
NC
NC
NC
NC
NC
NC NC
CRESP
EX
NC NC
GND
CMD
POWER_DOWN
CTS PB CMD_DATA_IN CMD_DATA_OUT LNA_EN PA_EN GND VCC RESET
Figure 14: HumPROTM Series Transceiver Pin Assignments (Top View)
Pin Descriptions
Pin Number Name I/O Description
1, 2, 3, 4, 5,
6, 10, 11, 32 NC — No Electrical Connection. Do not connect any traces to these lines.
7 CRESP O
Command Response. This line is low when
the data on the CMD_DATA_OUT line is
a response to a command and not data
received over the air.
8 EX O
Exception Output. A mask can be set
to take this line high when an exception
occurs. The line is lowered when the
exception register is read (EXCEPT).
9, 14, 15, 16,
17, 18, 20, 25 GND — Ground
12 POWER_DOWN I
Power Down. Pulling this line low places the
module into a low-power state. The module
is not functional in this state. Pull high for
normal operation. Do not leave floating.
Pin Descriptions
Pin Number Name I/O Description
13 CMD I
Command Input. When this line is low,
incoming bytes are command data.
When high, incoming bytes are data to be
transmitted.
19 ANTENNA — 50-ohm RF Antenna Port
21 VCC — Supply Voltage
22 RESET I
This line resets the module when pulled low.
It should be high for normal operation. This
line has an internal 10k resistor to supply, so
leave it unconnected if not used.
23 LNA_EN O
Low Noise Amplifier Enable. This line is
driven high when receiving. It is intended to
activate an optional external LNA.
24 PA_EN O
Power Amplifier Enable. This line is driven
high when transmitting. It is intended to
activate an optional external power amplifier.
26 CMD_DATA_OUT O Command Data Out. Output line for data
and serial commands
27 CMD_DATA_IN I Command Data In. Input line for data (CMD
is high) and serial commands (CMD is low).
28 CTS O
UART Clear To Send, active low. This line
indicates to the host microcontroller when
the module is ready to accept data. When
CTS is high, the module is busy. When CTS
is low, the module is ready for data.
29 PB I
Reset non-volatile memory. A sequence
of 4 high pulses on this line, followed by a
prolonged high state causes the module
to reset the non-volatile configuration
parameters to factory default values.
30 RFACTV O
RF Packet Transfer. This line goes high
when the module is transmitting a packet,
receiving a potentially valid packet or when
the PB line is high
31 BE O
Buffer Empty. This line is high when the
UART input buffer is empty, indicating
that all data has been transmitted. If
acknowledgment is active, it also indicates
that the receiving module has acknowledged
the data or a retry exception has occurred.
Figure 15: HumPROTM Series Transceiver Pin Descriptions
Pin Descriptions

–– – –
12 13
Pre-Certied Module Pin Assignments
The pre-certified version of the module has mostly the same pin
assignments as the standard version. The antenna connection is routed to
either a castellation (-CAS) or a u.FL connector (-UFL), depending on the
part number ordered.
The antenna =pad is disconnected on the version with the connector. The
RF is routed as shown in Figure 16 for the version without the connector.
30
31
32
1
2
3
4
19 18
56789 10 11 12 13
29 28 27 26 25 24 23 22 21
ANT GND
BE
RFACTV
NC
NC
NC
NC
NC
NC NC
CRESP
EX
NC NC
GND
CMD
POWER_DOWN
CTS PB CMD_DATA_IN CMD_DATA_OUT LNA_EN PA_EN GND VCC RESET
0.45"
(11.43)
0.812"
(20.62)
0.116"
(2.95)
Figure 16: HumPROTM Series Transceiver Pre-certified Version Pin Assignments (Top View)
Module Dimensions
Figure 17: HumPROTM Series Transceiver Dimensions
0.45"
(11.43)
0.55"
(13.97)
0.07"
(1.78)
Figure 18: HumPROTM Series Transceiver Pre-certified Version Dimensions

–– – –
14 15
Theory of Operation
The HumPROTM Series transceiver is a low-cost, high-performance
synthesized FSK / MSK transceiver. Figure 19 shows the module’s block
diagram.
The HumPROTM Series transceiver operates in the 902 to 928MHz
frequency band. The transmitter output power is programmable. The
range varies depending on the antenna implementation and the local RF
environment.
The RF carrier is generated directly by a frequency synthesizer that includes
an on-chip VCO. The received RF signal is amplified by a low noise
amplifier (LNA) and down-converted to I/Q quadrature signals. The I/Q
signals are digitized by ADCs.
A low-power onboard communications processor performs the radio
control and management functions including Automatic Gain Control
(AGC), filtering, demodulation and packet synchronization. A control
processor performs the higher level functions and controls the serial and
hardware interfaces.
A crystal oscillator generates the reference frequency for the synthesizer
and clocks for the ADCs and the processor.
PA
LNA
0
90
FREQ
SYNTH
ADC
ADC
DEMODULATOR
MODULATOR
ANTENNA PROCESSORGPIO /
INTERFACE
INTERFACE
Figure 19: HumPROTM Series Transceiver RF Section Block Diagram
Module Description
The HumPROTM Series module is a completely integrated RF transceiver
and processor designed to transmit digital data across a wireless link.
It employs a fast-locking FHSS system for noise immunity and higher
transmitter output power as allowed by government regulations.
When the module does not have data to send it scans all of the channels
for incoming data. If it finds a valid preamble, it pauses and looks for
the start of a packet. When it receives a valid packet with a matching
destination address the module outputs the data through the UART.
The transmitting module accepts packets through its UART until a
configurable number of bytes is reached or a configurable timeout expires
between bytes on the UART. At this point the module transmits the packet.
When the module has data to send it goes to the next channel in its
hopping pattern. It measures the RSSI on that channel to ensure that the
channel is clear. If the RSSI check passes, then it transmits the packets. If
the RSSI fails, then it implements a random wait time and tries again. When
the channel is clear, the module transmits the data.
The module can stay on one channel for up to 400ms. If the module is
ready to start transmitting near the end of the channel time, it transmits the
number of bytes that it can in the remaining time. It then hops to the next
channel in its hopping pattern to transmit the remaining data.
The module supports automatic acknowledgements for assured delivery.
When enabled, the receiving module responds to a valid transmission with
an acknowledgement to let the transmitting module know that it received
the data. If an acknowledgement is not received then the transmitting
module repeats the transmission for a configurable number of retries. If the
retry limit is exceeded without an acknowledgement then the transmitting
module issues an exception error to let the host micro know of the
communication problem.
A standard UART interface is used to configure the module for operation
and for the data input and output. This is suitable for direct connection to
UARTs on many microcontrollers, USB converters and RS-232 converters.
A simple command set is used for configuration and control.
Modules can be pre-configured for fixed point-to-point or broadcast
topologies allowing streaming data (no commands) during operation.

–– – –
16 17
Overview
The HumPRO Series RF transceiver module offers a number of features
that make it suitable for many data transfer applications. This section
provides a basic overview of the features while following sections dive into
them in more detail.
Addressing
The modules have a very powerful addressing method. Each module is
given a unique 16 or 32 bit address. The receiving modules use an address
mask that determines how it responds to a received transmission.
The addressing and masking allow for the creation of point-to-point,
many-to-one and one-to-many wireless links. This allows the creation of
many network topologies, such as star, tree and mesh. The routing for the
network topology is managed outside the module.
The addressing is the primary configuration when getting started with the
modules. RG-00105, the HumPRO Addressing Mode Reference Guide has
details about configuring the addressing.
Acknowledgements and Assured Delivery
The modules support assured delivery in the form of acknowledgements
and retries. When the acknowledgements are enabled, the receiving
device sends an acknowledge message to let the sender know that the
transmission was received. If the sender does not get an acknowledgement
it resends the message up to a configurable number of retries. If there is
still no acknowledgement, the module triggers an exception to let the host
processor know of the error.
Command Mode and Data Mode
The module has two main interface modes controlled by the state of the
CMD line. Command mode routes the data coming in on the CMD_DATA_
IN line to the processor for configuring the module. Data mode routs
the data to the transmitter for transmission over-the-air. The CMD line is
normally controlled by an external microcontroller.
Carrier Sense Multiple Access (CSMA)
The module implements a Carrier Sense Multiple Access method. It
listens to the channel and makes sure that it is clear before it transmits. If
the channel is in use, the module waits for it to clear or hops to the next
channel if the channel time expires. This reduces the overall potential for
interference and improves the robustness of the link.
Streaming Data and Explicit Packets
The module’s default configuration is for streaming data. In this operation
the module sends the data at a higher rate over-the-air than it is input on
the UART. This hides the time required for the protocol transactions and the
frequency hopping. The result is that the data appears to stream through
the module with no breaks in the data apparent to the host processor.
Alternatively, the module can be configured for explicit packet transmission.
This allows the host processor to control when packets are sent and what
data is in each packet
Exceptions and Host Processor Interface
The module has several indicator lines that provide feedback to the host
processor on the module’s operation and current status. This includes an
exception engine that informs the processor when errors occur so that it
can take steps to manage the issue gracefully. The state of the status lines
can also be read through the module’s Command Data Interface to reduce
the number of hardware connections that are required.
Encryption
The module supports AES-128 encryption to provide a secure wireless link.
All of the modules must have encryption enabled and be using the same
key in order for communication to be successful. There are two ways of
entering an encryption key: directly by writing the key to registers through
the Command Data Interface or through a pairing operation.
Encryption is not yet enabled on the initial release of HumPRO modules.
Command Data Interface
The module has a Command Data Interface that consists of a set of serial
commands entered through a UART. These are shorter and simpler than AT
commands that are popular with many modules. These commands control
the configuration of the module as well as allow feedback on the operation
and status of the module.

–– – –
18 19
Addressing Modes
The module has very flexible addressing schemes selected with the
ADDMODE register. It can be changed during operation. The transmitting
module addresses packets according to the addressing mode
configuration. The receiving module processes all addressing types
regardless of the ADDMODE configuration. If the received message
matches the addressing criteria, it is output on the UART. Otherwise it is
discarded. The ADDMODE configuration also enables assured delivery.
There are three addressing modes: DSN, User and Extended User. Each
mode offers different communications schemes, but all use source and
destination addressing. The source address is for the transmitting unit,
the destination address is the intended receiver. Each mode uses different
registers for the source and destination addresses.
All three addressing modes can be configured to be compatible with the
older 250 Series modules. The default operation has an additional level
of masking on the receiving module that helps prevent interference from
adjacent networks.
The following sections give brief descriptions of the three modes, but a
detailed explanation and examples are given in RG-00105, the HumPROTM
Addressing Mode Reference Guide.
DSN Addressing Mode
Device Serial Number Addressing mode is the simplest mode and
supports point-to-point communications. Each module is programmed at
the factory with a unique 4-byte serial number that cannot be changed.
These bytes are found in the non-volatile read-only MYDSN registers
(MYDSN[3-0]). DSN Addressing mode uses this serial number as an
address. The transmitting unit’s DSN is used as the source address and
the intended receiver’s DSN is written into the destination address registers
(DESTDSN[3-0]). All modules within range hear the transmission, but only
the module with the serial number that matches the destination address
outputs the data on its UART. All others ignore the transmission.
User Addressing Mode
User Addressing Mode is a more flexible method than DSN Addressing
Mode. It uses the customer ID bytes (CUSTID[1-0]) and two of the user
destination bytes (UDESTID[1-0]) as a destination address. The customer
ID bytes are programmed at the factory and cannot be changed. These are
determined by the factory for specific customers to prevent their systems
from operating with any other systems. Contact Linx for more details.
The module’s local address is contained in two of the user source ID
registers (USRCID[1-0]). In this mode, USRCID [1-0] contain the node
address and USRCID [3-2] must be 0 in the receiver.
In normal operation each module has a user ID mask (UMASK[3-0]) that
splits the 32 address bits into three fields to provide a network address and
address fields for sub-networks, supporting both individual addressing and
broadcast addressing within the user’s network. A detailed explanation and
examples are given in Reference Guide RG-00105. This mode only uses
the 16 bits in the USRCID[1-0] registers, but the mask includes the 16 high
order 0 bits in USRCID[3-2].
If acknowledgements are enabled, only the module with a user source ID
that exactly matches the transmitted user destination ID responds. The
mask is not used for this determination.
Extended User Addressing Mode
Extended User Addressing mode is the same as User Addressing
mode but uses 32-bit addresses. The two customer ID bytes are still
used (CUSTID[1-0]) but four bytes are used for the user destination
address (UDESTID[3-0]), user source ID (USRCID[3-0]) and user ID mask
(UMASK[3-0]). This provides more addressing capabilities at the expense of
more overhead in the packet.
Automatic Addressing
The module supports an automatic addressing mode that reads the Source
Address from a valid received packet and uses it to fill the Destination
Address register. This makes sure that a response is sent to the device that
transmitted the original message. This also allows the host microcontroller
to read out the address of the sending unit. The automatic addressing is
enabled for the different addressing modes with register AUTOADDR.

–– – –
20 21
Acknowledgements and Assured Delivery
When a module transmits with assured delivery enabled, the receiving
module returns an acknowledgement packet. The transmitting module
waits for this acknowledgement for a preset amount of time based on the
data rate. If an acknowledgement is not received, it retransmits the packet.
If the receiver receives more than one of the same packet, it discards
the duplicate packet contents but sends an acknowledgment. This way,
duplicate data is not output by the module.
If the received destination address matches the local address, the
receiving module immediately sends an acknowledgement. This packet
lets the sending module know that the message has been received.
An acknowledgement packet is sent immediately following reception;
CSMA delay is not applied to these packets since permission belongs
to the interacting modules. When the sending module receives the
acknowledgement packet, it marks the current block of data as completed.
If this is the last message in the queue, the sending module takes the BE
line high to indicate that all outgoing data has been sent.
Assured delivery should only be used when addressing a specific module
in a point-to-point link. It should not be used when multiple receivers are
enabled. When address masking is used, only the receiver with an exact
match to the address in the transmitted packet responds. If none of the
enabled receivers has an exact match, then there is no response and the
transmitting module continues to re-transmit the data until the max number
of retries is attempted. This causes the transmitting module to appear slow
or unresponsive. It also impedes valid communications.
Compatibility with the 250 Series
When DSN mode is used with a specific address, the module can
communicate with 250 Series modules at UART data rates of 38,400
to 115,200 bps. For other addressing modes, the HumPROTM Series
modules can be configured to operate with them. Setting the COMPAT
register to 0x00 enables the compatible operation. This allows mixed-mode
systems and upgrades of legacy products that still maintain backwards
compatibility. Only the higher baud rates are compatible.
The main feature of compatibility operation is that it configures the same
addressing methods used by the 250 Series. These methods are more
susceptible to interference from adjacent networks of 250 Series modules
which use DSN (GUI) broadcast messages. Please see Reference Guide
RG-00105 for more details.
Address Register Use
Figure 20 shows the address registers that are used with each addressing
mode.
Networking
The HumPROTM Series modules can be used to create many types of
wireless networks. The modules do not provide network routing since the
internal memory size of the module would limit the overall network size. The
HumPROTM can work as the MAC/PHY layers of a network stack and the
memory and processing speed of the external microcontroller can be sized
according to the size of the network that is needed for the application.
This requires more software development, but avoids the cost of adding
extra memory on the module for applications that don’t need it. Linx can
assist with network frameworks and concepts and can create custom
designs on a contract basis. Contact Linx for more details.
Figure 20: HumPROTM Series Transceiver Address Register Use
HumPROTM Series Transceiver Address Registers
COMPAT 0x00 (Relaxed Addressing) 0x02 (Normal Addressing)
ADDMODE
0x04
(DSN)
0x06
(User)
0x07
(Ex User)
0x04
(DSN)
0x06
(User)
0x07
(Ex User)
0x14
(DSN
+ACK)
0x16
(User
+ACK)
0x17
(ExUser
+ACK)
0x14
(DSN
+ACK)
0x16
(User
+ACK)
0x17
(ExUser
+ACK)
UDESTID[3-0] X X
UDESTID[1-0] X X
USRC[3-0] X X X
USRC[1-0] X
UMASK[3-0] X X X
UMASK[1-0] X
DESTDSN[3-0] X X

–– – –
22 23
Transmitting Packets
In default operation when transmitting, the host microcontroller writes bytes
to the CMD_DATA_IN line while the CMD line is held high at the baud rate
selected by the UARTBAUD register. The incoming bytes are buffered until
one of four conditions triggers the packet to be transmitted:
1. The number of bytes in the buffer exceeds the value in the Byte Count
Trigger (BCTRIG) register.
2. The time since the last received byte exceeds the value in the Data
Timeout (DATATO) register.
3. A SENDP command is written to the CMD register.
4. The number of buffered bytes exceeds what can be sent before the
radio must hop channels.
The first three conditions can be controlled by the host microcontroller. In
the last case, the module transmits what it can in the remaining time then
sends the rest on the next channel. This can cause the data to be divided
up into multiple packets and is not within the control of the host micro.
In cases where it is desired for all data to be sent in the same packet or
where the microcontroller needs a greater level of control over the radio,
the HumPROTM offers explicit control of packet transmission through
options in the PKTOPT register.
When the TXPKT option is enabled (PKTOPT register, bit 0 = 1), the data is
held until a SENDP command is written to the CMD register. Alternatively, if
option TXnCMD is enabled (PKTOPT register, bit 1 = 1), then lowering the
CMD line triggers the packet transmission, reducing the number of UART
transactions that are required. The BCTRIG and DATATO conditions are
ignored when these options are enabled.
Once triggered, the transmitted packet contains the bytes in the buffer as
of the trigger event, even if more data bytes are received before the packet
can be sent. Multiple outgoing packets can be buffered in this way.
If the full packet cannot be sent in the time remaining on the current
channel, then it is held until the module hops to the next channel.
This option gives the host microcontroller very fine control over when
packets are transmitted and what they contain.
Receiving Packets
In default operation when receiving packets, the module outputs all
received bytes as soon as the packet is validated (CRC checks pass) and
if the addressing permits it at the baud rate selected by the UARTBAUD
register. No command or control bytes are output and no action is required
of an external microcontroller. The first byte from a packet directly follows
the last byte of the previously received packet.
In cases where the host microcontroller needs more control over the data
or where dynamic configuration changes could set up race conditions
between incoming data and outgoing commands, the module offers
explicit control over received packets.
When the RXPKT option is enabled (PKTOPT register, bit 2 = 1), received
data is output on the CMD_DATA_OUT line one packet at a time when a
GETPH, GETPD, or GETPHD command is written to the CMD register.
Writing one of these commands begins the received packet transfer cycle.
Two lines are used as flow control and indicators during the transfer cycle.
The CMD line is controlled by the host microcontroller. The module uses
either the CTS line or the CRESP line as a status line, depending on the
state of the RXP_CTS option in the PKOPT register.
When a valid packet is received, the EX_RXWAIT exception flag is set in
the EEXFLAG1 register. If the corresponding bit in the EEXMASK1 register
is set, then the EX line goes high. The host microcontroller can monitor
the EX line or periodically check the EEXFLAG or LSTATUS registers to
determine if data is ready to be read.
The transfer cycle is begun by writing a Get Packet Header (GETPH),
Get Packet Data (GETPD), or Get Packet Header and Data GETPHD
command to the CMD register. The module sends the command ACK byte
and sets the selected status line high. Once the status line goes high, the
host microcontroller sets the CMD line high and the module outputs the
received data. The command sent determines whether the bytes sent are
the header, data, or header followed by data.
When all packet bytes have been sent the control line goes low. When
the host microcontroller detects that the line is low, it sets CMD low,
completing the transfer cycle. The cycle is shown in Figure 21.

–– – –
24 25
The Sequence byte is incremented for each new packet, modulo 255. A
received packet is discarded if the sequence byte matches the previously
received packet to prevent delivering duplicate copies of an automatically
retransmitted packet.
The Cust ID field is a number that can be assigned to a specific customer.
Only modules with the same customer ID respond to transmissions. By
default, Cust ID is 0x7FFF for packets transmitted with COMPAT = 2 or
0xFFFF for packets transmitted with COMPAT = 0.
The Dest Addr field has the received destination address. This is 2 bytes
long with User Addressing Mode and 4 bytes with DSN and Extended User
Addressing Modes.
The Source Addr Field is the address of the transmitting module. This
is 2 bytes long with User Addressing Mode and 4 bytes with DSN and
Extended User Addressing Modes.
The Data Length byte indicates how many bytes of data are in the packet.
This value is the same in the packet header and the associated data.
If a GETPH was sent and header data received, the following data can
then be read by repeating the cycle with the GETPD command. If the next
GETPx command is a GETPH or GETPHD, the data associated with the
header read by GETPH is discarded and the header or header plus data of
the following packet is returned.
If there is RF-received data waiting to be sent to the UART and the mask
for EX_RXWAIT is set in the EEXMASK register, EX is raised if it is low.
If there is no packet waiting when a GETPx command is sent, the control
line is still taken high and not reset until after CMD goes high, thereby
performing a zero-byte transfer cycle.
Although not part of the normal packet transfer, if CMD is set low while the
control line is high (received packet transfer in progress), data transmission
stops, the control line goes low, and the module processes and responds
to incoming commands. If CMD is again taken high, the control line is
raised and the packet transfer continues where it left off. This gives the host
microcontroller very fine control over when received packets are output and
how much data needs to be managed.
The header and data structures for explicit packets are shown in Figure 22.
The Tag field identifies the start of the block and if it is the header
information (0x01) or the packet data (0x02).
The Header Length field identifies the number of header bytes that follow.
The Frame Type field identifies what kind of packet was received. The
values are shown in Figure 23.
The Hop ID field is the hop sequence number, 0 - 5.
CMD
CMD_DATA_IN
CMD_DATA_OUT
CONTROL
EX
Packet In
Exception for unread packet
Read Packet Command
ACK Packet to UART
Any Command
Any Response
Figure 21: HumPROTM Series Transceiver Received Packet Transfer Cycle
Tag
0x01
Frame
Type
1
Header
Length
1
Hop ID
1
Sequence
1
Dest DSN
4
Source
DSN
4
Data
Length
1
DSN Address Packet Header
Packet Data
Tag
0x02
Data
Data Length Bytes
Data
Length
1
Tag
0x01 1
Header
Length
1
Hop ID
1
Sequence
1
Cust ID
2
Dest Addr
2 or 4
Source
Addr
2 or 4
Source
DSN
4
User Address Packet Header
Data
Length
1
Frame
Type
Figure 22: HumPROTM Series Transceiver Packet Header and Data Structure
HumPROTM Series Transceiver Frame Types
Exception Mask Exception Name
0x04 DSN Addressing Mode
0x14 DSN Addressing with Acknowledgement
0x06 User Addressing Mode
0x16 User Addressing with Acknowledgement
0x07 Extended User Addressing Mode
0x17 Extended User Addressing with Acknowledgement
Figure 23: HumPROTM Series Transceiver Frame Types

–– – –
26 27
Exception Engine
The HumPROTM is equipped with an internal exception engine to notify the
host microcontroller of an unexpected event. If errors occur during module
operation, an exception is raised. There are two methods of driving the EX
pin when an exception condition exists:
1. From the EXMASK and EXCEPT registers (legacy operation)
2. From the EEXMASKx and EEXFLAGx registers (standard operation)
If EXMASK is non-zero, the first method is used, otherwise the second
method is used.
For legacy operation with the 250 and 25 Series, the EX line is set and
reset by the Exception (EXCEPT) register processing. It is set when
an exception occurs and the exception code ANDed with the current
Exception Mask (EXMASK) register is non-zero. It is reset when the
EXCEPT register is read through a command. No other operations affect
the state of EX. Setting EXMASK non-zero does not change the state of
EX.
If an exception code is already present in the register when an error occurs,
the new exception code overwrites the old value. Exception codes are
organized by type for ease of masking. Figure 24 lists the exception codes
and their meanings.
HumPROTM Series Transceiver Exception Codes
Exception Code Exception Name Description
0x08 EX_BUFOVFL Incoming UART buffer overflowed.
0x09 EX_RFOVFL Outgoing UART buffer overflowed.
0x13 EX_WRITEREGFAILED Attempted write to register failed.
0x20 EX_NORFACK Acknowledgement packet not received
after maximum number of retries.
0x40 EX_BADCRC Bad CRC detected on incoming packet.
0x42 EX_BADHEADER Bad CRC detected in packet header.
0x43 EX_BADSEQID Sequence ID was incorrect in ACK packet.
0x44 EX_BADFRAMETYPE
Attempted transmit with Invalid setting in
reg:NETMODE or invalid packet type in
received packet header
Figure 24: HumPROTM Series Transceiver Exception Codes
The EX line can be asserted to indicate to the host that an error has
occurred. The EXCEPT register must be read to reset the line. Figure 25
lists some example exception masks.
The exception mask has no effect on the exceptions stored in the
exception register. It only controls which exceptions affect the EX line.
The extended exception registers offer more functionality with more
exceptions and a separate bit for each exception. These registers are the
default and should be used with new applications.
The EX line is set and reset by the Extended Exception Flags (EEXFLAG)
and Extended Exception Mask (EEXMASK) register processing. It is set
whenever the EEXFLAG value ANDed with the EEXMASK value is non-zero.
EX can change on any write to either of these registers that affects the
result of ANDing the registers. Clearing an EEXFLAG register bit or value
can leave EX set if there is another masked condition bit set.
The state of the EX line can also be read in the LSTATUS register, reducing
the number of hardware lines that are required.
HumPROTM Series Transceiver Example Exception Masks
Exception Mask Exception Name
0x08 Allows only EX_BUFOVFL and EX_RFOVFL to trigger the EX line
0x10 Allows only EX_WRITEREGFAILED to trigger the EX line
0x20 Allows only EX_NORFACK to trigger the EX line
0x40 Allows only EX_BADCRC, EX_BADHEADER, EX_BADSEQID and
EX_BADFRAMETYPE exceptions to trigger the EX line
0x60
Allows EX_BADCRC, EX_BADHEADER, EX_BADSEQID, EX_
BADFRAMETYPE and EX_NORFACK exceptions to trigger the EX
line
0xFF Allows all exceptions to trigger the EX line
Figure 25: HumPROTM Series Transceiver Example Exception Masks

–– – –
28 29
Carrier Sense Multiple Access (CSMA)
CSMA is an optional feature. It is a best-effort delivery system that listens
to the channel before transmitting a message. If CSMA is enabled and
the module detects another transmitter on the same channel, it waits until
the active transmitter finishes before sending its payload. This helps to
eliminate RF message corruption and make channel use more efficient.
When a module has data ready to transmit and CSMA is enabled, it listens
on the intended transmit channel for activity. If no signal is detected,
transmission is started.
If a carrier is detected with an RSSI above the CSMA threshold in the
CRSSI register, transmission is inhibited. If a signal below the threshold is
detected that has a compatible preamble or packet structure, transmission
is also inhibited.
In these cases, the module waits for a random interval, then checks again
for activity. If no activity is detected after waiting, it starts transmitting.
If the detected carrier lasts longer than the time allowed for the current
channel, the module hops to the next channel in the hop sequence and
again waits for a clear channel before transmitting.
Using the Buffer Empty (BE) Line
The BE line indicates the state of the module’s UART buffer. It is high to
indicate that the UART input buffer is empty, indicating that all data has
been transmitted. When the module receives data in the CMD_DATA_IN
line and the CMD line is high, the BE line is lowered until all data in the
buffer has been processed by the protocol engine. If acknowledgement is
not enabled, the BE line is raised as soon as the protocol engine processes
the outgoing packets. If acknowledgement is enabled, the buffer is not
updated until either the data transmissions are acknowledged by the
remote end or delivery fails after the maximum number of retries. When
the BE line returns high, the EX line may be sampled, or the EXCEPT
or EEXFLAG register polled to determine if an error occurred during
transmission.
The state of the BE line can be read in the LSTATUS register, reducing the
number of hardware connections that are needed.
Using the Command Response (CRESP) Line
The CRESP line is normally high, but the module lowers this line when
responding to a UART command. This indicates to an external host
microcontroller that the data on the CMD_DATA_OUT line is a response
to a command and not data received over-the-air. CRESP is held in the
correct state until one byte time after the last byte for the indicated source
(command response or data).
The module normally outputs received RF data immediately following the
command response. The CRESP line does rise before resuming RF data,
but some microcontrollers cannot react quickly enough to this signal and
may not able to separate the command responses from RF data.
When configuring the module’s register settings, it is possible for incoming
RF data to intermix with the module’s response to a configuration
command. This can make it difficult to determine if commands were
successfully processed as well as to capture the received RF data. Setting
the CMDHOLD register to 0x01 causes the module to store incoming
RF traffic (up to the RF buffer capacity) while the CMD line is low. When
the CMD line is returned high, the module outputs the buffered data on
the UART. This allows the external host microcontroller to have separate
configuration times and data times instead of potentially having to handle
both at once.
The CRESP line stays low for ten bit times after the stop bit of the last
command response. Figure 26 shows the timing.
CMD_DATA_OUT
CRESP
0xFF ...D6D710 bit
times
Stop
Figure 26: HumPROTM Series Transceiver CRESP Line Timing

–– – –
30 31
Using the CMD Line
The CMD line informs the module where incoming UART data should be
routed. When the line is high, all incoming UART data is treated as payload
data and is routed to the transmitter to be sent over the air. If the CMD line
is low, the incoming UART data is treated as commands and is routed to
the controller for processing.
Since the module’s controller looks at UART data one byte at a time, the
CMD line must be held low for the entire duration of the command plus
time for ten bits as margin for processing. Leaving the line low for additional
time (for example, until the ACK byte is received by the application) does
not adversely affect the module. If RF packets are received while the CMD
line is active, they are still processed and output on the module’s UART.
Figure 27 shows this timing.
Commands can be entered sequentially without having to raise the CMD
line after each one. The CMD line just needs to be raised to be able to
enter data for transmission.
If the CMDHOLD register is 0x01 then any received data is held until the
CMD line is raised. This prevents received data from being intermingled
with command responses.
External Amplier Control
The HumPROTM Series transceiver has two output lines that are designed
to control external amplifiers. The PA_EN line goes high when the module
activates the transmitter. This can be used to activate an external power
amplifier to boost the signal strength of the transmitter. The LNA_EN line
goes high when the module activates the receiver. This can be used to
activate an external low noise amplifier to boost the receiver sensitivity.
These external amplifiers can significantly increase the range of the system
at the expense of higher current consumption and system cost.
The states of the PA_EN and LNA_EN lines can be read in the LSTATUS
register. This offers a quick way to determine what state the radio is in.
CMD_DATA_IN
CMD
0xFF ... D6 D7
≥10 bit
times
Stop
Figure 27: HumPROTM Series Transceiver CMD Line Timing
AES Encryption
Encryption algorithms are complex mathematical equations that use a
number, called a key, to encrypt data before transmission. This is done
so that unauthorized persons who may intercept the transmission cannot
access the data. In order to decrypt the transmission, the decoder must
use the same key that was used to encrypt it. The decoder performs the
same calculations as the encoder and, if the key is the same, the data is
recovered.
The HumPROTM Series module has the option to use AES encryption,
arguably the most common encryption algorithm on the market. This is
implemented in a secure mode of operation to ensure the secrecy of the
transmitted data. It uses a 128-bit key stored in the NKEY registers to
encrypt the transmitted data. The source and destination addresses are
sent in the clear.
Encryption is disabled by default.
AES Encryption is not yet implemented on the HumPROTM module.

–– – –
32 33
Restore Factory Defaults
The transceiver is reset to factory default by taking the PB line high briefly
4 times, then holding PB high for more than 3 seconds. Each brief interval
must be high 0.1 to 2 seconds and low 0.1 to 2 seconds. (1 second
nominal high / low cycle). The sequence helps prevent accidental resets.
Once the sequence is recognized, the RFACTV line blinks once per second
until the PB line goes low. After PB goes low, the non-volatile configurations
are set to the factory default values and the module is restarted. The default
UART data rate is 9,600bps.
If the timing on PB does not match the specified limits, the sequence is
ignored. Another attempt can be made after lowering PB for at least 3
seconds.
Using the Low Power Features
The module supports several low-power features to save current in
battery-powered applications. This allows the module to be asleep most of
the time, but be able to quickly wake up, send data and go back to sleep.
Taking the Power Down (POWER_DOWN) line low places the module into
the lowest power state. In this mode, the internal voltage regulator and all
oscillators are turned off. All circuits powered from the voltage regulator
are also off. The module is not functional while in this mode and current
consumption drops to below 6µA. Taking the line high wakes the module.
When the POWER_DOWN line is high, the IDLE register determines sleep
operation.
If IDLE is set to 1 during normal operation, the module sends an ACK byte,
waits for completion of an active transmission, then goes into sleep mode.
Unsent data in the incoming UART data buffer does not inhibit sleep.
During sleep mode, the output lines are in the states in Figure 28.
A rising transition on the POWER_DOWN or CMD_DATA_IN lines wakes
the module. If a negative-going pulse is needed to generate a rising edge,
the pulse width should be greater than 1 µs.
Other lines also wake the module but it immediately goes back to sleep.
Floating inputs should be avoided since they may cause unintended
transitions and cause the module to draw additional current.
On wakeup, the CRESP line is taken high.
If the volatile registers have been corrupted during sleep, a software reset
is performed. This restarts the module as if power were cycled. This can be
caused by power surges or brownout among other things.
After the module wakes up, it sets the IDLE register to 0 (active). If the
WAKEACK register is set to 1, then the module outputs the 0x06 byte on
the CMD_DATA_OUT line. The module then begins normal operation.
Pulsing RESET low causes the module to restart rather than continue from
sleep.
Output Line Sleep States
Output Line Sleep State
EX Unchanged
CRESP Low
LNA_EN Low
PA_EN Low
TXD High
CTS High
RFACTV Low
BE Unchanged
Figure 28: HumPROTM Series Output Line Sleep States

–– – –
34 35
The Command Data Interface
The HumPROTM Series transceiver has a serial Command Data Interface
(CDI) that is used to configure and control the transceiver through
software commands. This interface consists of a standard UART with a
serial command set. The CMD_DATA_IN and CMD_DATA_OUT lines are
the interface to the module’s UART. The UART is configured for 1 start
bit, 1 stop bit, 8 data bits, no parity and a serial data rate set by register
UARTBAUD (default 9,600bps). The CMD line tells the module if the data
on the UART is for configuration commands (low) or data transmission
(high).
The module has a 256 byte buffer for incoming data. The module starts
transmitting when the buffer reaches a specified limit or when the time
since the last received byte on the UART reaches a specified value. This
allows the designer to optimize the module for fixed length and variable
length data.
If the buffer gets nearly full (about 224 bytes), the module pulls the CTS line
high, indicating that the host should not send any more data. Data sent by
the host while the buffer is full is lost, so the CTS line provides a warning
and should be monitored. When there is data in the UART receive buffer,
the BE line is low; when this buffer is empty, BE is high.
Configuration settings are stored in two types of memory inside the
module. Volatile memory is quick to access, but it is lost when power is
removed from the module. Non-volatile memory takes longer to access,
but is retained when power is removed. When a configuration parameter
has both a non-volatile and volatile register, the volatile register controls the
operation.
Configuration settings are read from non-volatile memory on power up
and saved in volatile memory since it is faster to read and write the volatile
memory locations. The volatile and non-volatile registers have different
address locations, but the same read and write commands. The two
locations can be changed independently.
The general serial command format for the module is:
[FF] [Length] [Command]
The Length byte is the number of bytes in the Command field. The
Command field contains the register address that is to be accessed and,
in the case of a write command, the value to be written. Neither Length nor
Command can contain a 0xFF byte.
Byte values of 128 (0x80) or greater must be changed into a two-byte
escape sequence of the format:
0xFE, [value - 0x80]
For example, the value 0x83 becomes 0xFE, 0x03. The Length count
includes the added escape bytes.
A response is returned for all valid commands. The first response byte is
CMD_ACK (0x06) or CMD_NACK (0x15). Additional bytes may follow, as
determined by the specific command.