1

Senior Design IECE 4901Fall 2012

Variable Frequency Drive WirelessInterface Prototype

Final Report

Team 168 Members:Michael Kloter (EE)

Christopher Perugini (EE)Alexander Shuster (EE)

Kevin Wei (EngPhys-EE)

AdvisorJohn Chandy

John.Chandy@uconn.edu

SponsorLenze

Christopher Johnson

2

Christopher.Johnson@lenzeamericas.com TABLE OF CONTENTS

1) TABLE OF CONTENTS …......................................................................................................... 2

2 )INTRODUCTION …................................................................................................................ 3

3 )BACKGROUND ….................................................................................................................. 2

4) SPECIFICATIONS …............................................................................................................... 5

5) APPROACH …...................................................................................................................... 6

6) DESIGN METHODOLOGY …................................................................................................... 7

7) PROCEDURE ….................................................................................................................... 12 8) SUGGESTIONS …................................................................................................................. 16 9) FUTURE WORK …................................................................................................................ 17

10) TIMELINE …....................................................................................................................... 18

10) BUDGET …......................................................................................................................... 19

11) REFERENCES …................................................................................................................... 20

Introduction:

3

Lenze corporation is the sponsor for this project. Lenze specializes in AC electric motor drive and machine automation technology. They produce variable frequency drives (known henceforth in this document as VFD or VFD’s), for various motor power levels used in many different applications throughout the United States and the world. The VFD hardware is continuously being revised and improved upon because of this and its ability to be customized is attributed to its popularity. To further the feature set and increase device usability Lenze has proposed integrating a wireless communication feature in the current and next generation VFDs through this project. The scope of the project is as follows:

● Research wireless communication hardware employed in industrial environments● Suggest and prototype said wireless interface on current Lenze VFD hardware● Demonstrate the ability to establish bidirectional wireless communication with the VFDs● Demonstrate the ability to wirelessly commision Lenze VFD drives

Background:Variable Frequency Drive (VFD)

A variable frequency drive or VFD is an AC powered device that acts as an open loop speed and direction control system for an AC motor, rotary or linear of any power rating. It can also act as a closed loop speed, direction and position controller for a DC stepper motor of any power rating. Lenze’s VFD products are mostly for mid to high power AC rotary motors however they do have products for linear and DC stepping motors. Lenze’s Customers

Lenze sells variable frequency drives to many types of customers. Most of these customers are in the industrial sector. For example, automotive construction, pharmaceutical manufacturing, robotics, and food and beverage packaging, are among their customer base. In order for the industrial sector to adopt new technology, the benefits must greatly outweigh the cost. Wireless technology has been in the consumer market for a long time, but has only recently started integrating into the industrial environment. Current VFD Interface

Each VFD controls exactly one device, each device will have its own requirements for speed and direction as a function of time, which must be controlled by the VFD in a safe manner. To obtain the desired functionality each VFD must be programmed to meet the required specifications, this programming can currently be accomplished by any of four current methods. 1) Direct programming.

The VFD has a six key keypad and segmented LED readout that a human user can use to locally program the device. This method is not desirable as programming with this limited keypad can be tedious and time consuming. Also in circumstances where the VFD is not physically accessible due to environmental or space constraints it can make programming

4

impossible.

2) Remote programming:A remote six key keypad with segmented LED readout is available for the Lenze VFD’s

that functions the same as the direct programming method, however the keypad is now divorced from the VFD eliminating the requirement to interface with the device directly. However this remote option does not decrease the complexity and time consuming nature of the direct programming option. 3) Programming over ethernet

A IP based ethernet module is available for a number of Lenze VFD models that allows the VFD to be programed anywhere with access to the IP network that the VFDs are connected to. The actual programming method can be via PC, Mac, smartphone or any other computer based device running software written to communicate with the IP ethernet module. Also programing can be accomplished through any web browser via ethernet modules onboard web server 4) Programming over RS-485

A RS-485 based module is available for a number of Lenze VFD models that allows the VFD to be programed anywhere with access to the RS-485 network that the VFDs are connected to. The actual programming method can be via PC, Mac, smartphone or any other computer based device running software written to communicate with the RS-485 ethernet module via the modbus protocol. This project will be using the current infrastructure of the RS-485 programming method however it will intercept the modbus packets distributed over sent by the programming device over RS-485, convert them into a form suitable for transmitting wirelessly to be converted back to modbus packets and re transmitted to the receiving VFD. ZigBee

