Real-life performance of the LoRa radio

Numbers put in datasheet is one thing, but experimenting the performance in real environment gives you the confidence. According to our experiments, LoRa really does outperform other competing RF technologies.

Today I performed some RF link length and performance testing in customers premises in production facilities. The purpose was to detect the limits of different frequencies and radio technologies commonly used in Wireless Sensor Networks, which means low power and low cost. Testing was limited to license-free IMS bands with transmit power within legal limits. Protocol issues were not covered in this experiment since the purpose was to set theoretical limits of any radio.

National Instruments Finland kindly supported us by supplying necessary wireless measurement instruments: NI PXI FlexRIO SDR (Software Defined Radio) which acted as a base station, and NI USRP (Universal Software Radio Peripheral) which was used as mobile station together with laptop running LabVIEW.

RF testing ongoing: measurement man at the left,
USRP in the middle, and PXI FlexRIO on the right.

The test environment consist of 160m long warehouse with interconnected manufacturing and office spaces. All in all rather complex building with many concrete walls, number of metal plated walls, metal fire doors, and plenty of metal structures inside. Mobile phones didn't work in many spots and Wifi had very limited coverage. Definitely difficult environment for any radio, just like real industrial deployment sites tends to be.

Typical narrowband tranceiver have receiving sensitivity of -110dBm, thus we decided to map the border where typical radio can not detect signal from noise. Test results of 434MHz, 868MHz and 2.4 GHz didn't surprised much. 2.4 GHz achieved 80m link length with direct line of sights. It couldn't penetrate through the first concrete wall.

434 and 868 MHz had very similar performance to each other. Almost the whole building complex was covered with recognizable signal. Only at the other end of the building in a completely metal covered hall with tiny windows in doors the signal was completely lost.  434 MHz benefits from open doors, even if they are not within the direct line in between transmitter and receivers. This indicates the lower frequency reflects from structures better and can bounce within the labyrinth, whereas the higher frequency tends to travel more straightforward though obstacles. When fire doors were closed, there was no significant difference in performance.

Then we compared the results of narrowband RF with spread spectrum LoRa radio. We changed from NI equipment to actual LoRa hardware, as generating the spread spectrum signal with software radio would be way too complex and effort consuming exercise for the purpose of this test. ARM mbed-enabled SX1276 LoRa development board from Semtech and FRDM-KL25Z MCU development board from Freescale was used instead.

LoRa RF test equipment for 434 and 868 MHz with battery pack.

In this experiment, we did not only measured carrier signal strength, but two-way packet communication over LoRaMac was used. Other radio unit was located in the same spot with the original base station. With this setup, we couldn't identify the limits of the connectivity, as we got packets through in all over the building, even in most difficult locations.

We went event to a bomb shelter in the basement of the office wing, with heavy steel-reinforced concrete walls and blast doors. There was no problems with signal when doors were closed. We event put the radio into a all-metal locker in the bomb shelter and locked the door. Still the signal passed happily, obviously through the small ventilation holes of the locker, and through all the concrete walls up to ground and into next wing of the building.

Really incredible result!

At last we moved the base station into most distant location within the building at the end of the warehouse hall. Now we managed to create challenging enough conditions for the radio. To block the signal, several concrete walls, metal fire doors and dozen or so metallic warehouse shelves were needed. Performance of 434MHz and 868MHz Lora was similar to each other, just like recognized in narrowband Sub-GHz tests.

The conclusion: We did not quite reach the promised 150-160 dB link budget advertised by LoRa datasheets and marketing material. However, we did got 145 dB link budget in a real and challenging environment. It really does outperform any competing technologies, not only in paper but in practice as well, with actual two-way data link established.

The test was performed with two LoRa end-nodes. I'm really waiting for a possibility to repeat the experiment with real LoRa-gateway having a LoRa concentrator chip in place. LoRa Alliance was publish at the beginning of January 2015, thus it is still pretty new technology.

Internet of Testing

Internet of Testing is all about productivity improvement. Market leading test and measurement technology from NI integrated with leading Cloud technology from IBM makes at all possible.

