Lora 443 – How to make wireless as reliable as wired!

Lora 443 – How to make wireless as reliable as wired!

April 5, 2019 0 By Daniel Moraczewski

In the previous article I was introducing to you our CANx technology which we are already successfully promoting on the market.  I didn’t mention there that we didn’t only focus on the wired technology but wireless as well. Our CANx range of devices contains both interfaces in a single device. You have a choice if you want to use it as a wired or wireless product.  At the same time any of the CANx/LoRa devices act as a gateway between both worlds.

In the old times when I was a SI I always stuck to wired solutions as reliability is for me the most important.  If there was a need for wireless, I would have stopped the Earth and found a way to pull the cable. The reason for this was simple: no single wireless solution worked for me reliably enough. Even if it worked fine most of the time in some cases it failed. If there was no other way, I was using EnOcean which has a limited range and a lack of security, but it was pretty good for cable extension due to less busy frequency and very short time on the air to send telegram.  The other good point about EnOcean was that it talked directly to gateway without any meshing and didn’t rely on any other devices to pass telegram further. This always limited the possibility for telegram not being delivered.

You probably ask yourself the question now, what is wrong with mesh network?  As with many technologies they look good on PPT but the real-world life corrects it brutally. If you ever installed any bigger mesh network, you must have experienced the issue that for some reason one or two devices couldn’t communicate and you had to add a dummy device nearby to let it repeat the telegram.  Other issue with mesh is that if one device fails it can put down a big chunk of the network as it could be located in a strategic place. Something what you need to be aware of is that when one node is sending telegram and it must go through few repeaters, each repeater is adding a delay.  When you sum up all the delays it is a significant amount of time.  I used to work in an office where Zigbee lighting was installed. The whole ceiling was full of ZigBee nodes with a distance of 1-2 meters from each other and a presence detector in the middle.  You wouldn’t think that such a close and condense network would have issues. You couldn’t be more wrong. Once in a while when I entered my office the lights simply didn’t come on.  To be funnier they weren’t installed any push buttons to manually control the lights. Each time I had to leave the office for the 25 minutes of PIR staircase timer and hoped next time the lights would switch on.  Once I was testing another Zigbee gateway and it was not connected to the lights at all.  I forgot about it and went for a business trip for a few days. Next day I had a call from the office, they were asking me if I had any Zigbee device on my panel as the light system was down 😊. Once they disconnected my gateway it started to work again.  What is even funnier, on this day when I was off, they were trying to add some new lights to the system and somehow my gateway picked them up faster than the lighting gateway and this ZigBee node was locked to my network. They had to send them back to the factory for re-flashing as there was no other way to reset it 😊.  With Zwave I have a similar experience as sometimes it simply is not working.  No chance to say why as it is hard to monitor a wireless network.  This is why cable is cable!

OK but we are here not to waste time on complaining about other wireless systems.  In today’s world there is no option to go always wired and we had to find proper solution which does deliver a solid, long range and secure communication.  When you look at an overview of different wireless technologies, we can split them in two types. One is short range and here we have BLE, Enocean, Zigbee, Zwave, KNX RF etc.  There is a second type which is long range and here we have 4G LTE, Sigfox, OnRamp, LoRaWan, etc.  The long range is used for industrial applications and telecom providers for IoT applications.   The distance difference split is simple: the short range is defined in meters and the long range is defined in kilometres. To avoid the need of using mesh network we selected one of the long-range networks and applied it to our application.  The decision was to use LoRa as the medium.  Here is an image representing differences in the range compared to the speed and power needed to send data.

To increase the distance and the wall penetration we selected the 443Mhz frequency.  This frequency lets us go much further then any other wireless network in building automation.  This frequency is freely allowed to use in all Europe.   Should there be a need for different frequency, we can make a module with 868/900Mhz and even 2.4Ghz.  

In most cases the reason for a wireless network being interrupted is interference by other network with the same frequency.  433Mhz is the less busy frequency. To be even more robust we implemented 8 none-overlapping channels. We can make very dense installations with several sub-networks.

Transmit power is selectable so we can choose how much dBm a device will produce. We can go from 2 to 17 dBm. We even allow to choose bandwidth and Spreading Factor.  Based on those parameters we can make the decision if we need a longer range or a higher data speed. With our 8 none-overlapping channels we can make different selections based on application needed on the same project.  Heating doesn’t need to happen so fast, but we must make sure all data goes through. Higher speed and lower data rate can be used on other applications like lighting. Remember that each device has both media on board so there is no need of buying any expensive gateway.  You can easily mix and match on the same project.

We implemented several operation modes: with Acknowledge, without it, only for received or only for sent telegrams. Depending on the application we can choose the right solution and we will have a full control of what is happening.  We can configure a device to need so little power that it could run battery-less like EnOcean.

Further, for better optimisation each gateway between CANx and LoRa has a filtering option so we don’t have to flood wireless network with not needed data.

Hope count is also implemented to avoid loops in case more than one gateway is added to the same network or to make device to work as a repeater. 

Another functionality is Ping which is used to monitor the network if all devices are online. This is configurable so devices which should save its energy do not need to answer. 

As you could imagine, data send between devices is simply CANx. There are two ways of communication. We can talk either peer-to-peer or via broadcast to all clients.  As CANx, Lora-CANx and KNX have the same data structure we can mix and match all networks out of the box.

Such architecture is easily possible:

2019 is called the year of security.  The sentence is used not for manufactures, only for customers.  This year they are meant to understand why security is so important. Up until now the product selections were made based on nice design. Now the decisions will be made based on security! Security in upcoming years will be the most important topic and a lot of products will disappear from the market due to lack of it.  Taking this into account we treated it very seriously and implemented 2 types of security: passive and active.

The difference between wired and wireless network is that to hack a wired one you must be connected to the network. With wireless you just must be in its range as everything is in the air. For this reason, we implemented passive security.  Devices can be configured only via wired connection. This excludes any remote configuration without direct access to the device. Radio transport is used only for data message. There is no public keys exchange or any other security related configuration possible over wireless.  Firmware upgrades are only possible by accessing each device phisically. Recently the most common way to hack devices is when there is a firmware upgrade over the air.  Here as an example when Xiaomi Scooter was hacked via BLE: https://www.wired.com/story/xiaomi-scooter-hack/

For active security we implemented:

Configuration messages can be blocked when using wired connection. Enabling and disabling this block requires a unique network key which is programmed once during commissioning and cannot be read back from devices

Radio messages are time-stamped to prevent replay attacks. Each device compares the time-stamp from received messages with the internal clock. If the time difference is larger than accepted range the message is ignored. Central gateway device provides synchronization timing beacons.

Data encryption is based on ChaCha20 and it is more advanced than AES128 encryption.

The implementation reference for ChaCha20 has been published in RFC 7539; proposed standardization of its use in TLS is published as RFC 7905; use of ChaCha20 in IKE and IPsec has been proposed for standardization in RFC 7634.

Widely used in operating systems, VPN protocols and Internet security (e.g. Google’s implementation secures https (TLS/SSL) traffic between the Chrome browser on Android phones and Google’s websites).

To summarise CANx over LoRa is a fast, secure, robust, long range and extremely flexible wireless solution.  Our CANx devices come with both mediums on board and you can mix and match what you need for application.