ZigBee is a wireless communications protocol outlined by the IEEE 802.15.4 standard for personal area networks. It is intended for low power consumption, low to medium data rate and low cost implementation. A comparison with other common wireless technologies is given in Table 1. In addition, the ZigBee protocol operates in a frequency band show to be immune to common electromagnetic interference associated with the industrial environment (ZigBee). For this reason and those listed in Table 1, ZigBee will be the means of wireless communication in future Lenze VFD designs.

Wi-Fi Bluetooth Zigbee

Range 50-100 meters 10-100 meters 10-100 meters

5

Avaliable Network Topologies

Star, Ad-hoc Ad-hoc Star, Ad-hoc, peer to peer, mesh

Operating Frequency (excluding bands)

2.4 Types B,G GHz 5 GHz Type N

2.4 GHz 2.4 GHz Global, 868 Mhz Europe

Device and Firmware Complexity

High High Low

Security 128 AES hardware accelerated MAC, and application layer

64 and 128 bit encryption

64 and 128 bit encryption

Targeted Applications Broadband internet and wireless LAN access

Portable data device interconnectivity

Personal area device interconnectivity, low power devices

Table 1. Wireless technology comparison

Specifications:In order to satisfy Lenze’s design requirements, the following must be achieved; The

device needs to be integrated into the existing VFD communication module and offered as a stand-alone module that can be tied to an existing RS-485 communication network. The device also needs to properly communicate within an industrial environment as well as withstand the environment’s physical stresses such as shock, vibration, industrial temperature ranges and possible environmental contaminants. Software / Communication

● RS-485 – needs to communicate with the existing RS-485 Modbus protocol.● Multiple VFDs – the ability to communicate with multiple VFDs from one programming.

terminal, simulcast transmissions not required.● Range – short range to first node.● Monitoring – ability to monitor VFDs.

Hardware

● Size – needs to fit on or inside the existing VFD casing or small add on module.● Temperature – must be able to withstand the heat of the VFD.● Vibration – must be able to withstand the vibration of the environment.● EMI -electromagnetic interference, the device must communicate in an electrically noisy

environment.

Approach:The approach to satisfy Lenze’s proposal is outlined in Figure 1 below. There are two

components of the design. First a ZigBee transceiver will be attached to a PC via an existing

6

RS-485 network, this ZigBee device will act as the networks coordinator and will bring up the network. Secondly a ZigBee transceiver will be attached to the VFD and communicate over an existing RS-485 network or it will be integrated directly with the current RS-485 module. This device will be an end device of the network and, as shown in Figure 1, will not be singular to the network. Furthermore, Figure 2 shows a flowchart of the approach taken to implement this system.

Figure 1. Wireless technology comparison

Figure 2. Flow chart of approach milestones.

Design Methodology:Hardware Choices:

7

ZigBee - ZigBee was chosen as the wireless technology because it satisfies all of the proposal specifications and is inexpensive. The low cost and low bill of material count is an important factor in what will make this design a successful product. Computer - A PC was chosen as the monitoring device for several reasons: PCs were accessible at no additional development cost and will simplify development, the existing TechLink software is compatible with PCs specifically. Lastly most customers own PCs, and the ZigBee transceiver acting as the coordinator is easily connected to a USB to RS-485 dongle. TechLink - The existing TechLink software that Lenze provides was chosen as it is currently supported and can communicate with the VFDs within the scope of this project. Unfortunately, the TechLink software is not normally used for regular communication with the VFDs and is not set up in a convenient manner to do so. It is being used because the programming required to create another, more user friendly software, exceeds the scope of this project. However, TechLink does already have the ability to interact with multiple VFDs over a RS-485 network using the modbus protocol. ZigBee model and manufacturer hardware choices

The hardware selected for this project is the Atmel ATMega128RFA1 referred to henceforth as the Atmel MCU or Atmel Transceiver, as it is a monolithic device containing both component blocks. The manufacturer Atmel was chosen largely because all development tools including but not limited to the integrated development environment, multiple versions and complexity options for the Zigbee software stacks, are free for use and distribution (EULA limited), and readily available through Atmel for education/hobbyist or commercial purposes. There is also an abundance of local personnel support for Atmel C++ programming at a variety of complexity levels to assist our team with any coding problems that may be encountered. Lastly, Lenze corporation currently employs Atmel microcontrollers in some products so any learning curve associated with a microcontroller that has not been implemented in house is eliminated.