"LabVIEW - Improving the Productivity of Engineers and Scientists". is the main value proposition of National Instruments, as stated on their web site. LabVIEW is great tool for test and measurement of all kinds of physical phenomena. Robustness of the technology makes it good for most demanding live monitoring and automation control applications.

The real value comes from the high productivity of software development with graphical LabVIEW programming language. Graphical presentation makes LabVIEW program easy and intuitive to understand, but the value lies in the great amount of readily available mathematical algorithms, instrument drivers, communication interfaces, and user interface elements.

LabVIEW program can run in a PC (Win, Mac, Linux) or in a measurement instrument (RT-Target) like myRIO, CompactRIO,SingleBoard RIO, System-on-Module RIO, etc.  However, so far LabVIEW has provided limited support for remote operations and distributed architecture. But now the situation has changed.

Internet of Things Foundation is a IBM cloud-hosted service for collecting, storing, and integrating data of Things. IoT Foundation provides ready and direct integration to Bluemix, it's like one of the Bluemix APIs. When talking of Bluemix, we're yet again talking about productivity improvement, which is the main value proposition of PaaS (Platform as a Service).

When combining these two technologies, we get productivity square two. And that's the big thing!

LabVIEW recipe for IOT Foundation

Espotel has contributed my work to the open source community. It's a recipe how to connect any LabVIEW program, running either in a PC or in a measurement instrument, to IOT Foundation cloud fast and easily. It's a simple LabVIEW library which can be included in any LabVIEW project.

Example usage of the LabVIEW library for IOT Foundation

IOT Foundation uses MQTT for data transfer. It's fast, reliable, lightweight and secure messaging protocol intended for M2M and IoT applications. The LabVIEW library consists of three main elements:

• Open MQTT connection to IOT Foundation
• Publish (transfer) data over MQTT to IOT Foundation
• Close MQTT connection to IOT Foundation

The library contains one more element for reading device credentials from a file. IOT Foundation provides secure device registration, authentication and data transfer mechanism, based on credentials. Storing credentials is a file makes it possible to use the library in any stand-alone instruments without local user interface.


Applications:

• Remote real-time LabVIEW or HTML user interfaces
• Remote measurement and distributed testing
• Condition monitoring

IoT Ecosystem Game

Internet of Things is changing the world. Not by what we do, but how we do things. This affects individuals, organizations and business ecosystems.

Until now, we have seen ecosystems dominated by a single companies. Let's take Apple as an example. In specific consumer product segments, Apple has ruled the whole value chain from hardware via software to markets and distribution channel. With the model Apple has succeeded to collect 80% of profits of smart phone industry, with only 18% market share.

IoT however is way too diverse for any single company to dominate. Applications vary from hen houses to connected cars, from thermostats to medical instruments. Just like technical architectures are changed from M2M verticals to horizontal layers of IoT, are businesses forced to co-operate with partners and competitors.

M2M vs IOT architecture.

Connected devices is nothing new, M2M has existed from 10 to 20 years already. However, M2M  tends to be like vertical silos, application specific end-to-end solution with limited expandability. IoT as opposite is more like Internet architecture in general, horizontal layers without predefined purpose for any specific function.

Changes in connectivity architectures reflects to ecosystems. A healthy IoT ecosystem has different players for different horizontal players, and preferably many of them. A good example of IoT ecosystem is build around ARM and IBM. ARM provides technology for Things and  IBM for Internet, making it Internet of Things.

ARM embed and IBM cloud offering are really a winning combo. ARM has the strongest ecosystem of silicon vendors. IBM with it's new cloud offering and partnership with Apple, ARM, Semtech, and many more has really gained reputation. This heterogeneous and loosely linked ecosystem has no single point of failure.

There is no ring to rule them all, and there is always room for new trials. That's the only way how the technology can go further in large scale, the law of natural selection applies in technolofy as well.

Just recently Intel announced a new IoT platform, partnering with Accenture, Capgemini, HCL, NTT Data, Tata Consultancy and Wipro. Basically, that's a single silicon vendor with bunch of consultants. Doesn't sounds like a healthy ecosystem. I expressed my thoughts  about the Intel Edison/Quark technology already a year ago. The technology is the basis of this new alliance, which really doesn't convince me.

Node-RED for Home Automation

