OwlCircuits
Personal Weather Station
A weather station based on the Raspberry Pi
4.5 Configuring the end device
We will follow the same steps using XCTU and our USB programming adapter to configure the second XBee module as an end device. We will need at least one end device to talk to the coordinator. The major difference with the end device is that it will be capable of sleeping since it will be a battery operated device. We will need to take special care to configure the end device so that it can work properly as a low power device.
4.5.1 Special considerations with configuring end devices
I discovered one major issue when I flashed the XBee module with the end device firmware. After updating the firmware to an end device, suddenly I was having trouble communicating with the XBee module through XCTU. Some of the settings were not taking effect and when I read them back, they were the original values and not my updated values.
This was frustrating at first but I eventually realized that once I flashed the XBee with the end device firmware, by default it was in cyclic sleep mode. Cyclic sleep mode means that the device will go to sleep every 320ms. This means that the XBee module will go into a low power mode every 320ms and you can't communicate with it, including using XCTU until it wakes back up. The issue is if you are in the middle of writing a new setting to the device and it goes to sleep, it may not see the write command, and when it wakes back up the old setting is still there.
The trick to resolving this is after you have flashed the end device firmware, you must change the sleep mode setting first. By changing the sleep mode from the default of cyclic sleep to pin sleep, the device will then remain awake until you assert the Sleep_RQ pin. On most programming adapters the Sleep_RQ pin is tied inactive, so once you configure pin sleep successfully, the module will remain awake as long as it is connected to the programming adapter.
The trouble is, it may take a few tries to successfully write the sleep mode setting to pin sleep. Since the module is in cyclic sleep by default, it may take a couple of tries to get the device into pin sleep mode.
One trick to make switching to pin sleep mode easier is that after you do a reset of the XBee module, it can take 10-15 seconds before the module joins a network. While the device is trying to join a network it remains awake. The trick is to reset the module and then immediately write the sleep mode to pin sleep. If you do this in the first 10-15 seconds after the device is reset, you have a high chance of successfully writing the sleep mode value to pin sleep.
Be sure to read the sleep mode value back after you have written it to make sure it has been written to the correct value successfully.
Once you are sure that you have changed the sleep mode to pin sleep, use XCTU to write the remaining settings into the end device. The settings that you should configure are shown in the table below. Note that some settings may already be set as they are the default.
End device configuration settings
- Flash with X24-ZB ZigBee End Device AT software
| Setting | Value | Notes |
|---|---|---|
| Networking | ||
| ID | 57 45 41 54 48 45 52 31 | (ASCII WEATHER1) 64 bit PAN ID |
| SC | 3FFF | SCAN all channels for devices |
| SD | 6 | Scan duration. How long the end device looks for a co-ordinator |
| ZS | 0 | ZigBee stack profile 0 |
| NJ | FF | Allow nodes to join at any time |
| JN | 0 | Join notification disabled |
| Addressing | ||
| DH | 00 13 A2 00 | Upper 4 bytes of Destination address |
| DL | 40 BE 28 9E | Lower 4 bytes of Destination address |
| NI | OUT TEMP HUMID (LIGHTNING) | Node identifier 20 byte ASCII string (optional) |
| NH | 1E | Max number of hops (leave default) |
| BH | 0 | Number of broadcast hops to use 0-Max (leave default) |
| DD | 30000 | Device type (leave default) |
| NT | 3C | Node discovery timeout Value*100ms (leave default) |
| NO | 3 | Network discovery options (leave default) |
| CR | 3 |
|
| Zigbee Addressing | ||
| SE | E8 | Source endpoint (default) |
| DE | E8 | Destination endpoint (default) |
| CI | 11 | Cluster identifier (default) |
| RF Interfacing | ||
| PL | 4 | Highest (default) |
| PM | 1 | Boost mode (default) |
| Security | ||
| EE | 0 | Encryption enable (Disabled) |
| EO | 0 | Encryption Options |
| KY | (leave blank) | Link Key |
| NK | (leave blank) | Network Key |
| Serial Interfacing | ||
| BD | 3 | 9600 bps |
| NB | 0 | No parity |
| SB | 0 | 1 stop bit |
| RO | 3 | Packetization timeout # of characters of silence before transmitting RF data. |
| D7 | 1 | CTS Flow control |
| D6 | 4 | Digital output default low. |
| AT command options | ||
| CT | 64 | Command mode timeout (default) |
| GT | 0x3E8 | Guard Time (default) |
| CC | 2B | Command Character (default) |
| Sleep Modes | ||
| SM | 1 | Pin hibernate |
| ST | 1388 | Time before sleep (Not applicable for pin sleep mode) |
| SP | 20 | Sleep period (Value*10ms) |
| SN | 1 | Number of Sleep periods |
| SO | 0 | Sleep options (default) |
| PO | 0 | Polling rate (default) |
| IO Settings | ||
| D0 | 4 | Digital output default low |
| D1 | 4 | Digital output default low |
| D2 | 4 | Digital output default low |
| D3 | 4 | Digital output default low |
| D4 | 4 | Digital output default low |
| D5 | 4 | Digital output default low |
| P0 | 4 | Digital output default low |
| P1 | 4 | Digital output default low |
| P2 | 4 | Digital output default low |
| PR | 1000 | Pull-up resistors enable |
| LT | 0 | Associated LED blink time |
| RP | 28 | RSSI PWM timer |
| IO Sampling | ||
| IR | 0 | IO Sample rate |
| IC | 0 | IO Change notification |
| V+ | 0 | Supply voltage sampling |
4.6 Simple loop back test of the wireless link
Now that we have one coordinator and one end device configured we can do our first test of the wireless link. We will test the wireless link directly using XCTU without the need for a microcontroller at this point.
We will need two USB programming adapters, a computer running XCTU, the coordinator and the end device XBees that we programmed earlier.
Install the coordinator XBee into one programming adapter and the end device XBee into the other. Plug both programming adapters into two USB ports on your computer.
Start XCTU and click on add device. Select the first XBee programming adapter and let XCTU discover the radio. Add another device and select the second programming adapter. Allow XCTU to discover the second radio. At this point you should have two radios detected and shown on the left hand side of X-CTU. You should see your coordinator and your end device detected.
Since both radios have been configured with the same PANID , they should link up to each other. It may take a few minutes, but since both radios are now powered at the same time, they should find each other.
The easiest way to see if the radios have linked up to each other is to see if they both have the same operating PAN ID. Click on the coordinator radio on the left side of XCTU and then click the refresh button to re-read the radio's settings.
Check the operating PAN ID value. It should be the same value that you set earlier in the PAN ID field. If it is zero, it means that the radio has not yet established a network. Operating 16 bit PAN ID and operating channel are values that are randomly selected by the coordinator but should be non-zero if a network was successfully established.
Click on the end device and refresh the settings. Check the operating PAN ID, operating 16 bit PAN ID and operating channel. They should all be non-zero and each value should match the values that the coordinator has. If the end device and the coordinator have the same operating PAN ID and operating channel, they you have successfully created a network.
Once you have confirmed that a ZigBee network has been established between the coordinator and end device, it is time to send some data between them.
Select the coordinator and then click on the serial terminal icon on the top right of XCTU. The serial terminal icon looks like a little computer screen with a prompt on it. Next click the connect icon (the plug icon) . This initializes the serial port for the coordinator.
Follow the same steps to connect to the serial terminal of the end device.
Now type "Hello World" in the terminal window of the end device. Select the coordinator terminal and you should see your message "Hello World" printed in the terminal. You can now type a different message in the coordinator terminal window and you should see it appear in the end device terminal window.
In each terminal window, data in blue is data you typed and are transmitting to the other side. Red is data that is received from the other radio.
4.7 Troubleshooting XBee communication and network issues
If the simple wireless loop back does not work, the most likely reason is that the two XBee radios did not link up to each other on the same network.
In order for the two radios to link up successfully, they must both be on the same operating channel and have the same PAN ID. Use XCTU to view the configuration of both the coordinator and end device XBee. Use the refresh button for each device to see the latest values.
Make sure to check that both devices have the same operating channel and operating PAN ID. Don't confuse PAN ID with operating PAN ID. PAN ID is the value that you set, and operating PAN ID is the actual PAN ID that is being used. If a network has been successfully established both devices should have the same operating PAN ID and operating channel. If they do have the same operating values the most likely cause of lack of communication is that you did not click the connect button on the serial terminal page of XCTU.
In many cases the end device has an operating PAN ID of 0. This means that the end device did not join a network. This is usually caused by an incorrect setting in either the coordinator or the end device. It is important for the following settings to exactly match between the coordinator and end device. If the settings don't match, the two devices essentially try to join different non-existent networks:
- PAN ID (This can be up to 64 bits long and it takes only 1 bit difference to cause a network creation failure)
- SC Scan channels. This tells the XBee what frequencies to look for other devices on. If you have different values between the coordinator and end device, it is possible that the coordinator will pick a channel that the end device is not allowed to use. You should allow all channels for both devices by setting SC to 0x3FFF on both the coordinator and the end device.
If you still have trouble and the end device has not joined a network there are a couple of other settings to check.
Increase the value of the setting scan duration (SD) in the end device. This sets the amount of time an end device scans a channel looking for a coordinator.
Make sure that you are in pin sleep mode and not cyclic sleep mode in the end device. If you are in cyclic sleep, the end device will keep going to sleep while looking for a network. This is not an issue but may cause finding a network to go from seconds to several minutes. Cyclic sleep may also cause issues with your loop back testing as your device may decide to go to sleep just as you start typing a message in the terminal. When the XBee end device is asleep, it ignores any input from its serial port.
In pin sleep mode you still need to tie the Sleep_RQ pin to zero (ground) on the end device. Don't leave the Sleep_RQ pin floating there as there is an internal pull up on the pin by default. If you don't disable the internal pull up resistor on the Sleep_RQ pin it will be pulled high indicating a sleep request. The XBee end device will scan the first channel looking for a coordinator, if it does not find one, it will go to sleep and then scan the next channel looking for a coordinator when it wakes. The problem is if you are not controlling this pin, it will stay high and the device will never wake and look on the next channel for the coordinator.
Sometimes after changing numerous settings it is wise to power cycle both XBees so that they both reset and re-create the network. A hard reset of both devices can sometime flush out strange behaviour caused by making numerous changes while the devices are trying to create a network. Make sure to power up the coordinator first, then a few seconds later the end device.
