There are moments in an individual's life, when a simple yet silly question comes into his mind and tries to disturb the way we think about technical solutions around us. In my case that question was: could you control your Zigbee network from one thousand meter distance?
The obvious answer was - no, it is not possible nor needed:
- There were on-site measurements done, which showed, that a typical Zigbee link over 2.4GHz band reaches around 300-400m range in a free field.
- One of the reasons behind using mesh protocols is to extend the range by adding more nodes, instead of going for higher transmit (TX) powers.
- Using a short range transceivers decrease the probability of on-air collisions, so both you and your neighbour can control your smart lights without issues.
- Increasing transmission power is not always possible, due to power consumption restrictions.
But even if you feel convinced by those arguments, a curious mind jumps into the next question - what if one makes it possible?
- Going through walls, doors or other obstacles would be easier.
- Installing smart products in huge facilities, such as hotels or conference centres will not require you to think about weak links or to use dummy repeaters.
- Connecting door locks to your yard, garage, or shed would be possible.
- All sensor kits may be installed inside the garden, making your alarm system more robust and precise.
- Smart solutions may be installed on a farm to monitor plant's growth, even if the field is distant from the house or incorporates several sections.
- If some device looses connection to the network, you are 99% sure it gets sunk, stolen, or brought outside your home.
In my case, the small list of new possibilities made me decide to give it a try.
The problem to solve was how to overcome the range limitation, without breaking the technical decisions mentioned at the beginning of this text. What's more, it would be extremely impractical if the solution would require to redesign all existing devices to use the new, better protocol or radio standard.
Let's take a look at the typical Zigbee smart lightning system installation. Usually a starter kit contains a light bulb and a switch, communicating with each other over Zigbee.
According to the fact, that I decided not to change the protocol or the transmitted power, the problem cannot be solved without adding more devices. One of the technical possibilities, that were introduced by chip vendors, is a multiprotocol solution. It has been shown that with this kind of chip you may control the network from a mobile phone, but can it be used to extend the network range?
The first protocol to mix with, that came into my mind was Bluetooth Low Energy with a Coded PHY (long range). The feature, that I was interested in the most, was the idea of increasing the range (link budged) by using a special codes, so the receiver sensitivity is increased. That way, the transmitter on both protocols would use the same TX power and the range would be still extended.
The next decision to be made was what kind of information should be put inside Bluetooth packets to meet all of the requirements? As I did not want to modify existing devices, the whole Zigbee packet (including ZCL/AF/ZDP/NWK/MAC layers) needs to be put inside the Bluetooth packet. It was also a convenient option for me, because I decided to use nRF52840 platform and the Zigbee stack is delivered as a library in Nordic's SDK, so the only piece of code, in which I could introduce my modifications was the nRF IEEE 802.15.4 radio driver, available on github.
As a result, the Zigbee stack would stay unmodified and the code needed to implement the range extension would be injected between the radio driver core and the public API, used by the Zigbee stack.
The solution sounds doable, so let's go through the list of requirements:
- The regular Zigbee links are not altered and stay at their typical range.
- It does not introduce more powerful transmitters.
- The probability of over-the-air collisions between two sites is not increased.
- The proxy device will be a Zigbee Router, which will bring a connectivity for the whole network, without modifying existing devices or deployment.
From Bluetooth point of view, I decided to start from the throughput multirole (central/peripheral) example and change the application layer to Nordic's UART service. That way I could use it as a raw data pipe to relay Zigbee (precisely - IEEE 802.15.4) packets.
The first test was done without special preparations. I simple flashed the Development Kit (DK) and left it next to my laptop. Afterwards I flashed the second DK, connected to the power bank and walked outside. The range was not so promising. I was able to get a Bluetooth connection from one floor distance (on the staircase) and around 150m through the window.
For the next test I wanted to verify, if the window barrier was that tough and if I can get closer to the results presented in Bluetooth Long Range tests done by Nordic [Nordic's long range tests]. There was only one issue - how to place a DK outside the window, so I can walk through the street and check if the solution works? After a quick search through my flat I found that I do have a perfect tool to do so. It has a flat surface to set the antenna angle, a canal to put the USB power cable and a huge ballast, so even if the perfect duckt-tape-based mounting fails, nobody get hurt. In a couple of minutes, my professional, well-trusted hoover machine based mounting was completed.
This time I got better results:
- around 300m distance for native Zigbee link
- impossible to measure distance for Bluetooth long range link (the street ended after around 450 meters).
I felt that the firmware was prepared to go for a test on a huge field.
The set of hardware that was used to perform the final test contains:
- Two nRF52840 DKs, working as Zigbee-over-BLE proxy devices.
- One nRF52840 DK, working as a Zigbee coordinator.
- Basic smart lightning kit (light bulb and a switch).
- Small UPS, which was used as a mobile power plant for the regular 230V light bulb.
- One DK was flashed with the unmodified coordinator firmware.
- Light bulb was reset to factory defaults, so it connects to the new Zigbee network.
- Light switch was reset to factory defaults, so it connects to the same network.
- Light bulb was reconfigured by the switch (long press of the button on the back of the switch), so it gets assigned to a Zigbee group, controlled by the switch.
- Connectivity between the bulb and the switch was verified by a single toggle.
- Remaining DKs (two) were flashed with the Softdevice S140 and the Bluetooth proxy firmware.
- One of the Bluetooth proxy nodes was started as peripheral (single press on button 3), the other one as central (single press on button 4).
- LED1 on both proxy boards turned on, indicating that Bluetooth long range link was active.
- The proxy functionality was verified by pressing the toggle button on the switch (both LED2 and LED4 toggled on proxy boards).
As the first step I put all DKs and the light bulb at one place and walked with the switch. One of the DKs was kept around 1.5m above the ground, facing the direction to the switch to get better results. The maximum measured distance, at which I was able to toggle the bulb was 393.52m
Afterwards I came back for the proxy DKs, activated Bluetooth roles and walked with both the switch and the proxy DK. The second proxy DK was placed around 1.5m above the ground, facing the direction of my walk path.
What was a bit surprising, I was able to create a Bluetooth long range connection only at maximum 500-600m distance, but the established Bluetooth link could go much further. Most probably I have misconfigured scanning/advertising parameters, which resulted in this limitation. Further investigation is needed to see what has caused this issue. According to the Bluetooth long range measurements done by Nordic, both connected and not connected states should give similar range results [Nordic's long range tests].
Keeping a Bluetooth connection established, I walked much further than in the first test. The working Zigbee over Bluetooth connection reached 1200m distance. The connectivity was checked by pressing buttons on the switch. There was no need to perform special actions on the proxy boards.
The challenge showed that the 1000+ meters Zigbee (over Bluetooth long range) link is possible. The of-the-shelf set was working as if both devices were placed close to each other, only with a larger delay. The solution met all requirements and was confirmed by the field test.
The firmware, the source code
If you want to check how this solution will work in your environment, you may find the firmware file attached at the end of this blog. The device implements a simple Zigbee router without a Touchlink functionality, so please use a coordinator example from Nordic's SDK to get it running with your smart lightning set. This firmware is based on Thread and Zigbee SDK v3.1.0. It should also integrate with any hub-based Zigbee network without issues.
- LED1: Bluetooth connection is established.
- LED3: Zigbee connection is established.
- LED2: A frame was received from Nordic's UART service.
- LED4: A frame was sent through Nordic's UART service.
- Button 3: Activate Bluetooth peripheral role.
- Button 4: Activate Bluetooth central role.
As the code used to perform those tests is at a very poor quality, I am not going to publish it in the current form. I have learned which features of the implemented modules are required and which were absolutely unnecessary, so the next step would be rather to redesign and reimplement it than trying to clean and stabilize it. If the code will be improved or I will see a huge interest in it, I will publish it on github and place a link here.