Node-RED is a great tool for creating graphical data stream integration and processing flows. Now Node-RED is even better suitable for home automation, as support for multiple different wireless sensors is added via Tellstick Duo.

Yesterday I started to prepare a demonstration for a local Node.js meetup in Helsinki. Node-RED is built a top of Node.js, thus it is natural topic for a presentation in the meet-up. Meanwhile preparing the demonstration, I ended up creating an input node into Node-RED for Tellstick Duo. It is now contributed to the project.

The node is available in npm and github with name node-red-contrib-tellstick.
More detailed information is available on my web site: http://ala-paavola.fi/Node-RED

Node-RED with tellstick input node.

Tellstick Duo is USB-connected 433MHz RF transmitter and receiver from Telldus Technologies in Sweden. It supports wide range of commercially available sensors and devices from different vendors.

Node-RED was initially created by IBM Emerging Technologies at IBM Hursley lab, Winchester UK. It was released as an open source project and is still actively maintained and supported by IBM. It's one of the key assets in IBM Bluemix portfolio.

Couple of weeks ago I met one of the initial creators of the software, Dave Conway-Jones (@ceejay). His answer to my question why did they released it as open source in the first place was something like: "We tough it's so cool that it would be a crime against humanity not to publish it to the whole world." Well, perhaps Dave didn't expressed it exactly like that, but that's how I feel it.

Node-RED is really gaining momentum at the moment. More and more manufacturers are including it in their products, Multitech Conduit IoT Gateway as an example.

More and more devices are supported by Node-RED, Philips Hue for example.
A friend of mine, a system operator, created a build health status indicator with help of Node-Red and Hue. He integrated Node-RED into their company continuous integration tool chain, and now everybody in the office see what's the status of the build. If someone breaks the build, server room neighbourhood is immediately glowing red...

LoRa in constructed environment

Suddenly LoRa has became one of the hottest technologies in the Internet of Things domain. The number of new customer cases we see in our company is increasing on a daily basis. But where's the beef?

There are two main use cases where LoRa is strong:
- Wide area wireless sensor network (W-WSN)
- Factory (or any facility) area netwok (FAN)

In W-WSN applications, individual diameter of individual LoRa cells may vary from 2 to 20 kilometers. This makes it possible to collect data from many sensors into single gateway for upstream via wired or wireless connections (3G/4G data mode). This is the modem killer scenario explained in previous posting.

Factory area network with star-topology.

FAN is perhaps more common use case for LoRa. Facility can be anything including factory, refinery, warehouse, seaport, shopping center, or office block, and all other cases where mainstream technologies like WiFi, Bluetooth, Zigbee, and other 2.4 GHz RF can't do the job without unreasonable number of access points or complex multi-hop routing algorithms and routing node.

LoRa modulation has certain characteristics which make it suitable for difficult constructed environments like a factory.

Aa a rule of thumb: the lower the frequence the longer the distance, or better peneration. Reduction from 2.4 GHz to Sub-GHz frequencies alone gives significant improvement. The CSS modulation of LoRa makes it possible to detect signals 20dB below the noise floor, yet giving improvement over traditional narrow-band Sub-GHz radios.

Multipath propagation

Multipath fading is a common problem in constructed environment. Signal may travel via multiple different routes due to reflections from different surfaces. It's like echo on a railway station making it very difficult to understand announcements given by loudspeakers. In radio technology, multipath propagation may cause signal amplification or attenuation with short displacement of the receiver.

Up-chirp, increasing frequency sweep in time domain.

Different frequencies have different reflection signature. Chirp Spread Spectrum (CSS) uses frequency sweeps to carry information. During the sweep, some frequency may attenuate, whereas some other frequency may be amplified. All in all, detection of signal in receiver side is very reliable. Consider the railway station example. If audio frequency sweeps - chirps - are broadcasted from loudspeakers, human can easily recognize whether the individual sweep is going from low to high (up-chirp) or from high to low (down-chirp), even if significant echo takes place.

Frequency also affects signal penetration. Due to various reasons, certain frequencies may penetrate better than others. By spreading the signal to wider bandwidth, we increase the probability that some signal gets through. According to our experiments, LoRa has been the only commonly available IoT RF technology, which can deliver data from inside a closed metallic storage container to outside world.

LoRa - the modem killer?

