The ZigBee Alliance is an association of companies working together to enable reliable, cost-effective, low-power, wirelessly networked, monitoring and control products based on an open global standard.
The goal of the ZigBee Alliance is to provide the consumer with ultimate flexibility, mobility, and ease of use by building wireless intelligence and capabilities into every day devices. ZigBee technology will be embedded in a wide range of products and applications across consumer, commercial, industrial and government markets worldwide. For the first time, companies will have a standards-based wireless platform optimised for the unique needs of remote monitoring and control applications, including simplicity, reliability, low-cost and low-power. www.zigbee.org
Until the ZigBee Standard was ratified in December of 2004 there was no standard approach that addressed the unique needs of most remote monitoring and control applications. The ZigBee Standard enables the broad-based deployment of reliable wireless networks with low complexity, low cost solutions and provides the ability for a product to run for years on inexpensive primary batteries (for a typical monitoring application). It is also, of course, capable of inexpensively supporting robust mesh networking technologies.
The Telegesis ETRX2 and the ETRX3 modules utilise the Ember ZNet protocol stacks and can form a self-organizing, self-healing wireless networking platform based on the ZigBee specifications. The EmberZNet supports a variety of network topologies for wireless monitoring and control applications, including mesh, star, and cluster tree. Applications running the EmberZNet stack can be interoperable with other ZigBee nodes. Ember ZNet provides all of the standard benefits that come with ZigBee including: flexible topologies, high security, broad interoperability, low cost, long battery life, and integrated network management. In addition, Ember ZNet applications can take advantage of the industrial strength reliability and unprecedented ease of use of the Ember Transport Layer capabilities.
Until now, much of the cost of deploying sensing and control devices was in installing the network to connect them. With Ember ZNet, the value, like the network, is embedded in the devices themselves. Ember ZNet’s self-organizing, self-healing mesh algorithms produce networks that are reliable, flexible, secure, and easy to use. Adding devices only makes Ember ZNet sensing and control networks stronger and more efficient. Designed from the ground up for developers of sensing and control products, the EmberZNet product suite enables rapid development and deployment of embedded wireless networks that virtually “see around corners,” and that have no single point of failure.
The Ember ZNet Protocol Stack is a compact, scalable implementation of the ZigBee specifications which translates into lower cost MCU options for device manufacturers. The stack is available in different configurations optimized for the various ZigBee node types; PAN coordinators, full function devices, and reduced function devices. The stack is already available for several microprocessor platforms supported by Ember.
The ETRX2 and the ETRX357 are supplied with firmware that runs EmberZNet to form a meshing network. Tree, star and cluster tree are not implemented as the mesh topology is the most useful, and there are no superframes, time-synchronisation beacons or guaranteed time slots. On top of the Ember firmware we have put our AT command-like user interface, so that the user does not have learn all the details of controlling a PAN.
The ETRX2 is our second-generation product based on the Silicon Labs EM250 chip. The ETRX357 uses the newer EM357 which has better radio performance and a faster processor. The ETRX357 also has a smaller footprint and the side castellations make soldering and probing easier.
The ETRX2 is used in many mature products so it will continue in production for the foreseeable future. However, we recommend the ETRX357 for new designs.
There are a number of options. When using the Telegesis AT Style command interface the application sits on a host microcontroller which is external to the ETRX2 and ETRX3 module. Additionally the modules can be used stand-alone using the pre-defined functionality defined in the non-volatile S-Registers, which hold the configuration data of the ETRX2 and ETRX3 wireless meshing module. If you decide to develop your own firmware instead of using the Telegesis “AT style” command interface then it can run on the XAP2b processor on the ETRX2 module or the ARM Cortex processor used in the ETRX3 range.
The quickest and easiest way to begin your development is to use an ETRX357DVK development kit but if you wish, you could integrate the ETRX3 on to your own carrier boards. To connect the ETRX3 to a PC you will need to use an RS232 level converter or alternatively connect the ETRX3 straight to a host microcontroller. The ETRX2USB and ETRX3USB sticks also provides easy access to the modules serial port. Please note that ETRX2 Development kits are no longer available.
The ETRX2 and ETRX3 wireless meshing modules with the on-board antenna complies with EN, CE and FCC regulations and carries an FCC ID which allows them to be integrated into products which don’t need to be re-tested for radio compliance – subject to the following.
The ETRX2 has been tested and approved by a certified laboratory for RF Transmission, EMC and for general product safety.
Using the integrated Antenna it conforms with EN300 440, EN 300 328,EN301 489,EN60950 (Europe) and FCC CFR 47 Part 15 (USA).
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.
ETRX2 FCC ID: T7VEM250A
The ETRXn device carries FCC authorization and is marked with the FCC ID Number. Whilst any device into which this authorized module is installed will not normally be required to obtain FCC authorization, this does not preclude the possibility that some other form of authorization or testing may be required for the finished device.
When the ETRXn module is integrated inside another device/product, then the outside surface of that device/product must display a label referring to the enclosed module. This exterior label can use wording such as “Contains Transmitter Module FCC ID: T7VEM250A” or “Contains FCC ID: T7VEM250A” although any similar wording that expresses the same meaning may be used. If in doubt, please check with a certified laboratory of the FCC. See certification for details of the current certification.
See Certification for details of the current certification. The ETRX2HR-PA, the ETRX357(HR) and ETRX357(HR)-LRS with either the on-board antenna or specified external antennas also conform to EN 300 328, EN 301 489, EN 60950 (Europe) and FCC CFR 47 Part 15 (USA).
The modules have also been certified for some other countries as well. See Certification for details of the current certification and contact email@example.com for the up-to-date situation.
Telegesis General Questions
We specialise in ZigBee modules based around the Ember EM250 and EM357 chips and we make a small suite of hardware and firmware products built around these modules. These include USB sticks, a Range Finder kit, Smart Energy and Home Automation compliant AT command interfaces and (coming shortly) a ZigBee to Ethernet gateway. For current products see www.telegesis.com/products.
No, only 2.4GHz.
Programming ETRX Modules
The ETRX2 does not support JTAG.
Not with the default AT command firmware. The physical peripheral connections are present to utilize this with custom firmware.
On pre-programmed modules the Ember bootloader is installed which can be used to download new firmware over the air or via the serial port. This bootloader can be accessed using the Telegesis Terminal software. Note that after downloading your own firmware you may not be able to access this bootloader any longer unless you include a suitable feature in your own program.
Alternatively, you can connect an Ember InSight Adaptor to the module’s SIF port and reflash it.
Please contact us about an extension of the AT-command dictionary.
Feel free to develop your own firmware, however we can only support you on the hardware side. Please contact Ember directly for support on their software stack. The ETRXn modules are not write-protected.
Firmware for the EM250 in the ETRX2 or the EM357 must be written using an Ember developer kit – see Ember Tools
No, the Ember development tools always include the ZigBee Layer.
Using ETRX Modules
No. Wi-Fi and Bluetooth are completely different technologies that also happen to use the same radio banddote.
You don’t, you run your application on a host processor. However, the built in functions of the ETRX2 or ETRX3 families may be enough for the device to operate automatically. You can only load a new program by developing your own ZigBee application and overwriting the Telegesis firmware.
The range depends on a lot of factors such as the surroundings in which the devices are used and the product they are integrated into. With the on board antenna in an urban environment a range between 30-60 metres can be expected but free space ranges of over 200 meters have been experienced. If you require a greater range the use of a suitable external antenna can improve the performance of the module.
Yes, see ETRX2-PA and the ETRX357-LRS
Yes, providing they have the same firmware version
Definitely not, they will not mesh together. In fact, it is better not to mix firmware versions at all.
No. there is no R2xx firmware file available for the ETRX357
No, because they have different internal processors.
For nodes to form a network, they must all be using the same protocol stack profile and stack parameters. Furthermore, for communication between nodes in a network they must be running the same application profile. Ours, using our AT command set, is a private profile not a public one. Please see the notes in our documents (eg the AT Command Manual) regarding ZigBee compliance. Our devices incorporate the EmberZNet2.5 or 3.x protocol stack and a meshing network rather than a tree topology. Devices with the R3xx firmware may sometimes be able to join with another manufacturer’s devices, particularly if the device is configured as a ZigBee end Device, but the other nodes must have encryption enabled.The R3xx firmware can be configured to communicate with other profiles, see our Application Note for Interoperability for more details.
The drivers are all supplied by the manufacturers of the CF and USB bridge chips. Try the following:
Silicon Labs for the USB stick.
Suitable drivers may already be incorporated in your Linux kernel.
USB devices usually have to be handled at the application level in Android. There is an open source Java project (issued under the GNU Lesser GPL licence) for USB-serial for Android which supports the CP2102 chip at:
You can directly download the jar file and use it as application:
Also you must use our product ID for CP2102 devices which is 33427 (0x8293) in the device_filter.xml file in the project for the driver to work with Telegesis devices. You can download the source and use the example project in the above link to get started.
Unicasts will travel up to 6 hops and broadcasts can travel 10 hops (with R2xx firmware) or both can travel 30hops with R3xx firmware. These cannot be increased without compromising the performance, and the user cannot alter these limits.
The unit needs to be in power mode 0 i.e. fully awake in order to interact with the network. If you need to save power you should use the leaf node approach (a Sleepy End Device). A leaf node has no routing responsibilities and therefore can be put to sleep at any time. When woken up a leaf node can transmit its data to the coordinator either in predefined intervals or event triggered.
With R2xx firmware each router can have 8 Sleepy End Devices and 8 Mobile End Devices as children. With R3xx it varies between firmware versions, but an R308 router can support 30 End Devices regardless of their type.
The over the air data rate is 250kbps but the serial link speed is recommended not to exceed 19200bps. What is the maximum throughput of the ETRXn module?
250kb/s is the raw bit rate within a radio packet and is not a guide to data throughput. The ETRXn has been designed to allow stable wireless meshing connectivity for remote control, metering and automation purposes. Due to its nature it isn’t suitable for time-critical control or high-speed data like audio/video or file transfer (unless you have a lot of time). If you intend to do any of this you should look for a different technology. See our application note on achievable data rates.
- Make sure power is plugged in and the module is correctly connected to the socket (if using the Development kit).
- Make sure your computer is communicating via the correct COM port.
- If the register that sets up the UART has been modified, the data rate, parity or number of bits of the serial link will have changed. When this is the case you quite often will receive garbage or nothing at all. Try adjusting the Terminal program to match the settings of the ETRXn module, or correct the register over-the-air.
- The module may have been powered down by putting it into a low-power mode. Try causing an external interrupt as described in the Development Kit manual or simply reset the module.
- The module may have been set to have a pre-defined functionality which may cause the module to go to sleep even after a reset. Refer to the descriptions of the built-in functionality and the Application Note on how to wake the unit up permanently.
- If the device has been powered up with pad 10 (for the ETRX2 – A/D2) or pad 28 (for the ETRX357 – PB7 or ADC2) held low, it will be running its bootloader.
- Reset it, or see the Development Kit Technical Manual for details of the bootloader.
You are connected to your dial up modem instead. Check the list of COM ports in the Windows device manager.
Telegesis can supply a limited selection of antennas – see Telegesis Web Shop There are a number of companies worldwide that do specialise in this area. We can recommend Embedded Antenna Design, Milton Keynes, UK who stock a wide selection of antennas as well as offering a bespoke antenna design capability. www.ead-ltd.com
ZigBee Smart Energy
A ZigBee Smart Energy device must have special security keys (purchased from Certicom) that enable it to carry out data transfer between other devices on the network. This feature gives the necessary security for financial transactions and control of electrical appliances from outside the premises. This validation process is called key establishment.
There are 2 types of keys: test certificates and production certificates, both obtainable from Certicom or in limited quantities from Telegesis. You develop your ZigBee SE device using test certificates, then submit it to be tested and certified as an approved SE-compliant device. You can then start using production certificates.
No, because HA devices do not perform the Key establishment procedure.
No, it does not perform the required Key establishment procedure.
It is not possible to supply general purpose firmware for SE devices because of the large number of different Smart Energy devices which each support a different set of messages. Furthermore, the SE specification defines the content of the radio messages but does not define what effect they have on the receiving device. This makes it necessary for custom firmware to be written to interface the ETRX2 or the ETRX3 with the SE equipment
We have written demonstration firmware for an ETRX3USB stick that defines it as an In-Premise Display and allows it to receive readings from an SE meter device. This uses a version of our AT command set which enables you to implement a display on a PC using only your application program. We can provide custom SE firmware as well. Please contact us with your detailed requirements.
Yes, within limits. You can configure it to send HA commands but you have to consult the ZigBee Cluster Library specification and assemble a binary message payload. Incoming messages are passed to the serial port to be interpreted by a host processor. See our Application Note for Interoperability.
Yes, we have two firmware versions that implement a Combined Interface Device or a 5-in-1 device. These are currently offered as an evaluation kit containing a USB stick and one of our ETRX357 development kit boards.