The Internet of Things (IoT) seems to gain momentum in 2017. All major providers work on closed networks. However, all over the globe, local initiatives pop up to build a free network of things, also. Together they build ‘The Things Network’ (TTN) in the ISM-bands. TTN is a crowd-funded initiative with its roots in the Netherlands (Europe).
We are a group that wishes to research, develop and spread free network technologies. Therefore, we are very interested in the technology used with the The Things Network and LoRa in general. We’d like to know about its potential (and risks).
With our first field test, we aimed to find out about the real world range of a single channel ESP-gateway with a simple helical antenna costing less than $15 total.
The location we chose is the sub-urban town of Mechernich (NRW) in Germany, about 50km from Cologne.
We setup the gateway a) inside rooftop (indoor) and b) on the rooftop of a house (outdoor) and walked around with 2 nodes + smartphones, waiting in different spots. Collected data has been split into two datasets (indoor / outdoor) to compare the two result sets.
We also used two different nodes (one using a helical antenna as well, the other one using a simple wire antenna) to compare the antenna performance as well as speeding up the process of mapping (one packet every 6 minutes).
We purposefully decided for a gateway position far from being ideal. It’s a normal sub-urban house with surrounding buildings of same height. The rooftop had a normal, 20-30 year old isolation (about 10cm thick, with a layer of aluminium!).
To create comparable conditions, we pinned both nodes to sending on SF12 and deactivated CAD-feature (multi SF-support) on the gateway as well. Note: with these experiments, we measured outdoor coverage only. Also please note that we cut short on the outdoor experiment, when it became clear the southern area would be covered as well.
Here you can find some of the node locations. The camera is always facing in the direction of the gateway. Range and surroundings can be explored on this interactive flopp.net-map. Hover on the thumbnails to identify the location and see the rough distance or click to expand the images.
We basically went as far as we could by foot without a hill blocking RF to the gateway (about 1.1 kilometre). Coverage was great and we had no line of sight (LOS) whatsoever with any point being more than 100m away from the gateway. The simple gateway proofed it was able to basically cover the whole sub-urban city with a minimal data rate (SF12), with only slight differences with our indoor experiment.
When placed outside, the RSSI was about 8-9dB better within a range of about 500m. Above that, we did not always measure an advantage, as the RSSI would often show about -124dBm. When we did, the advantage was about 6dB. Also, we were able receive packets from a place in 1km that would not work with the indoor experiment. This is why we suspect -124dBm to be the limit of the used chip.
9 dB means that the gateway received a 8x stronger signal, which can be traded in for either range or advanced data rate. This makes the case for placing gateways outdoors, even with the better wave propagation properties of the 868MHz ISM-band (sub-1GHz).
As we used a single-channel gateway, we would only receive every 3rd packet (as the nodes use 3 channels with a round-robin approach), as we expected.
Why would you want to use better gateways in production?
Single-channel gateways and pinned spreading factors (SF) do not comply with the requirements for an official gateway. One would want gateways that can handle multiple frequencies (“channels”) with any spreading factor available at the same time, to miss no messages and to allow for higher data rates that come with lower spreading factors.
We also suspect the chips to be used with real gateways to have a better sensitivity (e.g. down to -138dBm with the IMST C880A-SPI). Unfortunately we couldn’t find a sensitivity for the ISM band 868MHz with the used Semtech SX1276.
Thanks to Janek Thomaschewski for building & providing us with the ESP gateway
Thanks to @jpmeijers for mapping service (ttnmapper.org)
Thanks to M. Westenberg for sharing his ESP gateway code repository on GitHub
Tests made by Ramdan Hamdan and Manuel Schmidt on 02.07.2017