Telegesis (UK) Limited
TG-ETRXn-UG-01-103
14
User Guide
1.04
ETRX1 and ETRX2
©2008 Telegesis (UK) Ltd
ETRXn User Guide (Rev 1.04)
Once the network has been established you may wish to keep this network private so other nodes
do not interfere with it. The first method is to prevent more nodes from joining (register S06, bit B),
the second is to only permit secured joining from the beginning (see section 8 for security).
Attempts to achieve privacy by setting radio channel masks or preferred PAN IDs may not be
reliable since the network‟s environment cannot be predicted. This is discussed more fully in
section 8.
4 Data Transmission
4.1 Overview
The purpose of a network is - of course - to send data between nodes. The data (formatted as
successive bytes) can be of predefined or undefined length, or may be single 16-bit words
controlling the ETRXn‟s I/O ports. It can be sent to a single node, or broadcast across the network.
ZigBee
®
has been designed for control and automation applications, therefore the maximum
payload for any message type mentioned in this section is 65 bytes, which reflects the small and
efficient messaging structures of ZigBee
®
(the exception is a packet of raw data sent by the
AT+RDATAB command, which can hold 114 bytes).
The strength of a meshed network compared to traditional point-to-point radio systems is that data
can be sent between nodes which are out of range of one another. The packets containing the
data dynamically route through the network finding the best possible path. In doing so the mesh
network can dynamically react to a changing RF environment and self-heal broken links, given that
an alternative route from the source to the destination of the data is present.
Due to the potential presence of alternative routes, packets may not arrive at their destination in
the order they have been sent and also the timing of messages may vary.
The worst case delay for data to be transmitted from one node to a direct neighbour (one hop) is
100 milliseconds. In addition, it may take as much as 100 milliseconds for an acknowledgement to
find its way back.
When sending data it is assumed that the user (or the application) doesn‟t want
to have messages in transit for more than 3.6 seconds, which leads to a limitation of the maximum
possible number of hops. In practise a node not having received an acknowledgement for 1.2
seconds will issue a retransmit and after three unsuccessful transmissions the message delivery
will be timed out and reported unsuccessful. This leads to a worst case limitation of 6 hops since
the worst case delay between each hop is 100ms, so we are looking at 600ms for the signal to
reach its destination and another 600ms for the acknowledgement to find its way back. As a result
of this when planning an application using wireless meshing networks, no more than 6 hops should
be planned for, although more than 6 hops may work given that the delay between hops is better
than the assumed worst case.
4.2 Broadcasts
“AT+BCAST:nn,<data>“ sends the string <data> to all nodes within nn hops. Broadcasts are not
acknowledged, so they are sent three times to improve the likelihood of reception. However,
reception
cannot
be
guaranteed.
Each
receiving
node
sends
the
message
“BCAST:<EUI64>=<data>” to its serial port (<EUI64> being the transmitting node).
“AT+BCASTB:xx,nn” will generate a „>‟ prompt in your terminal window, where a number of xx
characters may be typed. The character string can include <CR>, <LF> and non-displayable
bytes. Each receiving node sends the message “BCAST:<EUI64>,xx=<data>” to its serial port
(<EUI64> being the transmitting node and xx the string length).
