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:
But even if you feel convinced by those arguments, a curious mind jumps into the next question - what if one makes it possible?
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:
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:
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:
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.
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.
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.