The ATMega128RFA1 was chosen specifically from Atmel’s product line as Lenze corporation’s end goals aim for a solution that is not only very inexpensive but also low complexity, low bill of material count, and mechanically compact. The Atmel MCU addresses all of these requirements, as it is a monolithic microcontroller and Zigbee transceiver in one quad flatpack no lead package (QFN), thereby reducing component count and component footprint simultaneously. The Atmel MCU also incorporates a bill of materials count of only fifteen components, including hardware reset switch and circuitry using an on PCB bi-directional antenna. This product is also not scheduled for end of life, is available in large quantities, and is very inexpensive in quantity ($5.40 per unit at quantity 4000 from distribution) An added feature for using the Atmel MCU/Transceiver combination is that if needed, the MCU and transceiver can be purchased separately to create a divorced solution.

8

There are many other options available for Zigbee transceivers, the competitors to the Atmel Transceiver are shown in Table 2. Any of the solutions listed in Table 2 could be used as an alternative to the Atmel Transceiver/MCU hardware however they would incur either a higher total cost, higher development cost, higher toolchain cost, loss of local C++ coding support, or create footprint real estate issues due to a divorced transceiver/MCU combination.

Manufacturer Transceiver MCU Development tool chain Cost

Cost @ quantity

Total component cost

Atmel Yes Yes Free $5.40@4k $5.40@4k

Texsas Instruments

Yes Yes $514 per seat $10.04@5k $10.4@5k

Microchip Yes No Free $2.73@1.6k $5.73@1.6k

Freescale* Yes* Yes* $395-$995 depending on license

$5.50@2k $5.50@2k

*Package is BGA (not desirable for Lenze PC board production as reflow ovens are available however no X ray quality control equipment was noted to be in house)**All costs at quantity taken from Digikey as of 11/5/12. Cost can be reduced via wholesaleTable 2: Zigbee Transceiver Solutions at quantity through distribution (Assumed $3.00 cost at quantity for MCU if not included) Table 2 shows that by taking into account the raw component cost at Lenze production, the consumption quantities, and the development toolchain cost, Atmel is the best financial choice. To obtain the cheapest prototyping option for the Atmel MCU a Sparkfun ATMEGA128RFA1 prototyping board was chosen. This provides all of the necessary hardware for this project while maintaining a low bill of materials count and low cost. RS-485 hardware choices

Lastly the Atmel MCU must communicate with both the PC and the VFD via a physical RS-485 network however the input and output being used in this implementation is UART so a Sipex SP3481 UART to RS-485 level shifter was selected that will allow correct hardware communication. This device was selected because it was already available in a breakout board and is available through distribution in low cost and high quantity. This device also has form fit and function replacements from other manufacturers making it interchangeable. A more detailed block diagram listing all of the aforementioned components is shown below in figure 3.

9

Figure 3. Solution Diagram Software selection and design choices

To communicate with the ZigBee hardware onboard the Atmel MCU and transceiver device, firmware must be written and uploaded to the device that is capable of packet transmission, error checking, signal level checking, channel hopping, acknowledgment transmission, device addressing, message routing, encryption and any other task associated with IEEE 802.15.4 wireless personal area network communication. To assist the end user in this task Atmel has provided three different wireless firmware stacks written in the C language providing various function calls allowing the programer abstracted access to the transceiver hardware. Each different provided software stack has varying levels of complexity and capability that enable the programmer to accomplish the aforementioned tasks with as much hardware abstraction as possible while still maintaining all control needed for flexible application development. The three different wireless firmware stacks are discussed below. Bitcloud: This is the most complex implementation utilizing all features of the transceiver and conforming completely to IEEE 802.15.4. The below is a description of the software:

