Murata Electronics North America DNT2400P 2.4GHz Transceiver Module User Manual 16 0346 Exhibit Cover

Download:
Mirror Download [FCC.gov]
Document ID	3175821
Application ID	yDEAUc6AIIz6qRGST9ZBFw==
Document Description	Manual 1 of 2
Short Term Confidential	No
Permanent Confidential	No
Supercede	No
Document Type	User Manual
Display Format	Adobe Acrobat PDF - pdf
Filesize	320.08kB (4001058 bits)
Date Submitted	2016-10-26 00:00:00
Date Available	2016-10-26 00:00:00
Creation Date	2016-10-26 13:56:24
Producing Software	Adobe Acrobat 11.0.18
Document Lastmod	2016-10-26 13:56:24
Document Title	Microsoft Word - 16-0346 - Exhibit Cover
Document Creator	Adobe Acrobat 11.0.18
Document Author:	Kirby.Munroe

Certification Exhibit
FCC ID: HSW-DNT2400P
IC: 4492A-DNT2400P
FCC Rule Part: 15.247
IC Radio Standards Specification: RSS-247
ACS Project Number: 16-0346
Manufacturer: Murata Electronics North America
Models: DNT2400PC, DNT2400PP
Manual
1 of 2
5015 B.U. Bowman Drive Buford, GA 30518 USA Voice: 770-831-8048 Fax: 770-831-8598
DNT2400
2.4 GHz
Spread Spectrum
Wireless Transceivers
Integration Guide
Revision History
Revision
Date
Author
Change Description
1.0
08/18/09
F. Perkins
Initial issue
2.0
11-11-14
R. Willett
Reformatted document to conform to Murata V.I.
2.1
06-03-15
R. Willett
Added EN 300.328 v 1.8.1 compliance parameters to section 3.10.
3.0
10-25-16
R. Willett
Added information for Industry Canada on pages
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
www.murata.com
Important Regulatory Information
Murata Product FCC ID: HSW-DNT2400
IC: 4492A-DNT2400P
Note: This equipment has been tested and found to comply with the limits for a Class B digital device,
pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against
harmful interference in a residential installation. This equipment generates, uses, and can radiate radio
frequency energy and, if not installed and used in accordance with the instructions, may cause harmful
interference to radio communications. However, there is no guarantee that interference will not occur in a
particular installation. If this equipment does cause harmful interference to radio or television reception,
which can be determined by turning the equipment off and on, the user is encouraged to try to correct the
interference by one or more of the following measures:
1.
2.
3.
4.
Reorient or relocate the receiving antenna.
Increase the separation between the equipment and receiver.
Connect the equipment into an outlet on a circuit different from that to which the receiver is connected.
Consult the dealer or an experienced radio/TV technician for help.
Warning: Changes or modifications to this device not expressly approved by RFM could void the user's
authority to operate the equipment.
FCC Antenna Gain Restriction and MPE Statement:
RF Exposure Information:
For mobile operating conditions (>20 cm to the body):
This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment.
This equipment should be installed and operated with minimum distance 20 cm between the radiator and
your body. This transmitter must not be co-located or operating in conjunction with any other antenna or
transmitter.
For mobile operating conditions, the DNT2400 has been designed to operate with dipole antennas of up
to 9 dBi of gain, or patch antennas of up to 6 dBi gain. Antenna types not included in this list, having a
gain greater than the maximum gain indicated for that type, are strictly prohibited for use with this device.
Cet équipement est conforme aux limites d'exposition aux radiations définies pour un environnement non
contrôlé. Cet équipement doit être installé et utilisé à une distance minimale de 20 cm entre le radiateur et
votre corps. Cet émetteur ne doit pas être situé ou opérant en conjonction avec une autre antenne ou
émetteur.
Notices:
WARNING: This device operates under Part 15 of the FCC rules. Any modification to this device, not
expressly authorized by Murata Manufacturing Co., Ltd., may void the user's authority to operate this
device.
www.RFM.com
Technical support+1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
2 of 100
Page 2 of 97
DNT2400 - 04/13/11
www.murata.com
FCC NOTICE: 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.
Innovation, Science, and Economic Development (ISED) Canada Notice: This device complies
with ISED Canada's license-exemt RSSs. Operation is subject to the following two conditions:
(1) This device may not cause harmful interference; and
(2) This device must accept any interference, including interference that may cause undesired
operation.
Le présent appareil est conforme aux CNR ISED Canada applicables aux appareils radio
exempts de licence. L'exploitation est autorisée aux deux conditions suivantes:
(1) l'appareil ne doit pas produire de brouillage, et
(2) l'utilisateur de l'appareil doit accepter tout brouillage radioélectrique subi, même si le
brouillage est susceptible d'en compromettre le fonctionnement.
ISED RSS-247 Detachable Antenna Gain Restriction:
This radio transmitter (DNT2400P), has been approved by ISED Canada to operate with the
antenna types listed below with the maximum permissible gain and required antenna
impedance for each antenna type indicated. Antenna types not included in this list, or having a
gain greater than the maximum gain indicated for that type, are strictly prohibited for use with
this device.
Le présent émetteur radio (DNT2400P ) a été approuvé par ISED Canada pour
fonctionner avec les types d'antenne énumérés ci-dessous et ayant un gain admissible
maximal et l'impédance requise pour chaque type d'antenne. Les types d'antenne non inclus
dans cette liste, ou dont le gain est supérieur au gain maximal indiqué, sont strictement
interdits pour l'exploitation de l'émetteur.
Antennas not included in this list or having a gain greater than 9dBi dipole or 6 dBi patch are
strictly prohibited for use with this device. The required antenna impedance is 50 ohms:
Omnidirectional Dipole Antenna, 9 dBi
Patch Antenna, 6 dBi
See Section 3.9 of this manual for regulatory notices and labeling requirements. Changes or
modifications to a DNT2400P not expressly approved by MURATA may void the user’s
authority to operate the module.
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
3 of 100
www.murata.com
For Portable operating conditions (<20 cm to the body):
This equipment complies with FCC radiation exposure limits set forth for an uncontrolled
environment.
This equipment may operate in direct contact with the body of the user under normal operating
condi-tions. This transmitter must not be co-located or operating in conjunction with any other
antenna or transmitter.
For portable operating conditions, the DNT2400 has been designed to operate with dipole or patch
an-tennas of up to 3.47 dBi of gain. Antenna types not included in this list, having a gain greater
than the maximum gain indicated for that type, are strictly prohibited for use with this device.
This device does not comply with ISED exposure limits for portable applications. Any use for
portable applications in Canada is strictly prohibited.
Ce dispositif ne respecte pas les limites d'exposition ISED pour les applications portables. Toute
utilisation pour les applications portables au Canada est strictement interdite.
See Section 3.9 of this manual for additional regulatory notices and labeling requirements.
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
4 of 100
www.murata.com
Table of Contents
1.0
Introduction ...................................................................................................................................... 7
1.1
Why Spread Spectrum? ............................................................................................................... 7
Frequency Hopping versus Direct Sequence ............................................................................... 8
1.2
DNT2400 Radio Operation .............................................................................................................. 9
2.0
Network Synchronization and Registration .................................................................................. 9
2.1
Authentication ............................................................................................................................. 10
2.2
Serial Port Modes ....................................................................................................................... 10
2.3
SPI Port Modes .......................................................................................................................... 11
2.4
RF Data Communications .......................................................................................................... 11
2.5
RF Transmission Error Control.................................................................................................. 12
2.6
Transmitter Power Management............................................................................................... 1 2
2.7
2.8
Network Configurations............................................................................................................. 12
Point-to-Point Network Operation ......................................................................................... 1 2
2.8.1
Point-to-Multipoint Network Operation................................................................................... 13
2.8.2
Multipoint Peer-to-Peer Network Operation .......................................................................... 13
2.8.3
2.8.4
Tree Routing System Operation................................................................................................ 14
Full-Duplex Serial Data Communications ................................................................................. 14
2.9
2.10
Channel Access .................................................................................................................... 14
2.10.1
Polling Mode........................................................................................................................... 15
2.10.2
CSMA Mode .......................................................................................................................... 15
TOMA Modes ........................................................................................................................ 16
2.10.3
2.11
Transmission Configuration Planning........................................................................................ 17
2.11.1
TOMA Throughput ................................................................................................................. 17
2.11.2
Polling Throughput ................................................................................................................ 18
CSMA Throughput................................................................................................................. 18
2.11.3
Latency .................................................................................................................................. 19
2.11.4
2.11.5
Configuration Validation ........................................................................................................ 20
2.12
Tree-Routing Systems .............................................................................................................. 22
2.12.1
Example Tree-Routing System ............................................................................................. 22
2.12.2
Tree-Routing System Networks ............................................................................................ 24
Tree-Routing System Addressing ......................................................................................... 24
2.12.3
Tree-Routing System Implementation Options ..................................................................... 25
2.12.4
2.13
Serial Port Operation................................................................................................................ 27
2.14
SPI Port Operation ................................................................................................................... 28
2.15
Sleep Modes............................................................................................................................. 33
2.16
Encryption................................................................................................................................. 33
2.17
Synchronizing Co-located Bases ............................................................................................. 33
DNT2400 Hardware ..................................................................................................................... 35
3.0
Specifications ........................................................................................................................... 36
3.1
3.2
Module Interface ....................................................................................................................... 37
DNT2400 Antenna Connector .................................................................................................. 38
3.3
Input Voltages ........................................................................................................................... 39
3.4
ESD and Transient Protection .................................................................................................. 39
3.5
Interfacing to 5 V Logic Systems............................................................................................... 39
3.6
Power-On Reset Requirements ............................................................................................... 40
3.7
Mounting and Enclosures ......................................................................................................... 40
3.8
Labeling and Notices ................................................................................................................ 40
3.9
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
5 of 100
www.murata.com
4.0
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
4.2.10
4.2.11
4.2.12
4.2.13
4.2.14
5.0
5.1
5.2
5.3
5.4
5.5
5.6
5.6.1
5.6.2
5.7
5.8
6.0
7.0
7.1
8.0
8.1
8.2
8.3
8.4
9.0
Protocol Messages ........................................................................................................................ 43
Protocol Message Formats......................................................................................................... 43
Message Types ....................................................................................................................... 43
Message Format Details ......................................................................................................... 44
/CFG Select Pin ....................................................................................................................... 46
Flow Control ............................................................................................................................ 46
Protocol Mode Data Message Example .................................................................................. 46
Protocol Mode Tree-Routing MAC Address Discovery Example............................................ 46
Configuration Registers .............................................................................................................. 47
Bank O - Transceiver Setup ..................................................................................................... 47
Bank 1 - System Settings ........................................................................................................ 50
Bank 2 - Status Registers ....................................................................................................... 51
Bank 3 - Serial and SPI Settings ............................................................................................. 55
Bank 4 - Host Protocol Settings .............................................................................................. 58
Bank 5 - 1/0 Peripheral Registers ........................................................................................... 59
Bank 6 - 1/0 Setup ................................................................................................................... 60
Bank 7 - Authentication List .................................................................................................... 61
Bank 8 - Tree-Routing Active Router ID Table ....................................................................... 62
Bank 9 - Registered MAC Addresses ..................................................................................... 62
Bank FF - Special Functions ................................................................................................... 63
Protocol Mode Configuration Example.................................................................................... 64
Protocol Mode Sensor Message Example .............................................................................. 64
Protocol Mode Event Message Example ................................................................................ 64
DNT2400DK Developer's Kit ......................................................................................................... 66
DNT2400DK Kit Contents........................................................................................................... 66
Additional Items Needed ............................................................................................................ 66
Developer's Kit Operational Notes ............................................................................................. 66
Developer's Kit Default Operating Configuration ....................................................................... 67
Developer's Kit Hardware Assembly .......................................................................................... 67
DNT Demo Utility Program ......................................................................................................... 69
Initial Kit Operation .................................................................................................................. 70
Serial Communication and Radio Configuration ..................................................................... 73
DNT Wizard Utility Program ....................................................................................................... 80
DNT2400 Interface Board Features ........................................................................................... 83
Demonstration Procedure .............................................................................................................. 91
Troubleshooting ............................................................................................................................. 92
Diagnostic Port Commands ........................................................................................................ 92
Appendices .................................................................................................................................... 95
Ordering Information................................................................................................................... 95
Technical Support ....................................................................................................................... 95
DNT2400 Mechanical Specifications .......................................................................................... 96
DNT2400 Development Board Schematic ................................................................................. 98
Warranty ...................................................................................................................................... 100
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
6 of 100
www.murata.com
1.0 Introduction
The DNT2400 series transceivers provide highly reliable wireless connectivity for point-to-point, point-to­
multipoint, peer-to-peer or tree-routing applications. Frequency hopping spread spectrum (FHSS) tech­
nology ensures maximum resistance to multipath fading and robustness in the presence of interfering
signals, while operation in the 2.4 GHz ISM band allows license-free use world wide. The DNT2400
supports all standard serial data rates for host communications from 1.2 to 460.8 kb/s plus SPI data rates
from 6.35 to 80.64 kb/s. On-board data buffering and an error correcting radio protocol provide smooth
data flow and simplify the task of integration with existing applications. Key DNT2400 features include:
•
•
Multipath fading resistant frequency hopping technology with up to 37 frequency
channels per subband
Support for point-to-point, point-tomultipoint, peer-to-peer and tree-routing
networks
•
FCC 15.247, IC and ETSI certified for
license-free operation
•
1O mile plus range with omni-directional
antennas (antenna height dependent)
•
•
Transparent ARO protocol with data
buffering ensures data integrity
Analog and digital 1/0 simplifies wireless
sensing
•
•
•
•
•
•
Dynamic TOMA slot assignment that maximizes throughput and CSMA modes that
maximizes network size
AES encryption provides protection from
eavesdropping
Nonvolatile memory stores DNT2400 configuration when powered off
Selectable 1, 1 O and 63 mW transmit power
levels
Simple interface handles both data and
control at up to 460.8 kb/s on the serial port
or 80.64 kb/s on the SPI port
Auto-reporting 1/0 mode simplifies application development
1.1 Why Spread Spectrum?
A radio channel can be very hostile, corrupted by noise, path loss and interfering transmissions from
other radios. Even in an interference-free environment, radio performance faces serious degradation from
a phenomenon known as multipath fading. Multipath fading results when two or more reflected rays of the
transmitted signal arrive at the receiving antenna with opposing phases, thereby partially or completely
canceling the signal. This problem is particularly prevalent in indoor installations. In the frequency do­
main, a multipath fade can be described as a frequency-selective notch that shifts in location and intensity
over time as reflections change due to motion of the radio or objects within its range. At any given time,
multipath fades will typically occupy 1% - 2% of the band. From a probabilistic viewpoint, a conventional
radio system faces a 1% - 2% chance of signal impairment at any given time due to multipath fading.
Spread spectrum reduces the vulnerability of a radio system to both multipath fading and jammers by
distributing the transmitted signal over a larger frequency band than would otherwise be necessary to
send the information. This allows a signal to be reconstructed even though part of it may be lost or cor­
rupted in transmission.
www.RFM.com
Technical support+1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
7 of 100
Page 5 of 97
DNT2400 - 04/13/11
www.murata.com
NARROWBAND
SIGNAL
NARROWBAND
SIGNAL
SPREAD SPECTRUM(FREQUENCY HOPPING)
',
'fi
SPREAD SPECTRUM(FREQUENCY HOPPING)
.~
JAMMING SIGNAL
MULTIPATH FADING
Narrow-band versus spread-spectrum transmission
Figure 1.1.1
1.2 Frequency Hopping versus Direct Sequence
The two primary approaches to spread spectrum are direct sequence spread spectrum (DSSS) and
frequency hopping spread spectrum (FHSS), either of which can generally be adapted to a given applica­
tion. Direct sequence spread spectrum is produced by multiplying the transmitted data stream by a much
faster, noise-like repeating pattern. The ratio by which this modulating pattern exceeds the bit rate of the
base-band data is called the processing gain, and is equal to the amount of rejection the system affords
against narrow-band interference from multipath and jammers. Transmitting the data signal as usual, but
varying the carrier frequency rapidly according to a pseudo-random pattern over a broad range of chan­
nels produces a frequency hopping spread spectrum system.
{\
""' - - - ,_J
Pseudo-random channel sequence:
DIRECT SEQUENCE
... 02 43 09 22 76 58 17 ...
',
i ',
FREQUENCY HOPPING
Forms of spread spectrum - direct sequence and frequency hopping
Figure 1.1.2
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
8 of 100
www.murata.com
One disadvantage of direct sequence systems is that due to design issues related to broadband transmit­
ters and receivers, they generally employ only a minimal amount of spreading, often no more than the
minimum required by the regulating agencies. For this reason, the ability of DSSS systems to overcome
fading and in-band jammers is relatively weak. By contrast, FHSS systems are capable of hopping
throughout the entire band, statistically reducing the chances that a transmission will be affected by
fading or interference. This means that a FHSS system will degrade gracefully as the band gets noisier,
while a DSSS system may exhibit uneven coverage or work well until a certain point and then give out
completely.
Because it offers greater immunity to interfering signals, FHSS is often the preferred choice for co-located
systems. Since direct sequence signals are very wide, they can offer only a few non-overlapping chan­
nels, whereas multiple hoppers can interleave, minimizing interference. Frequency hopping systems do
carry some disadvantages, in that they requires an initial acquisition period during which the receiver
must lock onto the moving carrier of the transmitter before any data can be sent, which typically takes
several seconds. In summary, frequency hopping systems generally feature greater coverage and chan­
nel utilization than comparable direct sequence systems. Of course, other implementation factors such as
size, cost, power consumption and ease of implementation must also be considered before a final radio
design choice can be made.
2.0 DNT2400 Radio Operation
2.1 Network Synchronization and Registration
As discussed above, frequency hopping spread spectrum radios such as the DNT2400 periodically
change their transmit frequency. In order for the other radios in the network to receive the transmission,
they must be listening to the frequency on which the current transmission is being sent. To do this, all the
radios in the network must be synchronized to the same hopping pattern.
In all DNT2400 networks, one radio is designated as the base. All other radios are designated as remotes
or routers. The base transmits a beacon each time it hops to a different frequency, which allows the other
radios in its network to synchronize with it. Since all radios in the network know the hopping pattern, once
they are synchronized with the base, they know which frequency to hop to and when.
When a remote or router is powered on, it rapidly scans the frequency band for the synchronizing signal.
Since the base is transmitting on up to 37 frequencies and the remotes and routers are scanning up to 37
frequencies, it can take several seconds to synchronize with the base.
Once a radio has synchronized with the base, it will request registration information to allow it to join the
network. Registration is handled automatically by the base. When a radio is registered, it receives several
network parameters from the base, including HopDuration, lnitia/Nwk/0, FrequencyBand and Nwk_Key
(see Section 4.2 for parameter details). Note that if a registration parameter is changed at the base, it will
update the parameter in the remotes or routers over the air.
When leasing is enabled, registration also allows the base to track radios entering and leaving a network,
up to a limit of 126. The base builds a table of serial numbers of registered radios using their three-byte
MAC addresses. To detect if a radio has gone offline or out of range, a registration is leased and must be
renewed within the configured lease interval. DNT2400 radios automatically send lease renewal request
to the base. There is nothing a remote host needs to do to keep the lease renewed. Note that more than
126 radios can join a network, but base-managed leasing cannot be used. In this case, the base can be
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
9 of 100
www.murata.com
configured to send join announcements to a host application for an unlimited number of radios. The
application can then verify the continued presence of each radio in the network through periodic polling.
The DNT2400 also supports a RemoteLeave command that allows a host application to release a radio
from the network. This is useful to remove any rogue radios that may have joined then network when
authentication is not being used. It is also useful to remove remotes from the network once they have
been serviced by the application. The RemoteLeave command includes the amount of time the radio
must leave the network, which can be set from 2 seconds to more than 36 hours. In addition, a radio can
be told to leave and not rejoin until it has been power-cycled or reset. The base can use RemoteLeave to
keep track of remotes that have not yet been serviced, allowing networks of more than 126 remotes to be
indirectly tracked by the base.
2.2 Authentication
In many applications it is desirable to control which radios can join a network. This provides security from
rogue radios joining the network and simplifies network segregation for co-located networks. Registration
is controlled by the AuthMode parameter in the base. The AuthMode parameter can be set to one of four
values, 0..3. The default value is 0, which allows any remote or router to register with a base.
When the AuthMode parameter is set to 1, a radio's address must be listed in Parameter Bank 7 before it
will be allowed to register with the base. This is referred to as base authentication. Bank 7 must be pre­
loaded with the addresses of the authorized remotes before using base authentication. If a radio whose
MAC address is not in Bank 7 attempts to join the network the base will deny the registration request. A
maximum of 16 remotes can be entered into Bank 7. To support larger networks, mode 2 must be used.
When the AuthMode parameter is set to 2, the address of a radio attempting to register with the base is
sent to the host for authentication in a JoinRequest message. The host application determines if the radio
should be allowed to register and returns a JoinReply message to the base containing a PermitStatus
parameter that allows or blocks the radio from registering. The host application has 30 seconds in which
to respond, after which time the base denies registration to the radio. Up to 16 join requests can be
pending at any one time. If more than 16 radios are asking to join, the first 16 will be serviced and addi­
tional radios will be serviced after the earlier requests are handled. The RegDenia/Delay parameter
controls how often a radio will request registration after it has been denied. If it is anticipated that more
than 16 radios will request registration before the application can service the first 16, this parameter
should be set to the time it will take the application to service four requests, as this will speed the authen­
tication process by freeing the base from issuing multiple denials to the same remotes.
When the AuthMode parameter is set to 3, authentication is locked to the addresses of the radios cur­
rently registered with the base. Mode 3 is typically used in conjunction with Mode O during a commission­
ing process. AuthMode is set to 0, radios are turned on and allowed to register with the base, and
AuthMode is then switched to 3 to lock the network membership.
2.3 Serial Port Modes
DNT2400 radios can work in two data modes on the primary serial (UART) port: transparent and packet
protocol. Transparent mode formatting is simply the raw user data. Protocol mode formatting includes a
start-of-packet framing character, length byte, addressing, command bytes, etc. Transparent mode opera­
tion is especially useful in point-to-point systems that act as simple cable replacements. In point-to­
multipoint, peer-to-peer and tree-routing systems where the base needs to send data specifically to each
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
10 of 100
www.murata.com
radio, protocol formatting must be used unless the data being sent includes addressing information that
the devices connected to the remotes/routers can use to determine the intended destination of the broad­
cast data. Protocol formatting is also required for configuration commands and responses, and sensor 1/0
commands and responses. Protocol mode can be used at the base while transparent mode is used at the
remotes. The one caution about protocol mode: the length of a protocol mode message cannot exceed
the BaseS!otSize or RemoteS!otSize or the packet will be discarded. Protocol formatting details are
covered in Section 4.
The DNT2400 provides two ways to switch between transparent and protocol modes. To enter protocol
mode, the /CFG input Pin 18 can be switched from logic high to low, or the EnterProtoco/Mode command
can be sent. When input Pin 18 is switched from logic low to high, or an ExitProtoco/Mode command is
sent to the primary serial input, the DNT2400 will switch to transparent operation. Note that it is possible
that part of the EnterProtoco/Mode command will be sent over the air as transparent data.
When operating in transparent mode, two configuration parameters control when a DNT2400 radio will
send the data in its transmit buffer. The MinPacketLength parameter sets the minimum number of bytes
that must be present in the transmit buffer to trigger a transmission. The TxTimeout parameter sets the
maximum time data in the transmit buffer will be held before transmitting it, even if the number of data
bytes is less than MinPacketLength. The default value for MinPacketLength parameter is one and the
TxTimeout parameter is zero, so that any bytes that arrive in the DNT2400 transmit buffer will be sent on
the next hop. As discussed in Section 2.8.2, it is useful to set these parameters to values greater than
their defaults in point-to-multipoint systems where some or all the remotes are in transparent mode.
2.4 SPI Port Modes
DNT2400 radios can be configured to transmit and receive data through the serial peripheral interface
(SPI) port instead of the primary serial (UART) port. A DNT2400 can operate as either an SPI Master or
Slave. Messages routed through the SPI port must be protocol formatted, as described in Section 4.
When a DNT2400 is acting as an SPI Slave, all messages are routed through the SPI port. When a
DNT2400 is acting as an SPI Master, only data messages are routed through the SPI port; radio configu­
ration commands and responses are routed through the primary serial (UART) port. A radio configured as
an SPI Master can use a command stored in the SPI_MasterCmdStr parameter to interrogate a Slave
peripheral for data to transmit to the base. This is especially useful where periodic 1/0 reporting is en­
abled on the remote. Alternately, the base can send an interrogation command to the radio to fetch pe­
ripheral data. SPI operation is configured with the SPI_Mode parameter.
2.5 RF Data Communications
At the beginning of each hop the base transmits a beacon, which always includes a synchronizing signal.
After synchronization is sent, the base will transmit any user data in its transmit buffer, unless in transpar­
ent mode the MinPacketLength and/or TxTimeout parameters have been set above their default values.
The maximum amount of user data bytes that the base can transmit per hop is limited by the BaseS!ot­
Size parameter, as discussed in Section 2.8.1. If there is no user data or reception acknowledgements
(ACKs) to be sent on a hop, the base will only transmit the synchronization signal in the beacon.
The operation for remotes and routers is similar to the base, but without a synchronizing signal. The
RemoteS!otSize parameter indicates the maximum number of user data bytes a remote or router can
transmit on one hop and is a read-only value. The RemoteS!otSize is determined by the HopDuration and
www.RFM.com
Technical support+1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
11 of 100
Page 9 of 97
DNT2400 - 04/13/11
www.murata.com
BaseSlotSize parameters and the number of registered radios. The MinPacketLength and TxTimeout
parameters operate in a remote in the same manner as in the base.
2.6 RF Transmission Error Control
The DNT2400 supports two error control modes : automatic transmission repeats (ARQ), and redundant
transmissions for broadcast packets. In both modes, the radio will detect and discard any duplicates of
messages it receives so that the host application will only receive one copy of a given message. In the
redundant transmission mode, broadcast packets are repeated a fixed number of times based on the
value of the ARQ_AttemptLimit parameter. In ARO mode, a packet is sent and an acknowledgement is
expected on the next hop. If an acknowledgement is not received, the packet is transmitted again on the
next available hop until either an ACK is received or the maximum number of attempts is exhausted. If the
ARQ_AttemptLimit parameter is set to its maximum value, a packet transmission will be retried without
limit until the packet is acknowledged. This is useful in some point-to-point cable replacement applications
where it is important that data truly be 100% error-free, even if the destination remote goes out of range
temporarily.
2. 7 Transmitter Power Management
The DNT2400 includes provisions for setting the base transmit power level and the remote maximum
transmit power level with the TxPower parameter. DNT2400 networks covering a small area can be
adjusted to run at lower transmitter power levels, reducing potential interference to other nearby systems.
Radios that are located close to their base can be adjusted to run at lower maximum power, further
reducing potential interference. Base units transmit at the fixed power level set by the TxPower parameter. Remotes and routers automatically adjust their transmitter power to deliver packets to the base at an
adequate but not excessive signal level, while not transmitting more power than set by their TxPower
parameter. Remotes and routers make transmitter power adjustments using the strength of the signals
received from the base and the base transmitter power setting, which is periodically transmitted by the
base. The automatic transmit power adjustment is enabled by default, but can be disabled if so desired.
Refer to Section 4.2.1 for details.
2.8 Network Configurations
The DNT2400 supports four network configurations: point-to-point, point-to-multipoint, peer-to-peer and
tree-routing. In a point-to-point network, one radio is set up as the base and the other radio is set up as a
remote . In a point-to-multipoint network, a star topology is used with the radio set up as a base acting as
the central communications point and all other radios in the network set up as remotes. In this configuration, each communication takes place between the base and one of the remotes. Peer-to-peer communications between remotes using the base as a relay is also supported, as discussed in Section 2.8.3.
Tree-routing networks can retransmit messages through one or more routers, greatly expanding the area
that can be covered by a single DNT2400 system, as discussed in Section 2.8.4.
2.8.1 Point-to-Point Network Operation
Most point-to-point networks act as serial cable replacements and both the base and the remote use
transparent mode. Unless the MinPacketLength and TxTimeout parameters have been set above their
default values, the base will send the data in its transmit buffer on each hop, up to a limit controlled by the
BaseS/otSize parameter. In transparent mode, if the base is buffering more data than can be sent on one
hop, the remaining data will be sent on subsequent hops. The base adds the address of the remote, a
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
12 of 100
Page 10 of 97
DNT2400 - 04/13/11
www.murata.com
packet sequence number and error checking bytes to the data when it is transmitted. These additional
bytes are not output at the remote in transparent mode. The sequence number is used in acknowledging
successful transmissions and in retransmitting corrupted transmissions. A two-byte CRC and a one-byte
checksum allow a received transmission to be checked for errors. When a transmission is received by the
remote, it will be acknowledged if it checks error free. If no acknowledgment is received, the base will
retransmit the same data on the next hop. Note that acknowledgements from remotes are suppressed on
broadcast packets from the base.
In point-to-point operation, by default a remote will send the data in its transmit buffer on each hop, up to
the limit controlled by its RemoteSlotSize parameter. If desired, the MinPacketLength and TxTimeout
parameters can be set above their default values, which configures the remote to wait until the specified
amount of data is available or the specified delay has expired before transmitting. In transparent mode, if
the remote is buffering more data than can be sent on one hop, it will send the remaining data in subsequent hops. The remote adds its own address, a packet sequence number and error checking bytes to
the data when it is transmitted. These additional bytes are not output at the base if the base is in transparent mode. When a transmission is received by the base, it will be acknowledged if it checks error free.
If no acknowledgment is received, the remote will retransmit the same data on the next hop.
2.8.2 Point-to-Multipoint Network Operation
In a point-to-multipoint network, the base is usually configured for protocol formatting, unless the applications running on each remote can determine the data's destination from the data itself. Protocol formatting
adds addressing and other overhead bytes to the user data. If the addressed remote is using transparent
formatting, the source (originator) address and the other overhead bytes are removed . If the remote is
using protocol formatting, the source address and the other overhead bytes are output with the user data.
A remote can operate in a point-to-multipoint network using either transparent or protocol formatting, as
the base is the destination by default. In transparent operation, a remote DNT2400 automatically adds
addressing, a packet sequence number and error checking bytes as in a point-to-point network. When the
base receives the transmission, it will format the data to its host according to its formatting configuration.
A remote running in transparent mode in a point-to-multipoint network can have the MinPacketLength and
TxTimeout parameters set to their default values to reduce latency, or above their default values to reduce the volume of small packet transmissions.
2.8.3 Multipoint Peer-to-Peer Network Operation
After a remote has joined a point-to-multipoint network, it can communicate with another remote through
peer-to-peer messaging, where the base acts as an automatic message relay. In protocol mode, if a
remote specifies a destination address other than the base address, peer-to-peer messaging is enabled.
In transparent mode, the RmtTransDestAddr parameter sets the destination address. Changing RmtTransDestAddr from the default base address to the address of another remote enables peer-to-peer
messaging . The broadcast address can also be used as a peer-to-peer destination address. In this case,
the message will be unicast from the remote to the base (using ARO) and then broadcast by the base (no
ARO). For peer-to-peer broadcasts, no acknowledgement is sent and no TxDataReply packet is reported
to the host.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
13 of 100
Page 11 of 97
DNT2400 - 04/13/11
www.murata.com
2.8.4 Tree-Routing Operation
A ONT2400 tree-routing system consists of a base, remotes and up to 63 routers. A router is basically a
remote that has been configured with two operating modes - a base mode for its "child" radios and a
remote mode for its "parent" router or the system base. This allows a router to do tree-routing in addition
to normal remote functions. Each router can forward messages to/from a total of 126 child radios. A
ONT2400 tree-routing system can cover a much larger area than other ONT2400 networks, with the
trade-off that tree-routing increases message transmission latency. Tree-routing systems are well suited
to many industrial, commercial and agricultural data acquisition applications. Tree-routing operation is
supported by CSMA (mode 1) channel access. See Section 2.12 below.
2.9 Full-Duplex Serial Data Communications
From a host application's perspective, ONT2400 serial communications appear full duplex. Both the base
host application and each remote/router host application can send and receive serial data at the same
time. At the radio level, the radios do not actually transmit at the same time. If they did, the transmissions
would collide. As discussed earlier, the base transmits a synchronization beacon at the beginning of each
hop, followed by its user data. After the base transmission, the remotes/routers can transmit. Each transmission may contain all or part of a complete message from its host application. From an application's
perspective, the radios are communicating in full duplex since the base can receive data from a remote/router before it completes the transmission of a message to the remote/router and visa versa.
2.10 Channel Access
The ONT2400 provides three methods of channel access: Polling, CSMA and TOMA, as shown in the
table and figure below. The channel access setting is distributed to all radios by the base, so changing it
at the base sets the entire network or system. Polling refers to an application sending a command from
the base to one or more remote devices and receiving a response from only one remote device at a time.
Polling is suitable for both large and small networks where periodic or event reporting by remotes is not
required . Carrier Sense Multiple Access (CSMA) is very effective at handling packets with varying
amounts of data and/or packets sent at random times from a large number of remotes. Time Division
Multiple Access (TOMA) provides a scheduled time slot for each remote to transmit on each hop. The
default ONT2400 access mode is TOMA dynamic mode.
Access Mode
Description
Max Number of Remotes
Polling
unlimited
CSMA
unlimited
TOMA dynamic slots
up to 16
TOMA fixed slots
up to 16
TOMA with PTT
up to 16
Table 2.10.1
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
14 of 100
Page 12 of 97
ONT2400 - 04/13/11
www.murata.com
POLL
Base
Remote #1
Remote #2
Remote#3
CSMA
Base
Remote#1
Remote#2
Remote#3
Listen
)I( ~
Backoff
Listen
TOMA
Base
Remote #1
Remote #2
Remote#3
.~
ID
CJ
Figure 2.10.1
2.10.1 Polling Mode
Polling channel access is used for point-to-point and point-to-multipoint systems where only one remote
will attempt to transmit data at a time, usually in response to a command from the base.
Polling (mode 0) is a special case of CSMA mode 1. The user can set the BaseSlotSize and CSMA_
RemtSlotSize parameters when using this mode. Since only one remote will attempt to transmit at a time,
to minimize latency, the CSMA_Predelay and CSMA_Backoffparameters are not used. Lease renewals
are also not used, again to minimize latency. Thus, when the base is operated in protocol mode with
Announce messages enabled, only join messages are generated. This mode provides high throughput as
there is no contention between remotes and the entire portion of the hop frame following the base transmission is available for a remote to transmit. Applications where more than one remote may attempt to
transmit at a time, where event and/or periodic 1/0 reporting are enabled, and/or tree-routing operation is
required should not use this mode.
2.10.2 CSMA Mode
When using CSMA channel access, each remote/router with data to send listens to see if the channel is
clear and then transmits. If the channel is not clear, a radio will wait a random period of time and listen
again. CSMA works best when a large or variable number of radios transmit infrequent bursts of data.
There is no absolute upper limit on the number of radios that can be supported in this mode - it depends
on message density. A maximum of 126 radios can be supported if base-managed join/leave tracking is
required, or an unlimited number of remotes if base join-leave tracking is not required or will be handled
by the host application.
There are two important parameters related to CSMA operation. The CSMA_Backoff parameter defines
the initial time that a radio will wait when it determines the channel is busy before again checking to see if
the channel is clear (back-off interval). If, after finding the channel busy and backing off, the radio finds
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
15 of 100
Page 13 of 97
DNT2400 - 04/13/11
www.murata.com
the channel busy a second time, the amount of time the radio will wait before checking the channel will
increase. It will continue to increase each subsequent time the channel is busy until the channel is finally
found idle. This is the classic CSMA technique that handles the situation where a number of radios hold
data to send at the same time. The CSMA_ Predelay parameter controls the maximum time that a radio
will wait before first listening to see if the channel is clear for a transmission. This parameter is used to
make sure that all the remotes do not transmit immediately after the base finishes transmitting.
CSMA (mode 1) provides classical CSMA channel access, and gives the user control over both the
CSMA_Predelay and CSMA_Backoffparameters. This mode is well suited for large numbers of uncoordinated radios, where periodic/event reporting is used, or tree-routing operation is required. In addition to
CSMA_ Predelay and CSMA_ MaxBackoff, the user can set the BaseSlotSize and CSMA_ RemtSlotSize
parameters when using this mode. The following guidelines are suggested for setting CSMA_Predelay:
•
For lightly loaded CSMA contention networks, decrease CSMA_Predelay
to Ox03 or less to reduce latency.
•
For heavily loaded CSMA contention networks, increase CSMA_Predelay
to Ox05 or more for better throughput.
As an option, CSMA mode allows the base to directly track remotes entering and leaving the network, for
up to 126 remotes. The base is operated in protocol mode and is configured to send Announce messages
to its host when a remote joins, and when the remote's registration lease expires.
While a base in a CSMA network can track a maximum of 126 remotes entering and leaving the network,
it can generate join Announce messages for an unlimited number of remotes. This allows the host application to track remotes entering and leaving a CSMA network with more than 126 remotes by creating its
own table of MAC addresses and periodically sending a GetRemoteRegister command to each remote in
the table. Failure to answer a GetRemoteRegistercommand indicates the remote is no longer active in
the network.
CSMA modes work well in many applications, but CSMA has some limitations, as summarized below:
•
Bandwidth is not guaranteed to any remote .
•
Marginal RF links to some remotes can create a relatively high chance of
collisions in heavily loaded networks.
2.10.3 TDMA Modes
TOMA modes provide guaranteed bandwidth to some or all of the radios in a network. Radios that register with the base receive several special parameters, including ranging information and a specific channel
access time slot assignment. TOMA registrations are always leased and must be renewed every 250
hops. The DNT2400 provides three TOMA access modes, as discussed below.
TOMA Dynamic Slots (mode 2) is used for general-purpose TOMA applications where scaling the capacity per slot to the number of active remotes is automatic. Each radio that registers with the base receives
an equal time slice. As new remotes join, the size of the TOMA remote slots shrinks accordingly. The
number of slots, individual slot start times, and the RemoteS/otSize are computed automatically by the
DNT2400 network in this mode. The user should note that the bandwidth to each remote will change
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
16 of 100
Page 14 of 97
DNT2400 - 04/13/11
www.murata.com
immediately as remotes join or leave the network. When running in protocol mode on a remote, care must
be taken not to generate messages too long to be sent in a single hop due to automatic RemoteSlotSize
reduction .
TOMA Fixed Slots (mode 3) is used for applications that have fixed data throughput requirements, such
as isochronous voice or streaming telemetry. The slot start time and the RemoteSlotSize are computed
automatically by the DNT2400 network in this mode. The user must set the number of slots using the
MaxSlots parameter. The base radio will allocate remote slot sizes as if MaxSlots number of radios are
linked with the base, even when fewer remotes/routers are actually linked. In this mode, the remote slot
sizes are constant.
TOMA with PTT (mode 4) supports remotes with a "push-to-talk" feature, also referred to as "listenmostly" remotes . This mode uses fixed slot allocations. Remotes can be registered for all but the last slot.
The last slot is reserved for the group of remotes that are usually listening, but occasionally need to
transmit. In essence, the last slot is a shared channel for this group of remotes. When one of them has
data to send it keys its transmitter much like a walkie-talkie, hence the name push-to-talk (PTT). There is
no limit to the number of remotes that can listen to the last slot.
The slot start time and the RemoteS/otSize are computed automatically by the DNT2400 network in mode
4. The user must specify the number of slots using the MaxS/ots parameter. The last slot is reserved for
the PTT remotes. The user must configure PTT remotes individually to select mode 4 operation. The
user's application must ensure that only one PTT remote at a time is using the slot. Mode 4 does not
support tree-routing operation.
2.11 Transmission Configuration Planning
Because frequency hopping radios change frequency periodically, a single message may be sent in one
or more RF transmissions. The length of time the radio stays on a frequency, the hop duration, impacts
both latency and throughput. The longer the radio stays on a single frequency, the higher the throughput
since the radio is transmitting for a higher percentage of the time, but latency is also higher since radios
may have to wait longer to transmit. So latency and throughput trade off against one another. The
DNT2400 has several configuration parameters that allow latency and throughput to be optimally balanced to the needs of an application.
2.11.1 TDMA Throughput
For TOMA channel access without routers, throughput and latency are controlled by the RF data rate , the
serial port baud rate, the BaseS/otSize, the HopDuration, and the number of remotes. A wide range of
throughput and latency combinations can be obtained by adjusting these parameters. The throughput of a
radio in a TOMA network is simply:
Number of bytes per hop/Hop Duration
For the base, the number of byes per hop is controlled by the BaseSlotSize parameter so the throughput
of the base radio is:
BaseSlotSize/HopDuration
Note that if fewer bytes than the BaseSlotSize limit are sent to the base radio by its host during the hop
duration time in transparent mode, the observed throughput of the base radio will be reduced. If the base
is in protocol mode, it will wait until a protocol formatted message is completely received from its host
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
17 of 100
Page 15 of 97
DNT2400 - 04/13/11
www.murata.com
before transmitting it. If the message is not completely received by the time the base transmits, the base
will wait until the next hop to transmit the message. The throughput for each remote is:
RemoteSlotSize/HopDuration
In a TOMA mode, the RemoteSlotSize is set automatically based on the number of remotes and the
BaseSlotSize. Note that the base radio always reserves BaseSlotSize amount of time in each hop
whether or not the base has user data to send.
To help select appropriate parameter values, RFM provides the ONT Throughput Calculator utility program (DNTCalc.exe). This program is on the development kit CD. Enabling encryption (security) adds
additional bytes to the data to be sent but the Calculator has a mode to take this into account.
2.11.2 Polling Throughput
In polling mode, the application sends data from the base to a specific remote, which causes the remote
and/or its host to send data back to the application. The network operates like a point-to-point network in
this case. In polling, the HopDuration should be set just long enough to accommodate a base transmission up to the limit allowed by the BaseSlotSize parameter, plus one remote transmission up to the limit
allowed by the CSMA_RemtSlotSize parameter. These slot sizes and the hop duration set the polling
throughput as in TOMA channel access.
The throughput in Polling mode is also determined by the amount of time it takes for the remote host
device to respond to the poll. For example, consider the situation where a remote host device communicates with the DNT2400 at 38.4 kb/s, receives a 16-byte poll command, and takes 1 ms to generate a 32byte response which it then sends to the DNT2400. Sixteen bytes over a UART port is 160 bits using
8,N, 1 serial parameters. Sending 160 bits at 38.4 kb/stakes 4.2 ms. Add 1 ms for the host device to
process the command and begin sending the 32-byte response. The 32-byte response takes 8.4 ms to
send at 38.4 kb/s, for a total turnaround time of 13.6 ms. This amount of time could be added to the base
and remote slot times to allow the entire transaction to take place in a single hop. However, except at the
38.4 kb/s over-the-air data rate, this is likely to be much longer than the base and remote slot times.
Thus, in practice, lengthening the hop duration to complete the transaction in a single hop doesn't really
affect the throughput. Nevertheless, it is important to note that the throughput for the remote in the example above is substantially less than the remote slot size in bytes divided by the hop duration.
It is not a DNT2400 requirement that the complete application message be sent in a single hop, nor that
the remote response is returned in a single hop, when in transparent mode. If either transmission occurs
over more than one hop, then depending on the length of the data, the RF data rate and the serial port
data rate at the receiving end, there may be a gap in the serial data. Some protocols, such as Modbus
RTU, use gaps in data to determine packet boundaries.
2.11.3 CSMA Throughput
In CSMA mode, remote radios do not have a fixed throughput, which is why applications requiring guaranteed throughput should use polling or a TOMA mode. The reason that the throughput of a CSMA
remote is not fixed is because its ability to transmit at any given time depends on whether another radio is
already transmitting. The throughput of a remote is further affected by how many other remotes are
waiting for the channel to become clear so they can transmit. This is not a problem when remotes, even a
large numbers of remotes, only send data infrequently. The DNT2400 includes several configuration
parameters that can be used to optimize the performance of a CSMA network.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
18 of 100
Page 16 of 97
DNT2400 - 04/13/11
www.murata.com
It is often desirable to limit the amount of data a CSMA remote can send in one transmission. This prevents one remote from hogging network throughput. To accommodate this, the DNT2400 provides a
CSMA_RemtS/otSize parameter that is user configurable. When a remote has transmitted CSMA_
RemtS/otSize bytes on a given hop, it will stop transmitting until the next hop. Note that this remote will
have to contend for the channel on the next hop, so it is not guaranteed that it will be the first remote to
transmit on the next hop or that it will be able to transmit on the next hop at all. To allow multiple remotes
a chance to transmit on the same hop, the HopDuration parameter must be set long enough to support
the BaseSlotSize, plus the number of remotes to transmit per hop multiplied by the CSMA_ RemtSlotSize,
plus the number of remotes to transmit per hop multiplied by the CSMA_Backoff. Because of the way
CSMA channel access works, this does not guarantee that the desired number of remotes to transmit on
a hop will always be able to transmit on a single hop. This is due to the fact that when a remote with data
to send finds the channel busy a second time, it waits for a longer period to time before testing the channel again. This time will continue to increase until the remote finds the channel clear. In practice this is
unlikely to present a problem , as CSMA networks are used with devices that infrequently have data to
send.
The ONT Throughput Calculator can be used to determine the HopDuration, but it will be necessary to
increase the number of slots to a value greater than the number of remotes to transmit on a single hop to
account for the backoffs. It is indeterminate how many backoffs may occur during a single hop, which is
why the number of remotes that transmit on a given hop cannot be guaranteed. Note that the CSMA_
Backoff parameter sets the length of time a remote will wait to recheck the channel when it has detected
that the channel is busy. The second time a remote detects that the channel is busy, it will increase the
amount of time it waits until it checks again. Every subsequent time it detects a busy channel it will increase the amount of time it will wait in a geometric fashion. This continues until it detects an idle channel. So while a short CSMA_Backoff can decrease the time between when one remote transmits and the
next remote transmits, it can actually lead to a longer time between remote transmissions than a longer
backoff. This can occur when the remote checks the channel multiple times during the transmitting remote's transmission causing the back-off time to be increased.
2.11.4 Latency
The worst case latency for TOMA access (without routers), excluding retries, occurs when the radio
receives data just after its turn to transmit. In this instance, it will have to wait the length of time set by the
HopDuration to begin transmitting the data. If the radio is receiving data over its serial port at a rate higher
than its throughput, this will only occur at the beginning of a transmission that spans several hops.
In a polling application, latency is affected by how long the remote and/or its host takes to respond, and
when in the hop data is ready to be transmitted. Since a remote can begin transmitting at practically any
time during the hop after the base has transmitted, the latency can be less than HopDuration. However,
the remote transmission may extend over two hops if it starts late in the first hop.
Latency for any given remote in a CSMA network is particularly difficult to characterize. If many remotes
have data to send, the latency for the last remote to send will be the length of time it takes all the other
remotes to send. The CSMA scheme used in the DNT2400 is designed to allow each remote an equal
opportunity to transmit, so the concern is not that one remote is locked out, but just how long it will take a
number of remotes with data to sent to each gain access to the channel and send their data. The more
data that needs to be sent, the more time will be consumed checking the channel and backing off when
the channel is busy. Again, this is why CSMA networks are best used when there are a large number of
nodes that send data infrequently.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
19 of 100
Page 17 of 97
DNT2400 - 04/13/11
www.murata.com
The other factor impacting latency is retries. This impact is not unique to frequency hopping radios but is
common among all wireless technologies. A radio only transmits data once per hop. It needs to wait until
the next hop to see if the transmission was received at the destination. If not, the radio will transmit the
data again and wait for the acknowledgement. This can happen up to ARQAttemptLimit number of times
which is equal to ARQAttemptLimittimes HopDuration amount of time.
2.11.5 Configuration Validation
Although slot durations are automatically calculated by the DNT2400, the RF data rate, hop duration, etc. ,
must be coordinated by the user to assure a valid operating configuration based on the following criteria:
1.
Regardless of the RF data rate, the maximum DNT2400 hop duration is limited to 200 ms. A
DNT2400 network must be configured accordingly.
2.
In protocol mode, the BaseSlotSize and RemoteSlotSize parameters must be large enough to
hold all the data bytes in the largest protocol formatted message being used. Protocol formatted
messages must be sent in a single transmission. Any protocol formatted messages too large for
the slot size setting will be discarded
3.
In TOMA mode 2, the RemoteS/otSize will be reduced automatically when a new remote joins the
network. This can cause a network to suddenly malfunction if the hop duration is not set to provide an adequately large remote slot allocation when fully loaded with remotes
4. When operating in polling mode 0, the CSMA_RemtS/otSize and HopDuration parameters are
usually set to accommodate the number of data bytes in a maximum size transmission . This configuration provides low latency for polled messages.
5. When operating in CSMA mode 1 with multiple remotes, the CSMA_RemtSlotSize and HopDuration parameters are usually set to accommodate three times the number of data bytes in one
maximum size transmission, to allow time for more than one remote to attempt to transmit during
a single hop.
c:IDNT Throughput calculator
Calculate Hop Duralion
ft dJiu 1 .,.....
J,,,12.10:
.=.]
Jsta·
..,-]
,.,
Rf Data Rillt•
Jrn:r:i,,,
Calculate Remole Slol Size
Wtfl- l TTl-'t:1
fld Ji uT.......
_'-1
Jc,r,1oc
Bate Slot Si.!e
"-'
Jsta,
.:J
RFDala Rillt0
Jsnb,.
Ba1:a Slot Si:!e
N u a hr:r nf Rr.s, nt~:t
N111ahr:r nf Rr.mn tl':ot
"-J
W"'l"""1l T"l-'"'
.:J
H1111[1ur ;, tinP'lr.nunl:!:
·"
I" ).00 m~I
w... uu1,,,n.-:r. 1nM dr. 4
M• l lu.t,.,nr: r..,.M 1lr. .s.
1,u
I'"
Hep Dur.Jtien
o.oo~c
3.80n:c
Remote S101 Sizc
1)-F3
n ,ur. T hrnuohp1t
.1 ; n ~· .'.•
Figure 2.11.5.1
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
20 of 100
Page 18 of 97
DNT2400 - 04/13/11
www.murata.com
The ONT Throughput Calculator utility program is shown in Figure 2.11.5.1. Decimal data is entered by
default. Hexadecimal data can also be entered using a Ox prefix, as shown in the Hop Duration Counts
text box. When using the ONT Throughput Calculator, parameter coordination depends on the operating
mode of a DNT2400 network, as outlined below:
Polling (mode 0) - the user can set and must coordinate the RF data rate, hop duration, base slot size
and remote slot size. First, set the BaseSlotSize to accommodate the maximum number of data bytes in a
base transmission. Next, set the CSMA_RemtSlotSize to accommodate the maximum number data bytes
in a remote transmission. Use these slot sizes, the RF data rate and the maximum operating range (20
miles is the default) as inputs to the Calculator program to determine minimum valid HopDuration.
CSMA contention (mode 1) - the same procedure as for polling is used, except that the CSMA_
RemtS/otSize typically should be set at three times the maximum number of data bytes for point-tomultipoint networks. The default values for CSMA pre-delay and back-off are assumed.
TOMA dynamic (mode 2) - this is the DNT2400's default operating mode and the default settings are
optimized for point-to-point transparent operation. For other configurations the user must coordinate the
RF data rate, hop duration, base slot size and maximum number of remotes. Although the remote slot
size and remote slot time allocation are automatically set in mode 2, the user must predetermine these
values to assure a valid operating configuration. First, set the BaseS/otSize to accommodate the maximum number of data bytes in a base transmission. Next, determine the RemoteSlotSize required to
accommodate the maximum number of data bytes in a remote transmission. Use these slot sizes, the
maximum number of remotes that will be used in the network, the RF data rate and the maximum operating range as inputs to the Ca/culatorto determine the minimum valid HopDurationtime. Note that when
there are fewer remotes on the network than the maximum specified, the remotes will automatically be
configured with a bigger RemoteS/otSize parameter.
TOMA fixed (mode 3) - First, set the BaseSlotSize to accommodate the maximum number of data bytes in
a transmission. Next, determine the RemoteS/otSize required to accommodate the maximum number of
data bytes in a remote transmission . Then set the number of remote slots. Use the slot sizes, the number
of remotes, the RF data rate and maximum operating range as inputs to the Calculator to determine the
minimum valid hop duration.
TOMA PTT (mode 4) - use the same procedure as for TOMA fixed mode 3.
The DNT2400 base firmware can detect a significant number of invalid configurations and override the
HopDuration parameter to establish a valid configuration. To take advantage of this feature, configure a
DNT2400 network in the following order:
1.
In all system radios, set the RF_DataRate parameter and save it. Then reset all radios to establish the new RF data rate.
2.
Set the BaseSlotSize and TDMA_MaxSlots or CSMA_RemtSlotSize as needed. Use the default
maximum operating range unless links of more than 20 miles are planned.
3.
Set the HopDuration parameter and then read it back. If the HopDuration parameter readout is
different than the value set, the firmware detected an invalid configuration and is overriding it.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
21 of 100
Page 19 of 97
DNT2400 - 04/13/11
www.murata.com
2.12 Tree-Routing Systems
As discussed in Section 2.8.4, DNT2400 tree-routing systems can cover much larger areas than other
DNT2400 networks, with the trade-off that tree-routing increases message transmission latency. Treerouting systems are well suited to many industrial, commercial and agricultural applications. Compared to
other DNT2400 network configurations, however, tree-routing systems require somewhat more initial
planning and commissioning steps, as discussed in this Section.
2.12.1 Example Tree-Routing System
An example tree routing system is shown in Figure 2.12.1.1. In this example, seven sensor locations
need to be monitored over a several acre outdoor site. All of the sensor data must be sent back to a
central location, the base radio, for collection and analysis. Due to obstructions, remotes R1, R3, R6, and
R7 are prevented from communicating directly with the base radio. R1 , R3, and R6 have direct communications with either R2 or RS, both of which have direct communications with the base radio. R7 has direct
communications with R6 and can use R6 to route messages to and from the base through RS.
Using the tree routing function of the DNT2400, all nodes will be able to send and receive data to and
from the centrally located base. R2, RS, and R6 which are configured to relay data to and from other
nodes in addition to sending their own sensor data are called routing remotes, or routers. Note that there
is no hardware or firmware difference between DNT2400 base, remote and router nodes - they are
simply configured for the particular mode of operation.
As the system is powered up, R2, R4, and RS will join by registering with the base radio . R2 and RS, once
they have registered with the base radio, will start sending out beacons so that R1 , R3, and R6 can join
the tree-routing system through them . In the case of R6, it will wait until it has joined the system through
RS before sending out the beacons that will let R7 join the system through it.
Example DNT2400 Tree Routing System
R1 -Remote
R2 -Routing
Remote
R6 -Routing
Remote
Base
R5 -Routing
Remote
Figure 2.12.1.1
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
22 of 100
Page 20 of 97
DNT2400 - 04/13/11
www.murata.com
Data sent from the base radio in the central location will be routed down the "tree" to the intended node of
the network. Data from the nodes will be routed up the tree to the base or to another node in the system.
Note that it is possible to send data from one node to another node rather than sending it to the base.
A tree-routing system can operate in a polling mode where an application sends data requests to each of
the nodes as needed, or it can operate where devices attached to the node radios send data whenever
they have it to send. Additionally, the auto-report function of the DNT2400 radio can be used to send data
through the tree on a timer or interrupt basis.
To set up the example system, all of the DNT2400s, including the base, must be configured with the
same tree routing ID, and have tree routing option enabled. In addition, R2, RS, and R6 must be assigned
individual BaseModeNet/D parameters, and then configured for router operation. The network IDs and
network addresses will be automatically assigned as the system forms. Figure 2.12.1.2 shows one way
that the network IDs and system addresses could be assigned.
Note that the routing nodes, R2, RS, and R6 have two network-related IDs - a ParentNetwork/D and a
BaseModeNetlD. The ParentNetwork/D is used by a router to join the tree-routing system, and the BaseModeNetlD is the ID the router uses to let other nodes join the system through it.
While the tree-routing system can form automatically, it is also possible to do additional node configuration to control how the system forms. The following sections provide details of all the tree routing related
configuration commands plus details of the addressing used in a tree routing system.
Example DNT2400 Tree Routing System
lg
----~
1•M---,o-,
'\g
Parent Network ID - Ox01
lg / ~
Parent Network ID - OxOO
Base Mode Network ID - Ox01
System Address - OxFF0100
Parent Network ID - Ox01
System Address - OxFF0102
'§
Network 10 _ OxOO
Add
o FFOOOO
-- •
Base Mode Network ID - Ox03
System Address - OxFF0300
~5-Router
Parent Network ID - OxOO
System Address - OxFF0001
Parent Network ID - OxOO
Base Mode Network ID - Ox02
System Address - OxFF0200
Network IDs and System Addresses shown in hexadecimal format
Figure 2.12.1.2
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
23 of 100
Page 21 of 97
DNT2400 - 04/13/11
www.murata.com
2.12.2 Tree-Routing System Networks
A DNT2400 tree-routing system consists of one base and up to 63 routers, where the base and each
router can forward messages to/from a total of 126 child radios (leases enabled) 1 • A child radio can be
either a remote or router, within the system limitation of 63 routers total.
Within a DNT2400 tree-routing system, a network refers to a group of radios communicating with a router
or base acting as a parent, and all of the child radios that are linked to this parent. Hop-by-hop, a router
alternates from being a child of its parent network on one hopping pattern to being a parent of its own
network on a different hopping pattern.
The base maintains a routing table that describes the organization of all routers in its system. This table is
used by the base and the routers to determine which direction, up to the base, or down to its children, to
route a packet. The base updates the routing table using information in the heartbeat packets it receives
from the routers in its system. The base periodically broadcasts this routing table to inform all system
radios of the current system configuration. All heartbeat packets received by the base are also output to
its host (PC). The default channel access for tree-routing systems is CSMA (mode 1).
2.12.3 Tree-Routing System Addressing
Except for tree-routing systems, DNT2400 remotes are addressed from the base using their three-byte
hardware MAC addresses. In turn, remotes address the base using the address OxOOOOOO, rather than
the base radio's hardware MAC address. In tree-routing systems, however, radios are addressed using
system addresses rather than their hardware MAC addresses. Much of the planning and commissioning
activities for a DNT2400 system involve configuring system addresses.
Like MAC addresses, tree-routing system addresses contain three bytes. However, the most significant
byte of a system address is currently unused and can be assigned any value (typically OxFF). The middle
byte of a system address is the network ID or Nwk/D of a base or router. The Nwk/D is always OxOO for
the base, and will have a value in the range of Ox01 to Ox3F for a router. The least significant byte of the
system address is called the network address or NwkAddr. The NwkAddr is always OxOO for the base and
all the routers in a system . For a remote, the NwkAddrwill have a value in the range of Ox01 to Ox7E, so
the system address of a remote will contain the Nwk/D of its parent base or router, plus its own NwkAddr.
Several parameters are involved in the formation of a DNT2400 tree-routing system. All radios that will
become part of a tree-routing system must set the TreeRouteEn parameter to Ox01. Further, all radios
must be loaded with the same tree-routing system ID parameter, referred to as the TreeRouteSys/D. This
parameter allows systems to physically overlap without ambiguity as to which system a radio should join .
When a DNT2400 radio is configured as the base, it automatically assumes a Nwk/D of OxOO and
NwkAddr of OxOO. When a radio is configured as a router, it automatically assumes a NwkAddr of OxOO.
The router's Nwk/D byte is held in its BaseModeNetlD parameter, and will have value in the range of
Ox01 to Ox3F. The BaseModeNetlD parameter must be manually set in all routers. As discussed below,
when a router's addressing is totally manually configured, the remote-mode NwkAddr (network address)
is loaded from a router's StaticNetAddress parameter, otherwise the default value OxFF of the parameter
should be preserved to allow dynamic assignment by the router's parent.
1. Tree-routing systems can run without leases enabled to remove the 126 child limit on the base and routers in some circumstances. However, this takes special system planning. Contact RFM technical support for details.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
24 of 100
Page 22 of 97
DNT2400 - 04/13/11
www.murata.com
The lnitia/ParentNwk/D parameter controls which parent a child router or remote can join. Setting this
value to OxOO forces a router or a remote to join with only the base. Setting this parameter to the Nwk/D of
a parent router forces a child router or a remote to join only this parent's network. Setting this parameter
to OxFF in a router or remote allows them to join with any parent.
The StaticNetAddr parameter controls the assignment of the NwkAddr byte in a remote's system address.
A remote's NwkAddr can be manually assigned by setting the StaticNetAddr to a value between Ox01 and
Ox7E. Setting the StaticNetAddr parameter to OxFF allows the remote's parent to dynamically assign a
NwkAddr.
As discussed above, an example DNT2400 tree-routing system is shown in Figure 2.12.1.2. The example
system includes remote R4 which is directly linked to the base, routers R2 and R5 which are directly
linked to the base, remotes R1 and R3 which are linked to router R2, remote R7 which is linked to router
R6, which in turn is linked to router R5. The parent network ID, the system address and for routes the
base-mode network ID are shown in hexadecimal format.
Note that when dynamic address assignment is used, the system addresses of some of the radios in the
system will not be immediately apparent. A radio's system address can be obtained by broadcasting a
Discover command from the base which contains the radio's hardware MAC address. The radio will send
a DiscoverReply with its system address. After joining one of the system networks, all routers and remotes periodically transmit heartbeat status messages that contains their MAC address, network address,
network ID and other information. Note that the address of any radio can be constructed as follows:
OxFF + NwklD + NwkAddr.
2.12.4 Tree-Routing System Implementation Options
There are three ways to assign parent network IDs and system addresses to the routers and remotes in a
tree-routing system - dynamic router parent and remote system address assignment, manual router
parent assignment with dynamic remote address assignment, and manual router parent and remote
address assignment.
Dynamic router parent and remote address assignment is the preferred method for most systems that
contain just a few routers. This assignment method provides several advantages. The router parent and
remote system addresses do not have to be pre-assigned, reducing initial system planning details. In
case of a parent failure, child devices will automatically attempt to join another parent. Once the system
becomes organized, heartbeat status messages and/or Discover commands can be used to log the
system addresses against the MAC addresses of each router and remote in the system.
Manual router parent assignment with dynamic remote address assignment is the preferred method for
most systems with a large number of routers. Manual router parent assignment avoids the possibility of
the system creating a long chain of parent router-child router links which would introduce unnecessary
message latency. However, manual router assignment precludes a child router from attempting to link
with another parent in case its parent router fails. The parent address of each router is known before the
system becomes organized, and heartbeat status messages and/or Discover commands can be used to
log the system addresses against the MAC addresses of each remote in the system.
Manual router parent and remote address assignment allows all radios addressing to be preplanned and
preset before a system is installed. Manual system addressing precludes child radios from attempting to
re-link to the system by joining another parent if the assigned parent fails, but simplifies application code
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
25 of 100
Page 23 of 97
DNT2400 - 04/13/11
www.murata.com
development by removing the need to dynamically update a database that matches system addresses to
MAC addresses for each router and remote. The task of manually assigning system addresses to all
routers and remotes in a tree-routing system can be somewhat tedious. Contact RFM's module technical
support group for the latest support tools for manual address assignment. Table 2.12.4.1 summarizes
radio parameter settings for each assignment method.
Dynamic Router Parent Assignment and Dynamic Remote System Address Assignment
Radio
lnitialParentNwklD
StaticNetAddress
BaseModeNetlD
Router
Remote
OxFF (join any parent)
OxFF (assigned by parent)
Ox01 - Ox3F (router NwklD)
OxFF (join any parent)
OxFF(assigned by parent)
OxFF (not used by remote)
Manual Router Parent Address Assignment with Dynamic Remote System Address Assignment
Radio
lnitialParentNwklD
StaticNetAddress
BaseModeNetlD
Router
OxOO - Ox3F (specifies parent)
OxFF (assigned by parent)
Ox01 - Ox3F (router NwklD)
Remote
OxFF (join any parent)
OxFF(assigned by parent)
OxFF (not used by remote)
Manual Router Parent and Remote System Address Assignment
Radio
lnitialParentNwklD
StaticNetAddress
BaseModeNetlD
Router
OxOO - Ox3F (specifies parent)
Ox01 - Ox7E (sent to parent)
Ox01 - Ox3F (router NwklD)
Remote
OxOO - Ox3F (specifies parent)
Ox01 - Ox07 (sent to parent)
OxFF (not used by remote)
Table 2.12.4.1
Tree-routing networks can support peer-to-peer communications. However, the value of the P2PReplyTimeout parameter (see Section 4.2.2) is interpreted differently in a tree-routing system compared to a
point-to-multipoint network. In a point-to-multipoint network, the P2PReplyTimeout parameter is in units of
hops. In tree-routing systems, this parameter is in units of hop pairs, due to the system routers alternating
between remote mode and base mode hop-by-hop. Referring to Figure 2.12.1.2, the minimum useable
value for peer-to-peer communications between Remote 1 and Remote 7 is determined as follows:
Route Segment
Required Hops
Remote R1 to Router R2
Router R2 to Base
Base Turn Around
Base to Router RS
Router RS to Router R6
Router R6 to Remote R7
Remote R7 Reply Turn Around
Remote R7 to Router R6
Router R6 to Router RS
Router RS to Base
Base Turn Around
Base to Router R2
Router R2 to Remote R1
Total
13
Table 2.12.4.2
The minimum number of hops required is 13, so the minimum P2PReplyTimeout parameter value would
be 7 hop pairs. This minimum value provides no tolerance for transmission retries . Selecting a value 50%
to 100% larger is recommended, in the range of 11 to 14 hop pairs.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
26 of 100
Page 24 of 97
DNT2400 - 04/13/11
www.murata.com
2.13 Serial Port Operation
DNT2400 networks are often used for wireless communication of serial data. The DNT2400 supports
serial baud rates from 1.2 to 460.8 kb/s. Listed in Table 2.13.1 below are the supported data rates and
their related byte data rates and byte transmission times for an 8N1 serial port configuration :
Baud Rate kb/s
Byte Data Rate kB/s
Byte Transmission Time ms
1.2
0.12
8.3333
2.4
0.24
4.1667
4.8
0.48
2.0833
9.6
0.96
1.0417
19.2
1.92
0.5208
28.8
2.88
0.3472
38.4
3.84
0.2604
57.6
5.76
0.1736
76.8
7.68
0.1302
115.2
11 .52
0.0868
230.4
23.04
0.0434
460.8
46.08
0.0217
Table 2.13.1
To support continuous full-duplex serial port data flow, an RF data rate higher than the serial port baud
rate is required for FHSS. Radios transmissions are half duplex, and there are overheads related to
hopping frequencies, assembling packets from the serial port data stream, transmitting them, sending
ACK's to confirm error-free reception, and occasional transmission retries when errors occur.
For example, consider a TOMA mode 2 system with one remote operating up to 20 miles away at
500 kb/s, with the BaseSlotSize parameter set to 64 bytes and the RemoteSlotSize parameter set to 64
bytes. As shown in Figure 2.13.1, the hop duration from the ONT Throughput Calculator program for this
configuration is 4.85 ms :
EIDNT Tt-.-ou ll;ut Calculator
Calculate Hop Duralion
i.l
Js1a,
.J
Caloulate Remole Slot Size
nr D11111 nl'lt...,
nr r.i ..r .. n ... 11'!
j:WF:.~p1
t.lul!N' of Fl erootet
Hu~ Dw.._,n
.,
R.note Slot Sile
0-0)S-
H ~1•11~ l l•uuilla,ul
- .:l.:.:'.IJS::1:','·;
u .. 1-r l hroughpul
· J.:JJ i:: u; ,
NWT1ber of Rernotei:
Hop Dwallion CGUl'ltc
:J
:-1.8: rr~I
ts: " :.:
Ur:.H lhroughpull
l"J , U<._11
Figure 2.13.1
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
27 of 100
Page 25 of 97
DNT2400 - 04/13/11
www.murata.com
The average full-duplex serial port byte rate that can be supported under error free conditions is:
64 Bytes/4.85 ms
= 13.2 kB/s, or 132 kb/s for 8N1
Continuous full-duplex serial port data streams at a baud rate of 115.2 kb/s can be supported by this
configuration, provided only occasional RF transmission errors occur. Plan on an average serial port data
flow of 90% of the calculated error-free capacity for general-purpose applications.
The DNT2400 transmit and receive buffers hold at least 1024 bytes and will accept brief bursts of data at
high baud rates, provided the average serial port data flow such as shown in the example above is not
exceeded. It is strongly recommended that the DNT2400 host use hardware flow control in applications
where the transmit buffer can become full. The host must send no more than 32 additional bytes to the
DNT2400 when the DNT2400 de-asserts the host's CTS line. In turn, the DNT2400 will send no more
than one byte following the host de-asserting its RTS line. Three-wire serial port operation is allowed
through parameter configuration, as discussed in Section 4.2.4. However, data loss is possible under
adverse RF channel conditions when using three-wire serial operation due to buffer overruns.
2.14 SPI Port Operation
The DNT2400 SPI port data rate is configurable in 127 steps from 6.35 to 80.64 kb/s using the SP/_
Divisor parameter. The SPI data rate is the clocking rate the DNT2400 uses in Master mode. The SPI
data rate is also used in Slave mode to time SPI Select (/SS) sampling, etc. Where possible, devices
connected to the DNT2400 SPI port should be configured to match the 80.64 kb/s data rate. In any event,
the SPI data rate used by the DNT2400 and the connected device should be matched within a few percent for efficient data transfers. SPI port operation is full duplex in the sense that a single clock signal
simultaneously shifts data into and out of the SPI port. In order for the Master (host) to receive data from
a DNT2400 SPI Slave, it must clock bytes into the DNT2400.
As show in Figure 2.14.1, DNT2400 SPI slave mode operation is supported by two control signals from
the DNT2400. The /HOST_CTS line provides the same flow control function for SPI Slave mode as it
does for the serial (UART) port. The Master (host) can clock messages into the DNT2400 SPI Slave
whenever /HOST_ CTS is set to a logic low state. The Master can complete clocking one protocol formatted message into the DNT2400 if /HOST_CTS switches high part way through the message as shown in
Figure 2.14.2, but must then stop sending transmit message bytes until the DNT2400 resets /HOST_CTS
to a logic low state. If the DNT2400 slave is holding a received message(s) when the SPI master clocks in
a message to transmit, received message bits will be simultaneously clocked out on the MISO line while
the message to be transmitted is clocked in on the MOSI line. The end of a received message will often
not be aligned with the end of a message to be transmitted, so additional clocking may be required to
complete the transfer of a received message(s). It is acceptable to clock OxOO null bytes in on the MOSI
line to retrieve received message bytes when /HOST_CTS is high, but not transmit message bytes.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
28 of 100
Page 26 of 97
DNT2400 - 04/13/11
www.murata.com
DNT2400 SPI Slave Mode Signaling
/HOST CTS
SPI_RX_AVL
Host
MISO
DNT24DO
MOSI
SCLK
/SS
Figure 2.14.1
DNT2400 SPI Slave Mode TX Message Load
/SS
/HOST_CTS
SPIBltClock
SCLK
MOSI
Protocol Form- TX Message
MISO
Null or RX Message Bytes
Figure 2.14.2
DNT2400 SPI Slave Mode RX Message Retrieval
SPI_RX_AVL
/SS
SPI Bit Clock
SCLK
MISO
MOSI
9to 10
Null Bytes
Protocol Fonn-d RX Menage
Null or TX Message Bytes
Figure 2.14.3
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
29 of 100
Page 27 of 97
DNT2400 - 04/13/11
www.murata.com
GPIO port 4 can be alternately configured to provide a received message flag, referred to as SPI_RX_
AVL. Operation of this line is shown in Figure 2.14.3. Once the SPI_RX_AVL flag goes high, RX message
bytes can be clocked out on the MISO line by clocking OxOO null bytes and/or transmit message bytes in
on the MOSI line. Note that nine to ten OxOO null bytes will precede each received message, which is
always protocol formatted . Following the null bytes, the OxFB start of message symbol will then be
clocked out, followed by the message length byte. The length byte can be used to confirm that all the
bytes in each received message have been clocked out. If a DNT2400 slave is holding more than one
received message, the SPI_RX_AVL flag will remain high until all messages have been completely
clocked out.
In SPI slave mode, de-asserting and then asserting the /SS line resets the DNT2400 SPI port on a byte
boundary. The /SS line can be toggled this way between every byte to assure bit streams into and out of
the SPI port remain byte framed . Less frequent /SS line toggling is also acceptable in most applications. It
is recommended that /SS be toggled at the start and end of each transmit message, and after every 256
null bytes when clocking to output a received message. The /SS line should also be toggled at the end of
each received message.
DNT2400 SPI Master Mode Signaling
MISO
Peripheral
MOSI
SCLK
DNT2400
/SS
Figure 2.14.4
Figure 2.14.4 shows the signals a DNT2400 uses in SPI Master mode. When periodic 1/0 reporting is
enabled on a DNT2400 remote configured as an SPI Master, the remote will clock out a stored command
string, SPI_MasterCmdStr, to collect data from a Slave peripheral each time the 1/0 report timer fires. The
collected data is then transmitted as a TXData message. Alternatively, a host connected to the base can
transmit an SPI command as a T XData message to the remote. The remote will clock the command into
its Slave peripheral and transmit back the Slave's response, as show in Figure 2.14.5. In either case, the
command string and response string are limited to 32 bytes. Only data messages are routed through the
DNT2400's SPI port in Master mode. Command packets and command replies are routed through the
primary serial port. See Section 4.2.4 for additional SPI parameter details.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
30 of 100
Page 28 of 97
DNT2400 - 04/13/11
www.murata.com
DNT2400 SPI Master Mode Operation
/SS
SCLK
SPI Bit Clock
MOSI
Parlpharal Control Command
MISO
Peripheral Response Bytes
Figure 2.14.5
2.15 Sleep Modes
To save power in applications where a remote transmits infrequently, the DNT2400 supports hardware
and firmware sleep modes. Hardware sleep mode is entered by switching SLEEP/DTR Pin 11 on the
DNT2400 from logic low to high. While in hardware sleep mode, the DNT2400 consumes less than 50 µA
at room temperature. This mode allows a DNT2400 to be powered off while its host device remains
powered. After leaving hardware sleep mode, the radio must re-synchronize with the base and reregister. Note that sleep mode is not available on tree-routing routers.
In addition to the sleep mode controlled by Pin 11, in CSMA mode the DNT2400 remotes support an
additional sleep mode to support battery-powered applications. When this mode is enabled, the DNT2400
is in a low-power state and only wakes up in response to the 1/0 report triggers. The following list explains
the rules that sleeping remotes follow:
•
The DNT2400 will wake up when any of the enabled 1/0 report trigger conditions fire. When any
of the ADC triggers are enabled, the radio will also wake up every ADC_Samplelntvl long enough
to sample the ADCs, and then go back to sleep.
•
When a sleeping radio wakes up, it must acquire and synchronize to its base before it can send
or receive any data. To prevent excessive battery use, if the remote is unable to acquire before
the WakeUnkTimeoutelapses (because it is no longer in range, for example), it will cancel any
pending event trigger(s) and go back to sleep.
•
If a remote is linking for the first time or if its last attempt to acquire and synchronize was unsuccessful, it will scan and record the entire broadcast system parameter list before it goes back to
sleep. Otherwise, in order to conserve battery life, a sleeping remote will update any values that it
may hear while it is awake, but is not required to listen to the entire list.
•
If a remote is linking for the first time or if its last attempt to acquire and synchronize was unsuccessful, it will send a registration request to the base, allowing it to announce its presence to the
host. Otherwise, in order to conserve battery life, a sleeping remote will not register each time it
reacquires link with its base on successive wakeups.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
31 of 100
Page 29 of 97
DNT2400 - 04/13/11
www.murata.com
•
After a remote has received an acknowledgement for its 1/0 report, a WakeResponseTime timer
is started before the remote goes back to sleep. This allows the base host time to send a message to the remote. Note that the only notification that the base host application has that a remote
is awake is its report packet. In order to send it data, the base host must ensure that the message
is transmitted and received before the remote's WakeResponseTime window elapses. If this function is not needed, the WakeResponseTime can be set to zero to disable it.
The lease renewal mechanism is not supported for sleeping remotes. In order to successfully use sleeping remotes, the user must ensure that the system is configured for CSMA mode and that leases are
disabled. If these settings are not used, there is no guarantee that the remotes will be able to communicate reliably. Because leases are not supported, there is no built-in mechanism for the base to detect or
announce to its host if a remote leaves the network.
To summarize, while a remote is awake, the following list of condition checks are used to determine if and
when it is allowed to go back to sleep:
•
If the remote is linking for the first time or was unsuccessful linking on its last attempt, it will remain awake to record the beacon system parameter list.
•
At wakeup, the WakeUnkTimeouttimer is started. If the remote is unable to acquire link before
this elapses, it goes back to sleep.
•
If the remote receives an acknowledgement for a data packet it has sent (typically an Event
packet, but in theory it could be any other type of message), it starts or resets the WakeResponseTime timer to remain awake.
•
So long as a GPIO for which 1/0 reporting is enabled for a level trigger remains in its triggered
state, the remote will remain awake.
•
The remote will remain awake while it still has any ARO attempts left for a queued transmit
packet of any type.
•
The remote will remain awake while it is has serial characters in its buffer left to transmit to its
local host.
Sleep functions are controlled by the following registers (see Section 4.2):
•
S/eepMode - enables/disables sleep mode.
•
WakeResponseTime - sets the amount of time that a remote will wait for a
response after sending an 1/0 report.
•
WakeUnkTimeout- sets the maximum time that a remote will spend trying
to acquire it base before giving up.
Sleep is also affected by the following registers associated with 1/0 reporting: JO_ReportTrigger,
JO_Reportlnterval, ADC_Samplelntvl, and GPIO_EdgeTrigger. The following table indicates how the
status and control pins function on sleeping remotes:
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
32 of 100
Page 30 of 97
DNT2400 - 04/13/11
www.murata.com
Awake
Sleep
/HOST RTS
Normal operation
high impedance
/HOST CTS
Normal operation
/DCD
Normal operation
Normal operation
ov
ov
ov
ov
RADIO_TXD
Normal operation
Hi-2
RADIO_RXD
Normal operation
ov
Pin
ACT
DIVERSITY
3V
Table 2.15.1
Note that the ACT pin may be used by a local host to detect when a sleeping remote is awake. The
behavior of the GPIOs during sleep is governed by the GP/0_ SleepMode, GPIO_SleepDir, and
GPIO_SleepState configuration registers. Refer to the register definitions in Section 4.2.
2.16 Encryption
The DNT2400 supports 128-bit AES encryption of data and configuration packets. Encryption is enabled
by setting the EncryptionKey register to a value other than a string of NULL (OxOO) bytes. A remote without encryption enabled cannot link to an encrypted base, and an encrypted remote will not attempt to link
to an unencrypted base. A remote's encryption key must match that of the base before it can link. The
EncryptionKey register can be set over the air so it can be changed periodically if desired. Once an
encryption key has been entered, it can be changed but it cannot be read back.
2.17 Synchronizing Co-located Bases
The EX_SYNC input (Pin 15) on the DNT2400 allows co-located bases to synchronize their transmissions
so they all transmit at the same time. This prevents the situation where one base is transmitting while
another nearby base is trying to hear a distant remote. Even though the base radios may be on different
frequencies, because of their close proximity, the transmitting base can reduce the receiving base's ability
to hear distant remotes. The EX_SYNC input has the following characteristics:
1.
Base radios trigger on the rising edge of the pulse applied to their EX_SYNC input.
2.
All co-located bases must use the same hop duration and the period of the pulse train applied to
the EX_SYNC input must be within ±10 µs of this hop duration.
3.
The co-located bases must use different network IDs but the same frequency subband, which assures they are using different hopping patterns.
4.
A "narrow" pulse of 50 to 800 µs triggers base beacon synchronization. A train of narrow pulses
as described above will synchronize a group of co-located base stations after a period of time.
5. An optional "wide" pulse of 1 to 2 ms triggers a hopping pattern reset. Note: a wide pulse
can only be used in ETSI applications. It is not allowed under FCC and Canadian IC
regulations. The benefit provided by the wide pulse is to keep co-located networks from ever being on the same frequency at the same time. When the wide pulse is not used, it is possible that
co-located networks may occasionally try to transmit on the same frequency at the same time.
This can slightly reduce the network throughput. Where a wide pulse can be used, it should be
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
33 of 100
Page 31 of 97
DNT2400 - 04/13/11
www.murata.com
sent to reset all base patterns to their first frequency following the reset or power-up of any of the
co-located bases. Thereafter a cycle of N -1 narrow pulses and then 1 wide pulse should be sent,
where N is the number of frequencies in the subband being used . For example, if the frequency
subband contains 15 frequencies, a repeating cycle containing 1 wide pulse followed by 14 narrow pulses should be used.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
34 of 100
Page 32 of 97
DNT2400 - 04/13/11
www.murata.com
3.0 DNT2400 Hardware
DNT2400 Block Diagram
PKT_DET
RSVD
RSSI
GPIOO
GPl01
CLK
GPI02
SI
GPI03
so
PWMO
PWM1
Microcontroller
csn
RF
Transceiver
INT
SLEEP
PKTDET
ADC2
ADC1
ADCO
/CFG
vcc
GND
3,3V
3.6V
Figure 3.0.1
The major components of the DNT2400 include a 2.4 GHz FHSS transceiver and a low current 32-bit
microcontroller. The DNT2400 operates in the 2.4 GHz ISM band. The module includes nine frequency
subbands and 37 total frequency channels to support the various 2.4 GHz frequency allocations used
throughout the world. The DNT2400 has three selectable RF output power levels: 1, 10, and 63 mW.
Also, there are four selectable RF transmission rates : 38.4, 115.2, 200 and 500 kb/s. The DNT2400
includes a low-noise receiver preamplifier and a high efficiency transmitter amplifier, providing excellent
range in outdoor applications.
The DNT2400 provides a variety of hardware interfaces. There are two serial ports plus one SPI port.
Either the primary serial port or the SPI port can be selected for data communications. The second serial
port is dedicated to diagnostics. The primary and diagnostic serial ports support standard baud rates up
to 460.8 kb/s. The SPI port supports data rates up to 80.64 kb/s. Also included are three 10-bit ADC
inputs, two 8-bit PWM outputs, and six general-purpose digital 1/0 ports. Four of the digital 1/0 ports
support an optional interrupt-from-sleep mode when configured as inputs. The radio is available in two
mounting configurations. The DNT2400C is designed for solder reflow mounting. The DNT2400P is
designed for plug-in connector mounting.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
35 of 100
Page 33 of 97
DNT2400 - 04/13/11
www.murata.com
3.1 DNT2400 Specifications
Sym
Characteristic
Operating Frequency Range
Minimum
Maximum
Units
2409.3
2467.1
MHz
200
ms
Hop Dwell Time
Typical
Number of Frequency Hopping Subbands
Number of RF Channels in a Subband
15
37
Modulation
FSK/MSK
RF Data Transmission Rates
38.4, 115.2, 200 and 500
kb/s
10·5 BER @ 38.4 kb/s
-104
dBm
10·5 BER @ 200 kb/s
-96
dBm
10·5 BER @ 500 kb/s
-90
dBm
1, 10, 63
mW
50
Receiver Sensitivity:
Transmitter RF Output Power Levels
Optimum Antenna Impedance
RF Connection
U.FL Connector
Point-to-Point, Point-to-Multipoint
Peer-to-Peer, Tree Routing
Network Topologies
Access Schemes
TOMA and CSMA
Number of Network Nodes:
TOMA
16
CSMA
unlimited
ADC Input Range
ADC Input Resolution
3.3
10
Signal Source Impedance for ADC Reading
bits
Kn
10
PWM (DAC) Output Range
PWM (DAC) Output Resolution
PWM Output Period
Primary and Diagnostic Serial Port Baud Rates
Serial Peripheral Interface Data Rate
3.3
bits
20
µs
1.2, 2.4, 4.8, 9.6, 19.2, 28.8, 38.4, 57.6, 76.8,
115.2, 230.4, 460.8
kb/s
6.35
80.64
kb/s
-0.5
0.8
Digital 1/0 :
Logic Low Input Level
Logic High Input Level
3.3
Logic Input Internal Pull-up Resistor
50
200
Kn
Logic Input Internal Pull-down Resistor
50
180
Kn
+3.3
+5.5
Vdc
10
mVp.p
300
mA
Power Supply Voltage Range
Vee
Power Supply Voltage Ripple
Peak Transm it Mode Current, 63 mW Output
Average Operating Receive Current:
Base
105
mA
Remote, No Data Transmission
35
mA
Remote, 9.6 kb/s Continuous Data Stream
40
mA
Remote, 115.2 kb/s Continuous Data Stream
53
Sleep Current
50
mA
225 1
µA
Operating Temperature Range
-40
85
oc
Operating Relative Humidity Range (non condensing)
10
90
1. Maximum sleep current occurs at +85 °C
Table3.1.1
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
36 of 100
Page 34 of 97
DNT2400 - 04/13/11
www.murata.com
3.2 Module Interface
Electrical connections to the DNT2400C are made through the 1/0 pads and through the 1/0 pins on the
DNT2400P. The hardware 1/0 functions are detailed in the table below:
Pad
Name
1/0
Description
PKT_DET
Packet detect output. Signal switches logic high at the end of the start-of-packet symbol and
switches logic low at the end of the end-of-packet symbol on both received and transmitted packets.
PKT_DET provides a timing reference for use in network timing evaluations, etc.
RSVD
Reserved pad. Leave unconnected.
ADC_REF
ADC supply and external full scale reference voltage input. Voltage range is 2.4 to 3.3 Vdc. Connect
pad 34 to this input to reference the ADC full scale reading to the module's 3.3 V regulated supply.
RSVD
Reserved pad. Leave unconnected.
GPIOO
1/0
Configurable digital 1/0 port 0. When configured as an input, an internal pull-up resistor can be
selected and interrupt from sleep can be invoked. When configured as an output, the power-on state
is also configurable. Sleep mode direction and state are also configurable.
GPl01
1/0
Configurable digital 1/0 port 1. Same configuration options as GPIOO.
GPl02
1/0
Configurable digital 1/0 port 2. Same configuration options as GPIOO.
GPI03
1/0
Configurable digital 1/0 port 3. Same configuration options as GPIOO, with RS485 driver enable an
alternate function .
PWMO
8-bit pulse-width modulated output O with internal low-pass filter. Filter is 1st order, 159 Hz 3 dB BW.
10
PWM1
8-bit pulse-width modulated output 1 with internal low-pass filter. Filter is 1st order, 159 Hz 3 dB BW.
11
SLEEP/DTR
Default functionality is active high module sleep input (active low DTR). When switched low after
sleep, the module executes a power-on reset. Usually connected to host DTR.
12
ADC2
10-bit ADC input 0. Full scale reading is referenced to the ADC_REF input.
13
ADC1
10-bit ADC input 1. Full scale reading is referenced to the ADC_REF input.
14
ADCO
10-bit ADC input 2. Full scale reading is referenced to the ADC_REF input.
15
EX_SYNC
Rising-edge triggered input for synchronizing co-located bases. Synchronization pulse interval must
equal the hop dwell time ±10 µs. Pulse width must be in the range of 50 to 800 µs.
16
DIAG_TX
Diagnostic UART transmitter output.
17
DIAG_RX
Diagnostic UART receiver input.
18
/CFG
Protocol selection input. Leave unconnected when using software commands to select transparent/protocol mode (default is transparent mode). Logic low selects protocol mode, logic high selects
transparent mode.
19
vcc
Power supply input, +3.3 to +5.5 Vdc.
20
GND
Power supply and signal ground. Connect to the host circuit board ground.
21
GND
Power supply and signal ground. Connect to the host circuit board ground.
22
GPI04
1/0
Configurable digital 1/0 port 4. When configured as an input, an internal pull-up resistor can be
selected. When configured as an output, the power-on state is configurable. The SPI RX data
available flag, SPI_RX_AVL, is a configurable alternate function.
23
GPl05
1/0
Configurable digital 1/0 port 5. Same configuration options as GPI04, with antenna diversity control
an alternate function.
24
GND
Logic ground.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
37 of 100
Page 35 of 97
DNT2400 - 04/13/11
www.murata.com
25
ACT
Data activity output, logic high when data is being transmitted or received .
26
/DCD
Default functionality is data carrier detect output, which provides a logic low on a remote when the
module is locked to FHSS hopping pattern and logic low on a base when at least one remote is
connected to it.
27
RSVD
Reserved pad. Leave unconnected.
28
RSVD
Reserved pad. Leave unconnected.
29
RSVD
Reserved pad. Leave unconnected.
30
/HOST_RTS
UART flow control input. The host sets this line low to allow data to flow from the DNT2400 on the
RADIO_TXD pin. When the host sets this line high, the DNT2400 will stop sending data.
31
RADIO_TXD
UART transmitter output. The DNT2400 sends serial data to the host on this pin. The sleep mode
state of this pin is configurable.
32
RADIO_RXD
UART receiver input. The DNT2400 receives serial data from the host on this pin.
33
/HOST_CTS
UART or SPI flow control output. The DNT2400 sets this line low to indicate it is ready to accept data
from the host on the RADIO_RXD or MOSI input. When the DNT2400 sets th is line high, the host
must stop sending data. The sleep mode state of this pin and /DCD is jointly configurable.
34
VMOD
Module's +3.3 V regulated supply output. Connect to pad 3 to support 3.3 V full scale and/or
ratiometric ADC readings, etc. Current drain on this output should be no greater than 5 mA.
35
/SS
36
MOSI
37
MISO
38
SCLK
SPI active low slave select. This pin is an output when the DNT2400 operating as a master, and an
input when it is operating as a slave.
SPI master out, slave in function. This pin is an output when the DNT2400 is operating as a master,
and is an input when the DNT2400 is operating as a slave.
SPI master in, slave out function. This pin is an input when the DNT2400 is operating as a master,
and is an output when the DNT2400 is operating as a slave.
SPI clock signal. This pin is an output when operating as a master, and an input when operating
as a slave.
39
/RESET
Active low module hardware reset.
40
RSVD
Reserved pad. Leave unconnected.
Table 3.2.1
3.3 DNT2400 Antenna Connector
A U.FL miniature coaxial connector is provided on both DNT2400 configurations for connection to the
RFIO port. A short U.FL coaxial cable can be used to connect the RFIO port directly to an antenna. In this
case the antenna should be mounted firmly to avoid stressing the U.FL coaxial cable due to antenna
mounting flexure. Alternately, a U.FL coaxial jumper cable can be used to connect the DNT2400 module
to a U.FL connector on the host circuit board. The connection between the host circuit board U.FL
Circuit Board Stripline Trace Detail
For 50 ohm impedance W = 1.75 * H
Figure 3.3.1
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
38 of 100
Page 36 of 97
DNT2400 - 04/13/11
www.murata.com
Trace Separation from
Length of Trace Run
50 ohm Microstrip
Parallel to Microstrip
100 mil
125 mill
150 mil
200mil
200mil
290mil
250mil
450mil
300mil
650mil
Table 3.3.2
connector and the antenna or antenna connector on the host circuit board should be implemented as a
50 ohm stripline. Referring to Figure 3.3.1, the width of this stripline depends on the thickness of the
circuit board between the stripline and the groundplane. For FR-4 type circuit board materials (dielectric
constant of 4.7), the width of the stripline is equal to 1.75 times the thickness of the circuit board. Note
that other circuit board traces should be spaced away from the stripline to prevent signal coupling, as
shown in Table 3.3.2. The stripline trace should be kept short to minimize its insertion loss.
3.4 Input Voltages
DNT2400 radio modules can operated from an unregulated DC input (Pad 19) in the range of 3.3 to 5.5 V
with a maximum ripple of 5% over the temperature range of -40 to 85 °C. Applying AC, reverse DC, or a
DC voltage outside the range given above can cause damage and/or create a fire and safety hazard.
Further, care must be taken so logic inputs applied to the radio stay within the voltage range of O to 3.3 V.
Signals applied to the analog inputs must be in the range of Oto ADC_REF (Pad/Pin 3). Applying a
voltage to a logic or analog input outside of its operating range can damage the DNT2400 module.
3.5 ESD and Transient Protection
The DNT2400C and DNT2400P circuit boards are electrostatic discharge (ESD) sensitive. ESD precautions must be observed when handling and installing these components. Installations must be protected
from electrical transients on the power supply and 1/0 lines. This is especially important in outdoor installations, and/or where connections are made to sensors with long leads. Inadequate transient protection
can result in damage and/or create a fire and safety hazard.
3.6 Interfacing to 5 V Logic Systems
All logic signals including the serial ports on the DNT2400 are 3.3 V signals. To interface to 5 V signals,
the resistor divider network shown in Figure 3.5.1 below must be placed between the 5 V signal outputs
and the DNT2400 signal inputs. The output voltage swing of the DNT2400 3.3 V signals is sufficient to
drive 5 V logic inputs.
sv
Logic
DNT2400
2.2K
4.3K
Figure 3.6.1
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
39 of 100
Page 37 of 97
DNT2400 - 04/13/11
www.murata.com
3. 7 Power-On Reset Requirements
When applying power to the DNT2400, the /RESET Pin 39 and the RADIO_TXD Pin 31 must be initially
held low. The /RESET pin must be held low until the power supply voltage reaches 3.3 volts for 100 ms,
and then set high. The RADIO_TXD must be held low an additional 10 ms after the /RESET pin goes
high. RADIO_TXD is weakly pulled down with a 1OOK ohm resistor to meet the power-on reset require­
ment, unless this line is driven high by an external signal.
3.8 Mounting and Enclosures
DNT2400C radio modules are mounted by reflow soldering them to a host circuit board. DNT2400P
modules are mounted by plugging their pins into a set of mating connectors on the host circuit board.
Refer to Section 8.3 and/or the DNT2400 Data Sheet for DNT2400P connector details.
DNT2400 enclosures must be made of plastics or other materials with low RF attenuation to avoid com­
promising antenna performance where antennas are internal to the enclosure. Metal enclosures are not
suitable for use with internal antennas as they will block antenna radiation and reception. Outdoor enclo­
sures must be water tight, such as a NEMA 4X enclosure.
3.9 Labeling and Notices
Labeling:
A clearly visible label is required on the outside of the user's (OEM) enclosure stating the following:
"Contains FCC ID: HSW-DNT2400P"
"Contains IC: 4492A-DNT2400P"
Notices:
The DNT2400PC and DNT2400PP is qualified for use as a Portable device (body worn) if - and only if the following conditions are met. Variance from these requirements may result in harmful operation to the
user and will violate FCC RF Exposure rules.
1. Antenna Gain - the antenna must be of a type already approved and have a maximum gain of
less than 3.47 dBi.
2. The DNT2400 transmit duty cycle may not exceed 15.2% for the device to be used in a Portable
application.
This transmit duty cycle must be calculated as follows:
Tduty= ((Max_Bytes + Overhead_Bytes)*8)/(0TA Data Rate))/(Tdwel�
Where:
Tduty- is the resultant transmit duty cycle (in fractions of a unit)
Tdwe/1- is the frequency hopping dwell time (in seconds)
www.RFM.com
Technical support+1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
40 of 100
Page 38 of 97
DNT2400 - 04/13/11
www.murata.com
OTA Data Rate - is the over the air data rate in bits per second (note - this is not the user interface rate)
Overhead_Bytes - is the number of bytes sent along with the data packet by the DNT2400,
equal to 5 bytes
Max_Bytes - is the maximum amount of bytes that can be sent to the DNT2400 from the Host in
any Tdwe/1 number of seconds.
If in doubt about any values entered in this calculation or in the execution of the calculation, please contact Murata Applications for assistance.
WARNING: This device operates under Part 15 of the FCC rules. Any modification to this device, not
expressly authorized by Murata Manufacturing Co., Ltd., may void the user's authority to operate this
device.
FCC NOTICE: 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.
This apparatus complies with Health Canada’s Safety Code 6 /ISED RSS 247.
ISED RSS-247 Notice - Operation is subject to the following two conditions: (1) this device may not
cause interference, and (2) this device must accept any interference, including interference that may
cause un- desired operation of the device.
Cet appareil est conforme au Code de sécurité 6 de Santé Canada / ISED RSS 247.
ISED RSS-247 Avis - Le fonctionnement est soumis aux deux conditions suivantes: (1) ce dispositif
ne peut pas provoquer d'interférences et (2) cet appareil doit accepter toute interférence, y compris
les interférences qui peuvent causer un fonctionnement indésirable de l'appareil.
ICES-003
This digital apparatus does not exceed the Class B limits for radio noise emissions from digital
apparatus as set out in the radio interference regulations of ISED Canada.
Le present appareil numerique n’emet pas de bruits radioelectriques depassant les limites applicables
aux appareils numeriques de Classe B prescrites dans le reglement sur le brouillage radioelectrique
edicte par ISED Canada.
Under Industry Canada regulations, this radio transmitter may only operate using an antenna of a type and
maximum (or lesser) gain approved for the transmitter by Industry Canada. To reduce potential radio
interference to other users, the antenna type and its gain should be so chosen that the equivalent
isotropically radiated power (e.i.r.p.) is not more than that necessary for successful communication.
This radio transmitter, IC: 4492A-DNT2400P, has been approved by Industry Canada to operate with
the antenna types listed below with the maximum permissible gain and required antenna impedance
for each antenna type indicated. Antenna types not included in this list, having a gain greater than the
maximum gain indicated for that type, are strictly prohibited for use with this device.
www.RFM.com
Technical support+1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
41 of 100
Page 39 of 97
DNT2400 - 04/13/11
www.murata.com
En vertu des règlements d'Industrie Canada, cet émetteur radio ne peut fonctionner à l'aide d'une
antenne d'un type et maximum (ou moins) Gain approuvé pour l'émetteur par Industrie Canada. Pour
réduire les interférences radio potentielles pour les autres utilisateurs, le type d'antenne et son gain
doivent être choisis de manière que la puissance isot-ropically rayonnée équivalente (e.i.r.p.) ne
dépasse pas ce qui est nécessaire pour une communication réussie.
Cet émetteur radio, IC: 4492A-DNT2400P, a été approuvé par Indus¬try Canada pour fonctionner avec
les types d'antenne énumérés ci-dessous avec le gain maximal admissible et de l'impédance d'antenne
re¬quired pour chaque type d'antenne indiqué. types d'antennes non inclus dans cette liste, ayant un
gain supérieur au gain maximum indiqué pour ce type, sont strictement interdits pour une utilisation
avec cet appareil.
RFM OMNl249 Omnidirectional Dipole Antenna, 9 dBi, 50 ohms
RFM PA2400 Patch Antenna, 6 dBi, 50 ohms
This device does not comply with ISED exposure limits for portable applications. Any use for portable
applications in Canada is strictly prohibited.
Ce dispositif ne respecte pas les limites d'exposition ISED pour les applications portables. Toute utilisation
pour les applications portables au Canada est strictement interdite.
Canadian ICES-003 - This digital apparatus does not exceed the Class B limits for radio noise emissions from
digital apparatus as set out in the radio interference regulations of Industry Canada.
Le present appareil numerique n'emet pas de bruits radioelectriques depassant les limites applicables aux
appareils numeriques de Classe B prescrites dans le reglement sur le brouillage radioelectrique edicte par
lndustrie Canada.
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
DNT2400 10/25/16
42 of 100
www.murata.com
4.0 Protocol Messages
4.1 Protocol Message Formats
The DNT2400 is configured and controlled through a series of protocol mode messages. All protocol
mode messages have a common header format:
SOP
Length
PktTyp e
3 ...
I variable number of arguments ...
Figure 4.1.1
The scale above is in bytes.
The Start-of-Packet (SOP) character, OxFB, is used to distinguish the beginning of a message and to
assure synchronization in the event of a glitch on the serial port at startup.
The Length byte is defined as the length of the remainder of the message following the length byte itself
(or the length of the entire message - 2).
The Packet Type (PktType) byte specifies the type of message. It is a bitfield-oriented specifier, decoded
as follows:
Bits
Bit
Bit
Bits
7-6
3-0
Reserved for future use
Event - set to indicate this message is an event
Reply - set to indicates this message is a reply
Type - indicates the message type/command
As indicated, the lower 4 bits (3-0) specify a message type. Bit 4 is a modifier indicating that the message
is a command or a reply. A reply message has the original command type in bits 3:0, with bit 4 set to one.
Arguments vary in size and number depending on the type of message and whether it is a message sent
from the host or is a reply from the radio; see Table 4.1.2.1 below. Messages that are generated on the
serial interface by the user are referred to as host messages. Messages that are generated by the radio
are referred to as reply messages. For many message types, there is a reply message that corresponds
to a host message. For example, when the host sends a TxData message, the radio will reply to indicate
the status of the transmission, whether it succeeded or failed. Some message types are host-only or
reply-only; refer to Table 4.1.2.1 for specifics.
4.1.1 Message Types
Each message generally has two forms, a command from the host and a reply from the radio. Depending
on the direction, they have different arguments as shown in Table 4.1.2.1. Event messages from the radio
such as received data packets or status announcements make up a third category of messages. To assist
in interpreting the command-reply data flow, the direction is indicated by the high nibble in the message
type. For example, an EnterProtoco/Mode command from the host is a message type OxOO, and the
EnterProtoco/ModeReply from the radio is a message type Ox10. Event messages, including RxData,
RxEvent and Announce packets are indicated by Ox20 in the high nibble of the type byte. If multiple
arguments are to be provided, they are to be concatenated in the order shown. Little-Endian byte format
www.RFM.com
Technical support+1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
43 of 100
Page 40 of 97
DNT2400 - 04/13/11
www.murata.com
is used for all multi-byte arguments, where the lowest order byte is the left-most byte of the argument and
the highest order byte in the right-most byte of the argument.
4.1.2 Message Format Details
Command
Reply
Event
OxOO
Description
Direction
Arguments
EnterProtocolMode
from Host
DNTCFG (ASCII characters)
Ox10
EnterProtocolModeReply
from Radio
none
Ox01
ExitProtocolMode
from Host
none
Ox11
ExitProtocolModeReply
from Radio
none
Ox02
Software Reset
from Host
BootSelect
Ox12
SoftwareResetReply
from Radio
none
Ox03
GetRegister
from Host
Reg, Bank, Span
Ox13
GetRegisterReply
from Radio
Reg, Bank, Span.Val
Ox04
SetReaister
from Host
Rea, Bank, Span, Val
Ox14
SetReaisterReply
from Radio
none
Ox05
TxData
from Host
Addr, Data
Ox15
TxDataReplv
from Radio
TxStatus, Addr, RSSI
Ox06
Discover
from Host
MacAddr
Ox16
DiscoverRely
from Radio
Status, MacAddr, Addr
Ox26
RxData
from Radio
Addr, RSSI , Data
Ox27
Announce
from Radio
AnnStatus, additional fields
Ox28
RxEvent
from Radio
Addr, RSSI , Rea, Bank, Span.Val
OxOA
GetRemoteReaister
from Host
Addr, Rea, Bank, Span
from Radio
If command successful :
TxStatus, Addr, RSSI,
Reg, Bank, Span, Val
If command failed:
TxStatus, Addr
Ox1A
GetRemoteRegisterReply
OxOB
SetRemoteRegister
from Host
Addr, Reg, Bank, Span, Val
Ox1B
SetRemoteRegisterReply
from Radio
TxStatus, Addr, RSSI
Ox2C
OxOC
OxOD
Join Request
from Radio
MacAddr, Addr, DeviceMode,
SleepMode
Join Reply
from Host
MacAddr, PermitStatus
RemoteLeave
from Host
MacAddr, BackOffTime
Table 4.1.2.1
Arguments:
Reg= Register location (1 byte)
Bank= Register bank, which provides logical isolation from other data regions (1 byte)
Span= Number of bytes of register data to get or set; must align to a parameter boundary (1 byte)
Val= Value to read/write to/from a register (see table 4.1.2.1 for size and acceptable range).
Data= User data (must fit within the slot size allocation)
MacAddr = MAC address of sender, for a reply or an event, or the recipient for a command (3 bytes)
Addr = Same as MAC address (3 bytes). When specifying a destination address in a tree-routing system,
a system address is used according to the following format (little-Endian byte order) :
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
44 of 100
Page 41 of 97
DNT2400 - 04/13/11
www.murata.com
for routers - OxOO OxNN OxFF, where NN is the NwklD of the router.
for remotes - OxMM OxNN OxFF, where NN is the NwklD of the parent router and MM is the
network address of the remote.
TxStatus = Result of last TxData operation (1 byte)
OxOO
Ox01
Ox02
Ox03
Acknowledgement received
No acknowledgement received
Not linked (remote)
No ACK due to recipient holding for flow control
RSSI = 2's complement value in dBm , with a range of -128 (Ox80) to +125 (Ox7D) dBm (1 byte);
large positive RSSI values will not occur under ordinary circumstances. RSSI values 126 (Ox7E)
and 127 (Ox7F) have special meaning :
Ox7F = No RSSI measured because no ACK was received
Ox7E = No RSSI because packet was routed
NwklD = Network identifier of network joined (1 byte)
BaseMacAddr = MAC address of base that the remote joined (3 bytes).
AnnStatus = Status announcement (1 byte). Additional fields are also reported
depending on the status code:
Status code
OxAO
OxA2
OxA3
OxA4
OxA5
OxA7
OxA8
Additional fields
Radio has completed startup initialization
Base: a child has joined the network
Remote: joined a network, ready for data
Remote: exited network (base is out of range)
Remote: the base has rebooted
Base: remote has left the network.
Base: heartbeat received from router or remote
OxA9 = Base : router heartbeat timeout
none
MacAddr, Reserved, Range
NwklD, BaseMacAddr, Range
NwklD
none
MacAddr
MacAddr, NwkAddr, NwklD,
ParentNwklD, BeaconRSSI,
AvgTxAttmpts, ParentRSSI, Range
NwklD
New status code field definitions :
ParentNwklD = Network ID of parent (1 byte)
BeaconRSSI
= Average power of received beacons (1 byte)
ParentRSSI
= Average power of received heartbeat as reported by parent (1 byte)
AvgTxAttempts = Average number of upstream transmit attempts per packet times 4 (1 byte)
Status codes for error conditions
EO = Protocol error - invalid message type
E1 = Protocol error - invalid argument
E2 = Protocol error - general error
E3 = Protocol error - parser timeout
E4 = Protocol error - register is read-only
EB = UART receive buffer overflow
E9 = UART receive overrun
EA = UART framing error
EE= Hardware error
Additional fields
none
none
none
none
none
none
none
none
none
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
45 of 100
Page 42 of 97
DNT2400 - 04/13/11
www.murata.com
Range = Range measurement of joining radio (1 byte). Each count equals 0.29 miles.
BootSelect = Code indicating whether to do a normal reset or a reset to the bootloader (1 byte)
(0 = normal reset, 1 = reset to bootloader)
PermitStatus = Permission for new node to join , OxOO = denied, Ox01 = permitted (1 byte)
BackoffTime
= Time that a node will avoid trying to join a network, in seconds (2 bytes)
(OxFFFF = back off until reset or power cycled)
4.1.3 /CFG Select Pin
A falling edge on the /CFG pin is the equivalent of the EnterProtocolMode command. A rising edge on the
/CFG pin is the equivalent to sending the ExitProtocolMode command. The input to the /CFG pin is debounced to make it compatible with a mechanical switch or jumper.
4.1.4 Flow Control
There are two flow control signals between the radio and the host, /HOST_RTS and /HOST_CTS. See
Section 2.11 for flow control details.
4.1.5 Protocol Mode Data Message Example
In this example, ASCII text Hello World is sent from the base to a remote using a TxData command. The
MAC address of the remote is Ox000102. The protocol formatting for the host message is:
OxFB OxOF Ox05 Ox02 Ox01 OxOO Ox48 Ox65 Ox6C Ox6C Ox6F Ox20 Ox57 Ox6F Ox72 Ox6C Ox64
There are 15 bytes following the length byte, so the length byte is set to OxOF. Note that the Ox000102
MAC address is entered in Little-Endian byte order Ox02 Ox01 OxOO.
When an ACK to this message is received from the remote, the base outputs a TxDataReply message to
its host:
OxFB Ox06 Ox15 OxOO Ox02 Ox01 OxOO OxC4
The OxOO TxStatus byte value indicates the ACK reception from the remote. The RSSI value of the received ACK is OxC4 (-60 dBm).
If the remote is in protocol mode, the message is output in the following format:
OxFB Ox10 Ox26 OxOO OxOO OxOO OxC4 Ox48 Ox65 Ox6C Ox6C Ox6F Ox20 Ox57 Ox6F Ox72 Ox6C Ox64
The message is output as an Ox26 event. The address field contains the base (originator) address. Note
that the RSSI value OxC4 is inserted between the base MAC address and the Hello World user data.
4.1.6 Protocol Mode Tree-Routing MAC Address Discovery Example
In this example, a Discover command is broadcast in a tree-routing system to obtain the system address
of a remote with the MAC address Ox000102.
The protocol formatting for the host message is:
OxFB Ox04 Ox06 Ox02 Ox01 OxOO
There are 4 bytes following the length byte, so the length byte is set to Ox04. Note that the Ox000102
MAC address is entered in Little-Endian byte order Ox02 Ox01 OxOO.
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
46 of 100
Page 43 of 97
DNT2400 - 04/13/11
www.murata.com
The target remote will issue a DiscoverReply command as follows :
OxFB Ox08 Ox16 OxOO Ox02 Ox01 OxOO Ox01 Ox01 OxFF
The OxOO Status byte value indicates a response from the remote. The tree-routing system address of the
target remote is received in Little-Endian byte order, so the address is OxFF0101 . Referring to Figure
2.12.1.2, this is the system address of Remote R1.
4.2 Configuration Registers
The configuration registers supported by the DNT2400 are described below. Registers are sorted into
banks according to similar functions. Default register values are in bold. All changes to parameters are
temporary and will not persist through power cycling until Ox01 has been written to the MermorySave
parameter in Bank FF. Writing OxOO to the MemorySave parameter will reload the factory default values
which also require writing Ox01 to the MemorySave location. Also note that some parameter changes do
not take effect until they are saved and the module is reset or power cycled. Modules can be reset by
writing OxOO to the UcReset parameter in Bank FF.
4.2.1 Bank O- Transceiver Setup
Bank
Loc'n
Name
R/W
00
00
00
01
Device Mode
RF_DataRate
R/W
R!W
00
00
00
00
00
00
00
00
00
00
00
00
00
OxOO
OxOO
OxOO
OxOO
OxOO
OxOO
02
04
05
15
16
17
18
19
1A
18
1C
2C
2E
Ox34
Ox35
Ox36
Ox37
Ox39
Ox3A
HopDuration
lnitialParent NwklD
SecurityKey
SleepMode
WakeResponseTime
WakeLinkTimeout
TxPower
ExtSyncEnable
DiversityMode
Reserved
UserTag
RegDenialDelay
RmtT ransDestAddr
TreeRoutingEn
BaseModeNetlD
StaticNetAddr
Heartbeatlntrvl
TreeRoutingSyslD
EnableRtAcks
R/W
R!W
R/W
R/W
R!W
R/W
R/W
R!W
Size in
bytes Range
Default, Options
=Remote, 1 = Base, 2 = PTT Remote, 3 = Router
=500, 1 = 200, 2 = 115.2, 3 = 38.4 kb/s,
0 ..3
0 .. 4
4 ..4000
0 .. 255
0 ..2128
0 .. 1
0 .. 255
0 ..255
0 ..2
0 .. 1
0 ..2
10 ms (OxOOCS)
OxFF join any network
all null bytes (OxOO) security disabled
0 off, 1 = timer, 2 = interrupt
1 50 ms, 0 to disable
5s
0 1 mW; 1 = 10 mW, 2 = 63 mW
0 off; 1 = enable
0 0 V, 1 = 3.3 V, 2 = toggle
OXFF
R/W
R!W
R/W
R/W
R!W
R/W
R/W
R!W
R/W
R/W
16
16
= auto
"DNT2400"
10 s
OxOOOOOO (Base)
0 .. 1
OxOO off, 1 = enable
1..63
OxFF (must change on routers)
1.. 126, 255 OxFF dynamic assignment
Ox14 (20 seconds)
1.. 65535
0 ..255
OxOO
0 .. 1
OxOO (suppress remote peer-to-peer ACKs)
Note: These settings are individual to each module.
DeviceMode- selects the operating mode for the radio: remote, base, PTT remote (listen mostly remote)
or tree-routing router. Note that changing this setting does not take effect immediately. It must be followed
by a MemorySave command (See Section 4.2.9) and then a hardware reset.
RF_DataRate - this sets the over-the-air data rate. DNT2400's with different RF data rates cannot intercommunicate. The following codes are defined :
OxOO = 500 kb/s (default)
Ox01 = 200 kb/s
Ox02 = 115.2 kb/s
Ox03 = 38.4 kb/s
Oxff = auto
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
E-mail: tech sup@rfm.com
©2009-2011 by RF Monolithics, Inc.
DNT2400 10/25/16
47 of 100
Page 44 of 97
DNT2400 - 04/13/11
www.murata.com
The auto setting will cause a remote to try all four over-the-air rates when scanning for a network to join.
Setting the RF_DataRate to a fixed value on the remotes will allow a network to link much faster than
using the auto setting. However, if the base RF_DataRate is changed when the remotes are set to a fixed
rate, the network will not link. Note that changing this setting does not take effect immediately. It must be
followed by a MemorySave command (See Section 4.2.9) and then a hardware reset.
HopDuration - this sets the duration of the hop frame. The duration is set as a 12-bit value,
0.05 ms/count. Changing the hop duration must be followed by a MemorySave command to allow the
change to persist through a reset or power cycle. A HopDuration change takes effect immediately. Remotes will re-link following a HopDuration parameter change.
lnitia/ParentNwk/D - this parameter selects the network ID that a base will use to start a network, or a
remote will be allowed to join. A value of OxFF instructs a remote to operate in 'promiscuous mode' and
join any network it finds (if set for a base, this will select the default network ID of OxOO.)
In a tree-routing system, this parameter controls which parent a child router or remote can join. Setting
this value to OxOO forces a router or a remote to join with only the base. Setting this parameter to the
Nwk/D of a parent router forces a child router or a remote to join only this parent's network. Setting this
parameter to OxFF in a router or remote allows them to join with any parent. In a tree-routing system, the
lnitia/ParentNwk/D parameter also determines the hopping pattern for the parent and children of each
network. When a network ID equals or exceeds the number of unique hopping patterns, the hopping
pattern selection will "wrap around" to the network ID modulo of the number of hopping patterns. To
prevent interference between networks in a tree-routing system, networks with the same hopping pattern
must be physically separated by enough distance that they cannot receive transmissions from each other.
It is often convenient to set the lnitia/ParentNwk/D parameter value on remotes to OxFF to allow them to
connect to any parent device. However, setting the lnitia/ParentNwk/D parameter value to OxFF on a
system with a large number of routers can be problematical. This could result in very long routing paths,
slowing communications, and possibly causing reply delays to exceed the P2PReplyTimeout parameter
setting. For this reason, it is often best to design a tree-routing system using a large number of routers so
that each router has an explicit lnitia/ParentNwk/D.
SecurityKey- this sets the 128-bit AES encryption key to be used. To protect the key, this is a write-only
parameter for the user (always reads back as Ox2A) . Refer to the Section 2.16 for further information.
SleepMode - this parameter enables sleep mode, which may be used in conjunction with the automatic
1/0 reporting feature to wake up on specified triggers. Sleep mode is only available for remotes, and the
channel access mode for the network must be one of the CSMA modes.
WakeResponseTime - this parameter sets the length of time that a remote in sleep mode will wait for a
response after sending an 1/0 report before going back to sleep, from a minimum of 1O ms to a maximum
of 2.5 seconds in 1O ms units. This time interval is set to allow the base host application to respond to a
remote with a packet before the remote returns to sleep. If this parameter is set to 0, the remote will stay
awake indefinitely after sending an 1/0 report. This allows the application as much time as needs for any
initial configuration after which it can cause the remote to re-enter sleep by setting this to the operating
value. The default value for this parameter is 50 ms.
WakeUnkTimeout - this parameter sets the maximum length of time that a remote in sleep mode will
spend trying to acquire a link to its base before going back to sleep, from a minimum of 100 ms to 25.5 s
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
48 of 100
Page 45 of 97
DNT2400 - 04/13/11
www.murata.com
in 100 ms units. If this value is set to 0, the remote will stay awake and continue trying to link to its base
indefinitely.
TxPower- this parameter sets the transmit power level used by the base (fixed) , and the maximum transmit power level used by a remote. A remote may automatically adjust its power below the TxPower settings based on the signal strength it receives from the base plus the TxPower setting being used by the
base. The default 1 mW TxPower setting is useful for desktop testing. TxPower is usually set to a higher
level to increase operating range in actual applications. Setting bit 4 (0001 xxxx) disables the remote
automatic transmit power function .
OxOO = 0 dBm or 1 mW (default)
Ox01 = 10 dBm or 10 mW
Ox02 = 18 dBm or 63 mW
ExtSyncEnable - this parameter enables or disables the hardware EX_SYNC function on Pin 15. When
enabled, a pulse train can be input on Pin 15 to synchronize the transmission of co-located bases. Disabled by default.
DiversityMode - the following diversity antenna switching options are supported as an output on GPI05:
0 = 0 V output (default)
1 = 3.3 V output
2 = hop-by-hop toggle between O and 3.3 V
UserTag - this is a user definable field intended for use as a location description or other identifying tag
such as a "friendly name".
RegDenia/Delay - when a remote has been removed from a network through a RemoteLeave, the RegDenia/Delay parameter sets the length of time the remote will wait before considering that network a
candidate for joining again. Units are in seconds ; the default is 10 s.
RmtTransDestAddr - this parameter sets the destination address that a remote will send packets to when
configured to use transparent mode. The default destination is the base (OxOOOOOO) . If this field is set to
another remote's MAC address or to the broadcast address, a peer-to-peer packet will be sent. Note that
peer-to-peer packets have higher latency than direct packets between base and remote. This setting has
no effect on the base.
TreeRoutingEn - this parameter enables tree-routing system operation . Tree-routing operation is disabled
by default.
BaseModeNetlD - this parameter holds the base-mode network ID used by a router. This parameter must
be set to a unique value while the node is in remote mode. The node can then be configured as a router.
The base-mode network ID of O is reserved for the system base. To keep the base routing table transmissions short, low BaseModeNet/D values should be used when possible. The base routing table transmissions leave off all unused entries corresponding to higher BaseModeNet/Ds . For instance, if the
largest BaseModeNet/D being used is 63, the payload in the routing table packet will be 64 bytes long. In
contrast, if the largest BaseModeNet/D being used is five, then the payload in the routing table packet will
be only 6 bytes long.
StaticNetAddr - this parameter holds the lower byte of the system address of a remote. Assigning a value
other than OxFF provides a fixed (static) address. When this parameter is set to OxFF, the router assigns
www.RFM.com
Technical support+ 1.678.684.2000
Copyright © Murata Manufacturing Co., Ltd. All Rights Reserved. 2011
©2009-2011 by RF Monolithics, Inc.
E-mail: tech sup@rfm.com
DNT2400 10/25/16
49 of 100
Page 46 of 97
DNT2400 - 04/13/11
www.murata.com

---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.6
Linearized                      : Yes
Author                          : Kirby.Munroe
Create Date                     : 2016:10:26 13:56:24-04:00
Modify Date                     : 2016:10:26 13:56:24-04:00
Has XFA                         : No
XMP Toolkit                     : Adobe XMP Core 5.4-c005 78.147326, 2012/08/23-13:03:03
Metadata Date                   : 2016:10:26 13:56:24-04:00
Creator Tool                    : Adobe Acrobat 11.0.18
Format                          : application/pdf
Title                           : Microsoft Word - 16-0346 - Exhibit Cover
Creator                         : Kirby.Munroe
Document ID                     : uuid:7e43afdb-6228-4e69-a1ce-00d1875a4c6c
Instance ID                     : uuid:435197ee-8c14-44ab-9260-8d940d0054d1
Producer                        : Adobe Acrobat 11.0.18
Page Count                      : 50

EXIF Metadata provided by EXIF.tools