Internet of Things is at the top Gartner's hype curve of the year. But how to get the Things into the Internet? - That is the question.

When designing a IoT system, device connectivity is often among the biggest headaches. In case of consumer products, it is usually possible to rely on existing infrastructure, either Wifi Access point or Bluetooth/Smart connectivity of mobile phone. When considering city-wide installation of wireless sensors network or intending to cover a whole industrial plant, those consumer technologies are simply not feasible.

In practice, individual sensors are Today often having a cellular data modem with them, which is totally overkill. Reading a single sensor value every now and then does not need the bandwidth which is good for streaming video. Modem by itself as a component is usually more expensive than rest of the sensor electronics, and it ruins your power budget. Finally but not least, management of SIM subscriptions in global context is a nightmare.

Why there are so many cellular data modems then? Because there has been no other real options available. Low power 2.4 GHz radios like 802.15.4 can only do about 100 meters in open space. Wifi can be extended to some 500 meters, but then power consumption is over battery budget.

Sub-GHz radios can address the range issues. Narrowband RF like in TI portfolio are proven to have good performance in distance. A interesting new alternative is Semtech Lora.

Freescale FRDM-KL25Z Cortex-M0 evalution board with
ARM mbed-supported LoRa Shield from Semtech.

LoRA is a long range sub-GHz spread spectrum radio technology from Semtech. LoRa uses proprietary chirp spread spectrum  (CSS) modulation, which is rather unusual solution for data communication. CSS is more commonly known in radars and that sort of applications. In sensor node communication, added value of CSS is rather good distance measurement, which is far more accurate than traditional RSSI estimation.

BOM cost of Sub-GHz RF subsystem is less than 5€, which fits into the price range of most IoT sensors. However, having the radio in the sensor node only is not good enough. Also infrastructure is needed. In building-wide installations one can assume a gateway or two to be easily installed and maintained. In case of metropolitan area network the situation is different. Some one must build and operate the network infrastructure.

There are some indications that traditional telecom operators may be interested in introducing IoT networks. It may be considered as direct competitor with existing M2M cellular data business, which may hinder operators interest. However, if operators don't do that by themselves, some one else will do it, and then operators are only loosing.

FastNet in South Africa is the first public reference of a telecom operator investing in LoRa-infrastructure to provide IoT communication services. However, the playground is not reserved for traditional operators only, but new players like energy or transportation companies may invest into network infrastructure of their own and start selling capacity to other players as well.

Is Java dead?

While studying in the university at the turn of the millennium, Java was described as the programming solution to pretty much everything, and Java processors running bytecode in hardware were the future promise of embedded systems. 

Well,  Java processors never really made their way into mainstream, and nowadays you never hear anything of them. In the context of embedded systems, Java by itself is now performing similar act of dissappearance.

Last week I attended Embedded Conference Scandinavia as a speaker and exhibitor. ECS is the leading embedded event in the Nordics. Good for making contacts; compact and very well focused.

This year at ECS, I didn't heard anyone talking about Java or presenting any Java-based solutions. In the context of embedded systems, Java simply doesn't exists anymore - If it ever really existed? Last year I wrote about my toughs on java: Java for embedded - does it really make sense? (Sept. 2013). This year I'm even more convinced it really doesn't make sense, and other people are more and more thinking alike.

Snapshot of Freescale presentation slide at ECS.
MQTT, Node-RED, Node-JS, Bluemix and mbed promoted.

At ECS, I gave presentation about issues like MQTT, Node-RED, Node.js and Bluemix, and how to utilize them when creating embedded solutions. Just like I have done in numerous previous postings in this blog series. I was delighted to see I'm not alone with my message, companies like Freescale and Multitech also openly promoted the very same technologies and gave presentations at ECS.

If not Java, what then? ARM mbed platform is really gaining momentum now, and the ecosystem is growing with increasing acceleration. Freescale, IBM, Multitech, they all promote and support mbed Today. My first experiences with mbed are reported in Internet of Things with help of ARM (Aug. 2013).

Death of Java is not a tragedy. Instead it gives more space for proper programming technologies like mbed, Node.js and Node-RED. Think of world with Java never invented - all the millions of man years of wasted effort used for something useful...