“Atmel BitCloud is a full-featured ZigBee PRO stack supporting reliable, scalable, secure wireless applications running on Atmel wireless platforms. The design software is completely standard compliant with the ZigBee PRO certified platform. The platform features flexible, easy to use developer tools, including optional C API and serial AT commands. The software supports large mesh networks of hundreds of devices, and is optimized for ultra low power consumption with 5 to 15 years battery life (application dependent).”(Source: http://www.atmel.com/tools/BITCLOUD-ZIGBEEPRO.aspx)

This implementation was determined to be overly complex for the required task thus it will not be used. MAC Stack: This implementation is second in its level of complexity, it utilizes most of the features of the transceiver and conforms completely to IEEE 802.15.4. The below is a description of the software:

10

“IEEE 802.15.4 MAC stack software for different target platforms (microcontroller and board) and RF transceivers. The configurable software allows easy portability across various platforms and transceivers and improves resource usage.”(Source: http://www.atmel.com/tools/IEEE802_15_4MAC.aspx)

This implementation was determined to be overly complex for the required task thus it will not be used. Lightweight Mesh: This implementation is third in its level of complexity, it utilizes the least amount of features of the transceiver compared to the two aforementioned options however it still provides a robust suite of features that will be more than adequate for the scope of this project. The below is a description of the software:

“Atme®l Lightweight Mesh software stack is an easy to use proprietary low power wireless mesh network protocol. It has been designed to address the needs of a wide range of wireless connectivity applications, including: ● Remote control● Alarms and security● Automatic Meter Reading (AMR)● Home and commercial building automation● Toys and educational equipmentThe Lightweight Mesh software stack is designed to work with all Atmel IEEE® 802.15.4 transceivers and SoCs. Currently the stack works with AVR®-based MCUs, but given its extreme portability and low resource requirements, it can be run on almost any Atmel MCU.”(Source: http://www.atmel.com/tools/LIGHTWEIGHT_MESH.aspx)

As per its name this implementations strength is mesh topology networking which is described in greater detail in the following section. Network topology choice

In the scope of this project, the ZigBee network will consist of two types of devices running on the ZigBee side of the network, the coordinator that is attached to the PC and up to 254 VFDs connected as the end devices. Because of this two network topologies were considered, star and mesh.Star - In the star topology the coordinator acts as a central node. All of the end devices talk directly with the coordinator. Figure 4 provides a diagram of a small star topology. This topology has a greater simplicity than a mesh topology as each end device (shown here as VFD) only communicates with the coordinator, hence it only requires the coordinators address. This simplifies the firmware design however as shown below the maximum transmission distance is from coordinator to VFD end device.

11

Figure 4. Star Topology Mesh - In the mesh network, shown in figure 5, each node (shown here as VFD) acts as a relay. This provides alternate paths to each node if one node is lost. The device transmission range is now the length of the furthest node from the coordinator. Not all of the functionality of a mesh network can be utilized with two VFDs. This increased transmission range comes at a cost of firmware coding as now each node must maintain an active routing table to route the communications to their intended end address. This table must be dynamic to ensure the routing paths are always accurate.

Figure 5. Mesh Topology

12

Procedure:Atmel Software and Hardware

First all required software for programming firmware for the Atmel MCU is installed, for this purpose Atmel Studio 6.0.1843 (Latest at development insception) was chosen. Atmel studio is available free for all uses from Atmel corporation and is a full featured integrated development environment with integrated tool chain. Atmel studio ships with Atmel software framework 2.11.1, however the ATMEGA128RFA1 chip is not supported under that framework so framework 3.5.0 must be installed to successfully compile firmware.

Atmel MCU programming, the hardware selected to interface with the Atmel MCU is the Atmel AVR dragon. The AVR dragon is a multiple purpose device with PC USB connectivity capable of in system programming (ISP) used for uploading firmware from Atmel studio directly to the Atmel MCU while the MCU is in circuit. Other capabilities of this device is high voltage programming (HVP), and JTAG standard debugging. The firmware shipped with the AVR dragon is not compatible with the ATMEGA128RFA1 so the device must be updated. The update is automatic through AVR studio when the ATMEGA128RFA1 chip is selected.

Hardware connection, using hardware configuration as shown in figure 3 each Atmel MCU and transceiver is connected to a single RS-485 transceiver module to enable packet transmission from the MCU to the RS-485 network.

Figure 6. Circuit Diagram As shown in figure 6 the Atmel MCU receives USART level signals on pin 46 and transmits USART level signals on pin 50 both to and from the RS-485 transceiver. The Atmel MCU controls the RS-485 transceiver by providing a high signal on pin 47 to configure the RS-485

13

transceiver to send data and a low signal on the same pin to configure the RS-485 transceiver to receive data. This data direction control must be taken into account when converting from full duplex to half duplex. The 220 ohm resistor across the positive and negative differential signal input/output lines is to prevent ringing on higher baud rates. This enables bidirectional communication on the half duplex RS-485 network. The ZigBee transceiver hardware is contained almost entirely within the Atmel MCU and transceiver combination IC. This enables a very low bill of materials count allowing a small solution footprint and low implementation cost especially in large quantities. The only external hardware required for ZigBee communication is a crystal for clocking the transceiver asynchronously with respect to the MCU, supporting capacitors and a blaun for balanced and unbalanced signal conversion. All of the Zigbee communication components are included in the Sparkfun ATMEGA128RFA1 kit mentioned in the hardware chose section above.

Atmel FirmwareAs mentioned in the design methodology section the Atmel Lightweight mesh ZigBee

stack was chosen as the software suite to be used in this project. It provides all functionality needed for this project and has an extended feature set that includes options such as, 128 bit hardware accelerated encryption, self healing mesh networks and over the air boot loading for upgrade options. The Lightweight mesh provides a large number of functions and APIs available to the programmer that will allow fast and easy access to the ZigBee hardware.

As per its name the Lightweight mesh stack is primarily suited for mesh style networking outlined in the network topology choice section. It will provide mesh networking services such as:

● Basic data services (send and receive data)● Acknowledgements● Routing● Basic security● Power management of the radio transceiver● Network management (discovery, joining, commissioning, etc)● Advanced network operation scenarios (sleeping routers, parent-child relationship, data

delivery to the sleeping nodes, etc)● Retries to send data in case of failures● Defining message payload format● Advanced security● Power management of the MCU● Interfacing hardware peripherals (ADC, PWM, EEPROM, etc)

All programs written with the Atmel Lightweight mesh should adhere to a set of rules outlined by Atmel to maintain code consistency and prevent resource issues. This is due to the reduced memory space and resources involved with embedded system programming, as well as the time domain constrained nature of Zigbee data traffic. As such, the layers of the stack are arranged in a hierarchy where certain layers have higher priority than other layers.

14

To ensure the timeliness and efficiency at which network resources are used, the stack also employs callback functions which confirm that an asynchronous request has executed.

The Lightweight mesh stack referred henceforth in this document as the “Stack” provides

function calls to lower level hardware such as timers and USARTS that are used extensively in this project to provide the bidirectional USART communications needed, the architecture of the stack is shown in figure 7.

Figure 7. Stack Architecture The data transmission per Lenze corporation needs to be as transparent as possible. Currently the RS-485 network runs at 9600 baud (9.6KHz), the Atmel MCU clock runs at 32KHz and the ZigBee transceiver clock runs asynchronously to the MCU at 16MHz so the MCU clock is running 3 times faster than the data rate. This will provide adequate timing for the data to be sent a byte at a time allowing the ZigBee wireless communications module to operate transparently with respect to the RS-485 network. To transmit data in this scheme each byte must be buffered in the Atmel MCU and then encapsulated into the ZigBee packet payload section, this is done automatically by the stack, the packet structure is shown in figure 7.

Figure 7. Packet structureThe firmware for this transmission scheme is still under development, if this scheme

is not successful due to timing problems the clock speed of the Atmel MCU will be increased in an attempt to obtain more processor overhead capacity. If this scheme is unsuccessful the modbus packets transmitted on the RS-485 network will be received stored and transmitted as FIFO as so each modbus packet is encapsulated in a corresponding Zigbee Packet. This second method will be avoided if possible as it will decrease the overall transparency of the

15

ZigBee wireless transceiver solution.

To start coding the firmware Atmel offers sample code written for the Lightweight mesh stack. The sample code chosen is the Peer2Peer example solution. This example file is designed to transmit a serial connection over a ZigBee wireless signal in peer to peer configuration. The code is compact and provides hardware abstraction giving the system programmer function based access to much of the important hardware. The The Peer2Peer example code is written to run on the ATMEGA128RFA1 Atmel MCU transceiver combination, however it is not designed to work with the Sparkfun ATMEGA128RFA1 protoboard so the code will need to be modified accordingly.

This sample code assumes an attached SPI bus EEPROM providing the Atmel MCU

with unique ZigBee MAC address and device parameters. This information is provided to the MCU at power up and upon request and during code execution. The current example code will need to be modified to include this information into the firmware for the prototype as to not require EEPROM implementation code. Further, provisions will be made for this information to be coded into the MCU on board EEPROM which can be uploaded before or after system production.

This sample code also assumes RS-232 to UART level converters are attached to

the Atmel MCU. Unfortunately, the Sparkfun ATMEGA128RFA1 does not include these level converters and changes must be made to the code to disable the built in RS-232 specific functionality and to enable the transmit/receive control option for the RS-485 transceivers.

Conclusion

Currently the ZigBee hardware setup is implemented and appears to be function correctly however the device firmware is still in development and this can not be confirmed as of yet. Concurrent to code development, a Zigbee packet sniffer is being constructed to aid in traffic diagnostics to help debug the system. If the first implementation is unsuccessful the steps outlined in the Atmel firmware section will be implemented increasing the difficulty of the project but creating an end product that Lenze corporation will be able to implement in current and future product lines.

Suggestions:The first suggestion is that the ATmega128RFA1 can be placed directly onto the VFD’s

RS-485 option module as there is avaliable space on the current printed circuit board. This will eliminate the need for any hardware external to the VFD, this is advantageous for marketing as the current modules are very popular. For customers with existing modules and/or existing RS-485 networks a secondary wireless ZigBee module can be attached to the current network. Schematically, this module would be no different than the current design specified herein. Therefore, existing VFD owners could make their current RS-485 networks wireless with a simple secondary connection add-on external option module

16

Secondly, the program in its current state uses a broadcast method to send TechLink commands to the VFDs. Every VFD will get every ZigBee packet and the Modbus addressing will determine which VFD responds. This is an inefficient use of network resources and a better solution would be to incorporate the Modbus address into the ZigBee address of each device. In theory, the 8 bit Modbus address can be placed into the lower 8 bits of the 64 bit ZigBee MAC address. In the MAC address, the top 24 bits are reserved for the Organizational Unique Identifier which is purchased by an OEM from IEEE. This Organizational Unique Identifier marks a given ZigBee device as belonging to the OEM. The remaining 40 bits are managed by the OEM producing the ZigBee devices. Thus the lowest 8 bits can be used for the Modbus address in this case.

Future Work:There are many benefits to making VFDs wireless. The final solution will be inexpensive and very practical to implement especially when produced at levels Lenze corporation is forecasting. Wireless technology is becoming an industry standard option and would be a great addition to the current offering of features incurring higher sales.

Timeline:

Sept Oct Nov Dec Jan Feb Mar Apr

Project intro

Research and design

Finalize design

Order parts

Order Parts

Code RS485

Code RS485

Code RS485

17

Code Zigbee

Code Zigbee

Code Zigbee

Finalize Coding

Finalize Coding

Finalize Project

Document

[ ]=Completed taskFigure 8: Timeline for Implementing the Solution.

Budget / Supplies:

Zigbee Development Kit:● Part#: DEV-09734● Description: Atmel ATMEGA128RFA1 Development Board● # Units: 1● Unit Price: $119.00● Vendor: Sparkfun● Reason for choice: Low cost fully assembled proto board, all required components

onboard and functional. No bloatware or extra hardware to abstract design. Compatible with existing hardware. Shown to be functional and Zigbee communications established. Schematic and BOM available for easy transition into production.

Atmel ISP:

● Part#: ATAVRISP2-ND● # Units: 1● Unit Price: $35.36● Vendor: Digikey● Reason for choice: Low cost in circuit programmer compatible with current hardware.

Programmer was not received from last year’s team as it was personal property however one is required to start code tests.

Supplies provided by Lenze at no cost:

● Two Lenze VFDs

18

● Two motors (in que)● Techlink software● Lenze Reference Manuals● One spare RS485 communication module● One spare Ethernet communication module

Supplies provided by School of Engineering at no cost:● Desktop PCs Supplies owned by project members (no cost):● Laptop PCs

References:

Zigbee Protocol Stack BitCloud. (n.d.). Retrieved 12 03, 2012, from http://www.atmel.com/tools/BITCLOUD-ZIGBEEPRO.aspx Zigbee Protocol Stack MACStack. (n.d.). Retrieved 12 03, 2012, from http://www.atmel.com/tools/IEEE802_15_4MAC.aspx Zigbee Protocol Stack BitCloud. (n.d.). Retrieved 12 03, 2012, from http://www.atmel.com/tools/LIGHTWEIGHT_MESH.aspx