- Zigbit Overview
- Atmel Lightweight Mesh (ALM) Overview
- ALM Peer to Peer Application
- Step by Step Peer to Peer Example using ALM
- Common Issues
- Contact the Author
This page was written for Mature ZigBit modules. Click here for information on the newer modules.
This page describes how to setup Peer to Peer communication between two Zigbit modules using Atmel's Lightweight Mesh wireless stack.
The Zigbit is a family of Atmel RF modules containing an AVR microcontroller and an Atmel RF transceiver. All Zigbit modules contain an ATmega1281 microcontroller. The 2.4GHz Zigbit modules contain an AT86RF230 radio, while the 900MHz Zigbit module implements the AT86RF212 radio. Data transfer between the microcontroller and the transceiver occurs through each device's SPI interface. The ATZB-24-A2 Zigbit module was used for this project.
Atmel Lightweight Mesh software stack implements a proprietary low power wireless mesh network protocol. It is designed to work with all 802.15.4 transceivers from Atmel and can be loaded to any AVR microcontroller from Atmel. It can be used in a broad range of wireless applications including Alarms and Security, Automatic Meter Reading, Home Automation, as well as simple wire replacement applications.
The latest version of ALM can be dowloaded for free from Atmel's website here:
Atmel Studio 6 can be used to add a user application on top of the wireless stack. Atmel Studio 6 can be dowloaded for free from Atmel's website here:
The ALM download includes various pre-written Atmel Studio projects for multiple platforms, including Zigbit. The Peer to Peer project is designed to implement a 2 Node network using the ALM stack. There is no parent-child relationship within the ALM protocol, so this project displays true Peer to Peer behavior. The following describes how the Peer to Peer project is intended to operate.
Figure 1: Peer to Peer Communication
When either of the Zigbits receives data on the respective UART_RX line from an external device, the characters are immediately transmitted over the air to the opposite Zigbit. Whenever either of the Zigbits receives data over the air, the data is transmitted through the Zigbit's UART_TX line to an externally connected device. An example of an external device would be a PC with some sort of hyperterminal software. In this way, characters typed on PC 1 could be printed on PC 2.
The ALM does not provide a way to auto-assign an application ID on the fly to a node attempting to join the network. It is up to the designer to assign a unique ID within the application code of each device. The Zigbit Peer to Peer project includes a configuration file called config.h which can be used to assign the application ID. For two devices to communicate properly using the Peer to Peer application, define one device's application address as 0 and the other device's application address as 1. The application channel, PANID, endpoint, security key, and flush timer interval should be the same for both devices. If the user is using a PC with a hyperterminal program, it would be a good idea to add the following line of code to the HAL_UartBytesReceived() function in Peer2Peer.c:
immediately following the HAL_UartReadByte() function call. This will echo keystrokes entered from the keyboard.
For this example, two Zigbit modules will be used to communicate between two different hyperterminal programs on separate computers using topology similar to that shown in Fig. 1. When the user enters keystrokes in one hyperterminal program, the characters are displayed in the second hyperterminal program.
Two Zigbit modules with integrated chip antenna (ATZB-24-A2) were used for this example. Additional items used include JTAGICE3 programmer/debugger (ATJTAGICE3-ND), and two UART/USB bridge cables (768-1015-ND). The Zigbit modules were mounted onto a break out board for easy evaluation. The cables used in this example allow the user to communicate to the Zigbit UART through a USB port of a PC.
Figure 2 below shows the external connections between each Zigbit and the respective PC. The UART of the Zigbit was connected to the PC using the UART/USB bridge cable (768-1015-ND). The serial port settings were set to:
The JTAGICE3 was connected between the PC and Zigbit using the standard cables included in the kit. A general purpose LED was connected to GPIO0 of the Zigbit module to monitor status.
Figure 2: Zigbit Connections
Figure 3 shows the proper connections between the Zigbit UART and the PC serial port.
Figure 3: UART/PC Connections
Note: If using the UART/USB bridge cable from FTDI (768-1015-ND) to connect the Zigbit to the PC, the cross-over connections shown in Fig. 3 are already done within the cable. Consult the cable datasheet for a pinout of the cable connector and simply connect TXD of cable to TXD of UART. Do likewise for RXD, CTS, and RTS.
Warning: The FTDI cable draws power from the USB port. Therefore, the Vcc line on the cable will source 5.0V to the target. Make sure Vcc of the cable is not directly connected to Vcc of the Zigbit or damage to the device could occur. Use a voltage regulator to drop the voltage to 3.3V or use an external 3.3V source to power the Zigbit module.
In this section the two Zigbit modules will be referred to as Device 1 and Device 2. For this example we will only make a few additions on top of the stack to get the user familiar with how and where the stack should be modified.
This step describes how to configure a GPIO pin of the Zigbit and also how to create a miscellaneous application software timer within the ALM. To be able to use the LED, GPIO0 needs to be configured as a digital output pin. For this example, we will use the LED as a heartbeat for the module that toggles every second, indicating power up and proper function. If the user does not want to use an LED or configure a software timer, skip to step 6. In Atmel Studio, in the Solution Explorer window, navigate to hal.h and add the following line of code:
Also within hal.h, add the following lines of code under the function prototypes:
Navigate to hal.c. Add the following two lines of code to the HAL_Init() function:
Navigate to Peer2Peer.c and add the following variable declaration:
Add the following lines of code at the end of the appInit() function to configure a 1 second heartbeat software timer:
Add the software timer somewhere above the main function as shown below:
Now build the project and program Device 1. Make sure the LED is connected to Device 1 as shown in Fig. 2 above. If the LED is properly connected, it should toggle every second.
Since we are using a hyperterminal program, it may be desirable to echo keystrokes in the terminal window. To accomplish this, add the following line of code to the HAL_UartBytesReceived() function, after the HAL_UartReadByte() function call:
Now, as the user enters keystrokes in the hyperterminal program, the characters will be displayed in the terminal window.
By default, the ALM enables basic network security. For this example, we will also enable Ack signals between the two devices. In Peer2Peer.c, modify the options in the appSendData() function to enable Ack signals as show below:
Application configuration is based on definitions within config.h. For this example, we will leave the default configuration for Device 1. Navigate to config.h and verify the following definitions are made:
Connect Device 2 to the JTAGICE3. Verify proper fuse settings for Device 2 as described in Step 3 above. Navigate to config.h and make the following change:
All other definitions should be left alone.
Figure 3 below shows an example output from the terminal window connected to each device when the following message is entered:
"Hello, My name is Zigbit"
From this basic example, the user should be able to transmit data from one device to another. Characters received over UART were used as the data source in this example, but anything can be used as a data source. A simple button press, or physical measurement from a sensor could also be used as a data source. The example uses a software timer to transmit every 20ms if data is present. However, it is up to the designer to determine when transmission occurs.
Verify that the program is getting through intialization properly. Start debug session or add the following code at the very start of the main() function:
If LED still doesn't turn on, there's a connection issue. If LED does turn on, verify that system initialization is being completed by moving the block of code after initialization.
Navigate to the following variable declaration and remove 'static' keyword:
If connections and configurations appear to be correct, navigate to the following variable declarations and remove 'static' keyword:
Ensure each radio is entering receive mode. Enter a debug session or navigate to phy.c and place the following lines of code in the phyHandleSetRequests() function:
Make sure an active low LED is connected to GPIO0 and GPIO0 is not given a logic level '0' anywhere else in the program. Build project and program device. If the LED doesn't come on, navigate to the following variable declaration and remove 'static' keyword:
and see if LED turns on. If it does, remove the GPIO0 code, reprogram, and the radio should enter receive mode as intended.
If data is being received by the radio, but no data is getting stored in the PHY receive buffer, navigate to the following variable declarations and remove the 'static' keyword:
Was this section helpful to you? Are you encountering an issue not covered by this section? Do you have a fix for an issue not talked about here? Email the author.
The reader is strongly encouraged to fully read all documentation referenced on this page. Much of what is stated on this page appears somewhere in a devices datasheet. Many of the details of the functionality of the stack, radio, and microcontroller were not discussed on this page. Reading the ALM Developer Guide will give the reader a better understanding of the network protocol and how it compares to other wireless standards. For questions or concerns regarding this example usage of the ALM, contact me at firstname.lastname@example.org. I will continue to add common issues as they present themselves. Internal Zigbit schematics are available per request.