In this tutorial I'm going to show you how you can integrate yours automated garage doors or gates with your domestic Internet of Things network using an ESP32 board (which I already used in many projects), in order to control them using your mobile smartphone instead of the proprietary RC remote, thus extending the operating range of the gate control almost to any place where there is an internet connection.

To do this, I'm going to use three main components: an ESP32 or 8266 Wi-Fi powered relay board, an MQTT broker inside my home network and finally my smartphone with an MQTT dashboard app installed and properly configured. This solution allow me to control my gates and garage doors, without using no more the proprietary remote controller, which has a very limited operating range.

Also, this solution could be easily integrated with Google Home, as I already did, providing a useful and practical tool to control my gates and garage doors when I'm approaching home by car, thus allowing me to open them using Google Assistant without remove my hands from the steering wheel. But I will talk about Google Home integration in another article, since there is already much to do.

Open any automated gate or garage door with your smartphone and an ESP32

Requirements

In order to create our gate opener, we need many components. First of all we need an ESP8266 or ESp32 board. In my case, I decided to use a generic ESP32 board, based on the ESP32 microcontroller. You can easily find it on Aliexpress for a 3 or 4 dollars. Then, you need at least a relay module, at least because some gate automation mechanism has multiple inputs to control complete or partial gate opening, like mine. I bought a board with two of these optocouplers, which can handle 28 volt in DC or up to 220 in AC. They can be feed by the ESP32, since they work at 5 volt.  Then, we need a power supply or, as in my case, a voltage converter, since many gate automation boards work between 12 and 24 volts, while the ESP32 needs no more than 5 volt. I bought an LM2596 voltage converter, which can handle up to 35 volt as input, converting it to an output as low as 1.2 volt, so inside our operating range.

Finally, at least on the hardware side, we also need many cables for the wiring, both between the ESP32 and the relays, both between the power supply, relays and the gate control board. We also need some raw material and an IP67 box for the boards housing. Finally, moving on the software side, you need an MQTT broker, a smartphone and, of course, a Wi-Fi network.

About the MQTT broker, I decided to make my own broker (Mosquitto) on a Raspberry Pi 3 placed inside my home network, but there are also many online free available MQTT broker, hosted from AWS or Azure, which provide some free messages every day, which, for this kind of use case, should be enough. If you need a lot of messages, AWS MQTT broker has a cost of about 1.5 dollar for 1 billion 5 KB messages, that's a lot to play with. Remember to use a Private MQTT broker, otherwise anyone can subscribe or publish on your gates topic, thus controlling them.

As mobile application instead, there are many possible MQTT dashboard mobile apps. I picked up THIS ONE, it has a very good looking dashboard, with nice pics and custom buttons, allowing free customisation. Finally, I already have a good Wi-Fi coverage in my garden, so be sure that the interested areas have Wi-Fi coverage, otherwise the system will not work.

Summarising, you need:

• one ESP8266 or ESP32 board (my choice);
• one or more 5V relays (my choice);
• many cables with standard PIN dimension;
• an IP67 box (my choice);
• your own private MQTT broker (Mosquitto, if you have a spare Raspberry Pi inside you home network, or AWS or Azure to create an online broker);
• MQTT Dashboard mobile App;
• your smartphone;
• a 2.4 GHz Wi-FI network.

Total cost should be less than 30$.

If you have many gates or doors to open, you'll need many devices like these, one for each door or gate to control. So the overall cost depends on how much devices you plan to deploy, but if you buy all the components from Aliexpress, maybe multiple packs of products, you are going to save some money, thus reducing the final system cost to less than 20$ for each node. Also, if you would like to deploy a cheap home made MQTT broker, you can also use a Raspberry Pi Zero, which is just 10$.

Just remember that COTS (Commercially On The Shelf) based available solutions like this one, cost hundreds of dollars, so with our home made system we have huge savings and a lot of fun.

Software setup: allow the ESP32 to control your gate or door

Once we have our ESP32 board, we have to work on the software part. I use the Arduino IDE to program my ESP32 board. However, you can use any other IDE you want. If you decide to use Arduino IDE, be sure to import the right library and COM ports driver. You can check this tutorial.

As already introduced above, I use MQTT protocol and its publish/subscribe approach for the gate control. So, our ESP32 will connect to our Wi-Fi network and then to the MQTT broker, thus performing a subscription to one or more MQTT topics, which will allow use the control of the gate or door. As already stated, I used an ESP32 board, but even a 8266-based solution should work, however you must change some libraries.

Libraries and variables declaration

So, let's start with the needed libraries. We need many libraries, most of them comes with the ESP32 board installation, while others must be manually installed. Therefore, your sketch need the following libraries:

#include <WiFi.h>
#include <PubSubClient.h>
#include <Wire.h>
#include <HTTPClient.h>
#include <ESP32httpUpdate.h>
#include <TimeLib.h>
#include <ESP32Ping.h>

PubSubClient and ESP32Ping must be manually download. You can find them HERE and HERE. All the others library should already been installed.

After that, let's start with some variables declaration:

// Replace the next variables with your SSID/Password combination
const char* ssid = "xxx";
const char* password = "xxx";

//Firmware version for update
const int FW_VERSION = 3;

//Watch Dog Const
const int wdtTimeout = 100000; //time in ms to trigger the watchdog
hw_timer_t *timer = NULL;

// Add your MQTT Broker local (or global) IP address, example:
const char* mqtt_server = "192.168.178.51";

// IP to ping for Wi-Fi status checking
IPAddress ip (192, 168, 178, 1); // The remote ip to ping
bool pingResult;

// Define clients and variables
WiFiClient espClient;
PubSubClient client(espClient);
long lastMsg = 0;
char msg[50];
int value = 0;
long wifirssi;

// LED & Control Pin
const int ledPin = 2;
const int voltPin = 23;
const int voltPin2 = 22;

// Update Check
int realtime = 0;
int interval = 60;
int nxtcheck = 60;

Starting from the beginning, we have to define our Wi-Fi SSID and password variables, followed by our firmware version, which I'll discuss later. Then, there is the watchdog trigger time variables, our MQTT broker IP or Hostname, and finally the IP of our home network gateway (the central router), which is used to perform a ping test and check if the Wi-Fi connection is dead or alive.

Moving on, there is the Wi-Fi and MQTT client declaration, followed by many support variables for messages and Wi-Fi RSSI, which is useful for debug purpose. Finally, here we have the pin connected to the relay board definition, followed by the firmware update check support variables.

Setup and Wi-Fi function

Let's move to the setup function, which is used to setup the board at startup. As usual, the first option is used to define the serial port and its baud rate. Then Wi-Fi setup  and the check for update function are called, allowing the board to connect to the Wi-Fi network and check if new firmware release are available on the defined server.

// Board Init
void setup() {
Serial.begin(115200);
setup_wifi();
checkForUpdates();
client.setServer(mqtt_server, 1883);
client.setCallback(callback);
pinMode(ledPin, OUTPUT);
pinMode(voltPin, OUTPUT);
pinMode(voltPin2, OUTPUT);
digitalWrite(voltPin, HIGH);
digitalWrite(voltPin2, HIGH);

timer = timerBegin(0, 80, true); //timer 0, div 80
timerAttachInterrupt(timer, &resetModule, true); //attach callback
timerAlarmWrite(timer, wdtTimeout * 1000, false); //set time in us
timerAlarmEnable(timer); //enable interrupt
}

Going on, the MQTT client functions are called, followed by the pins definition and initialisation. Also, the two pins connected  to the relays board are set to HIGH. And  finally the watchdog timer is initiated.

Let's have a look to the Wi-Fi setup function, which perform the connection to our defined wireless network.

// WiFi setup
void setup_wifi() {
delay(10);
int trial = 0;
// We start by connecting to a WiFi network
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
trial = trial + 1;
if (trial == 120){
ESP.restart();
}
}
Serial.println(WiFi.localIP());
}

As visible, the function tries to connect to the defined SSID. If the device can't connect to it for several times, the board is rebooted. Once connected, the IP is printed on the serial console.

WatchDog, Check for Update and connection check

Let's see now the watchdog and OTA update function. I decided to implement them because, since the board is located in my garden, inside an IP67 box, it's not so easy access to it for maintenance. Thus, I need an emergency reboot tool - aka, watchdog-  in case something goes wrong. Also, I must have the option to update the code remotely, because if I'd like, for example, to control the gate trough Bluetooth (check HERE how Bluetooth can be used for IoT applications), I have to perform some code change an then install the new firmware on the board. Let's see how these stuffs are done.

The watchdog code is very simple, it's a function which checks the CPU built hardware timer and, if it is not fed before the time limit set at the beginning, it reboots the board, whatever it happens. 

//Watch Dog
void IRAM_ATTR resetModule() {
ets_printf("reboot\n");
esp_restart();
}

So, it must be fed before the timer triggers the reboot. To do this, let's see what's inside the Loop function:

// Looping function
void loop() {
// Get time
realtime = now();
// Check if is check update time
if (realtime >= nxtcheck){
pingResult = Ping.ping(ip);
// Check if still connected
if (pingResult) {
Serial.println("SUCCESS!");
timerWrite(timer, 0); //reset timer (feed watchdog)
} else {
Serial.println("FAILED!");
}
// get WiFi RSSi for debug
wifirssi = WiFi.RSSI();
char rssiString[16];
dtostrf(wifirssi, 1, 2, rssiString);
client.publish("esp32/statusgate2", rssiString);
// Check update
checkForUpdates();
nxtcheck = nxtcheck + interval;
}
// Check if client is still connected
if (!client.connected()) {
reconnect();
}
client.loop();
}

At the begin, we get the current timestamp, then we check if the time variable is greater or equal the the next check variable. If it is, many things are done.

First of all, a ping test is done, in order to check if our connection is still alive. If it is, we feed the watchdog timer. Then, we get the Wi-Fi RSSI value and we publish it to our debug MQTT topic, in order to evaluate the connection quality between the node and our Wi-Fi router.

Finally, we check if any update is available and then set the next check interval, which is actually fixed to 60 seconds. Well, let's dive into the check for update function.

// Check for new firmware update
void checkForUpdates()
{
String fwURL = "http://www.webhost.com/firmware/esp32/gate_opener";
String fwVersionURL = fwURL;
fwVersionURL.concat(".version");

Serial.println("Checking for updates at URL");

HTTPClient httpClient;
httpClient.begin(fwVersionURL);
int httpCode = httpClient.GET();
if(httpCode == 200) {
String newFWVersion = httpClient.getString();

int newVersion = newFWVersion.toInt();

if( newVersion > FW_VERSION ) {
Serial.println( "Update" );

String fwImageURL = fwURL;
fwImageURL.concat(".bin");
t_httpUpdate_return ret = ESPhttpUpdate.update(fwImageURL);

switch(ret) {
case HTTP_UPDATE_FAILED:
Serial.printf("HTTP_UPDATE_FAILD Error (%d): %s", ESPhttpUpdate.getLastError(), ESPhttpUpdate.getLastErrorString().c_str());
break;

case HTTP_UPDATE_NO_UPDATES:
Serial.println("HTTP_UPDATE_NO_UPDATES");
break;
}
}
else {
Serial.println("Already last version");
}
}
else {
Serial.print( "Firmware version check failed, got HTTP response code ");
Serial.println(httpCode);
}
httpClient.end();
}

 

In a very short way, this function checks at the defined URL the release version number placed inside a .version file. If it's greater than the one defined inside the sketch, then the compiled binary (.bin) is downloaded and then installed, thus performing a complete OTA update without connecting the board to a computer. So, when I have to update the code of my gates board, I simply put the the new compiled firmware on my server and then increase the number inside the .version file. Voilà!

MQTT topic check

Let's now see the key component of the ESp32 gate control system: the MQTT topics check and relays control. The function which perform this operation is the callback function, which is called in the board setup function. Let's dive into it.

// MQTT Client Callback
void callback(char* topic, byte* message, unsigned int length) {
Serial.print("Message arrived on topic: ");
Serial.print(topic);
Serial.print(". Message: ");
String messageTemp;

for (int i = 0; i < length; i++) {
Serial.print((char)message[i]);
messageTemp += (char)message[i];
}

// If a message is received on the topic esp32/output, you check if the message is either "on" or "off".
// Changes the output state according to the message
if (String(topic) == "esp32/opengate2") {
if(messageTemp == "on"){
digitalWrite(voltPin, LOW);
delay(400);
digitalWrite(voltPin, HIGH);
}
else if(messageTemp == "off"){
digitalWrite(voltPin, HIGH);
}
}

if (String(topic) == "esp32/opengate2partial") {
if(messageTemp == "on"){
digitalWrite(voltPin2, LOW);
delay(400);
digitalWrite(voltPin2, HIGH);
}
else if(messageTemp == "off"){
digitalWrite(voltPin2, HIGH);
}
}
}

So, as it is possible to see, the first operation which is performed is to print the received message and tis topic. Then, many IF statement check if the topic and the message are compatible with the built-in functions. In my case, since I have two relays, I also have two topics, thus two IF statements which checks the messages received on the subscribed topics.

Once the on message is received on one of the two topics, the pin related signal is set to LOW (by default it is HIGH) for 400 ms, allowing the gate control mechanism to receive the input and thus open or close the gate, depending on its status. After 400 ms, the pin is set again to HIGH. The same thing is done on the second MQTT topic, where a different pin status is changed.

MQTT Client broker connection

Finally, we have the MQTT client connection function, which ensure that our client is connected to the broker and subscribed to the described topics. As visible, there are some parameters that must be set. They are, the MQTT broker username and password, followed by the topics which we would like to subscribe.

// Reconnect Client to Broker if disconnected
void reconnect() {
// Loop until we're reconnected
while (!client.connected()) {
// Attempt to connect
if (client.connect("ESP32Gate2", "username", "password")) {
// Subscribe
client.subscribe("esp32/led2");
client.subscribe("esp32/opengate2");
client.subscribe("esp32/opengate2partial");
} else {
// Wait 5 seconds before retrying
delay(5000);
}
}
}

The function will try to connect to the broker and, if there are some problems, it will retry again after five seconds, until it is connected.

All the source code can be found HERE in my repository.

Hardware setup: connecting ESP32 with relay module and voltage converter

Let's start with the hardware setup. Before connecting our board with the gate control board, we have to connect together the three node components: voltage converter, ESP32 and relay module. The first step is to connect an input cable, made by many wires: one related to GND, one to VCC and one for each relay. This input cable will be connected to your gate/door control mechanism, so I suggest to chose a strong cable with at least one meter of length, depending also on the node location.

Once we have this input cable, GND and VCC cables must be connected to the voltage converter inputs. Also, the VCC wire is connected to the relay Normally Open input. Then, we have the relay output cable, which is the third wire inside the cable connected to your gate control mechanism. Of course, if you have many relays like in my setup, you will have many outputs wire, each one for each relay.

On the 5 volt side of the voltage converter, which shall be manually adjusted by turning the built-in regulation screw, we have to connect a GND and VCC wires, which will feed both the relays and the ESP32 boards, connecting them to the right input pins. Finally, we have to connect the control wires, which connect the ESP32 control pins with the relay board input pins, designated by the label IN2 and IN2.

A complete schematic of the performed wiring is visible below:

Before soldering all the wires and cables in the right way, you have to perform two operations:

1. Regulate the voltage converter through the built-in screw, in order to obtain a 5 volt output. Pay attention! Do this operation without any board connected to the voltage converter, otherwise you could burn them. Use a voltage tester to check the output voltage.
2. Before hardwiring the voltage converter to the ESP32, load the sketch on it, otherwise you could have some electrical issues by USB-powering your board with the voltage converter connected.

Finally, you can place all the component inside an IP67 box, with a small hole to allow the cable passage. I placed all the component inside a 100 x 100 x 85 mm IP67 box, over a thin wood layer in order to fix them with some screws. Below you can see the final result.

[gallery size="large" ids="714,713,712"]

Connecting the ESP32 with the gate or door automation mechanism

Here we are to the big step: connect our node to the gate or door opener. I will try to be as generic as possible, since there exist a pletora of automation mechanisms. Fortunately, they are all quite similar, even if there could be some differences in terms of wiring and ports. Technically speaking, what you have to do is to connect the VCC wire to the VCC port on the gate opener board, while the GND wire to the relative GND connector.

And then, depending on you gate automation mechanism, there are different possible connection for the signal wires. My sliding gates has four inputs port for different kind of control. There is a partial opening, a step by step opening, an open only port and a close only too. I connected the first relay signal wire to the partial open port, which open the gate just for a meter, allowing only people or bikes to pass thorough it.  The second one instead, has been connected to the step by step opener, which acts as follow:

1. if the gate is closed, it opens it;
2. if it is opening, it stops it;
3. if it is open, it closes it;
4. if it is blocked, due to statement two, it resume the opening or closing procedure.

So, with a single button, you have the control of all these states. Actually, I mounted the system on three gates and two garage doors and, despite being different brand and devices, they all had the same similar inputs ports .... so I assume it should be the same thing for many other devices around the world.

I picked-up a random gate control board on Google and I noticed it has almost the same input port as mine, even if it's a completely different brand. Looking at the image, it's almost clear that the GND wire must be connected to the port number 5, while the VCC to 6, then the step by step control wire must be connected to the port 12, while the partial open to 14.

If you can't find any scheme, check where your antenna receiver or keyboard inputs are connected, since there is a very high chance that's the gate open port. And here we have the final installation of one of my nodes.

Mobile App: how to control your gates and doors through your smartphone

And finally, here we are to the final step: the mobile control app. As I told at the beginning, there are many MQTT dashboard. I picked up this one, because it's very nice. So, let's see what we have to do to control our gate from the app. First of all, we have to setup the connection toward our MQTT broker, so we need the same credential used by the ESP32 board to connect to the MQTT broker in order to subscribe to the target topics.

Once you setup the broker connection, you can create your custom interface, with all the tiles and buttons you want. To do this, just press on the plus button and then chose the right kind of tiles (button, label, switch, etc). In this case, since the system behaviour is like a "push and release button", I create a button for each relay, in order to control their functions.

[gallery size="large" ids="724,725,726"]

Once you create a button, then you have to set its behaviour, specifying  the topic where to publish and the message to send. You can see an example of a button here below.

And this bring us to the end of this project.

Conclusion

I'm using this system since July 2020 and I have to say that it works very well. I also created a NODE-RED dashboard where I can see all data collected by in-house sensor and control al gates and garage doors, and I also integrated the system with Google Home, in order to control them using Google Assistant. But I will talk about it in the upcoming weeks.

All the source code of this project can be found HERE in my repository.

L'articolo How to use an ESP32 to open any automated gate or garage door with your smartphone proviene da Emanuele Pagliari.

In the last months I've often talk about Internet of Things communication protocols like Bluetooth, Wi-Fi, Narrow Band IoT and, of course, LoRaWAN, explaining and analysing how they works and which are they strengths and disadvantages, as detailed in the following article. Among them, one of the most interesting one is, of course, LoRaWAN, which allows Low Power Long Range communications for monitoring and sensing Internet of Things applications in a remote area. HERE you can learn how this protocol work, which are its limits and possible use cases, while HERE you can see my review of a LoRaWAN battery powered end node, which I used for many experiment and applications

Now the question is: how far can LoRaWAN and thus LoRa-based communications travel? Which is the LoRaWAN Line-of-Sight operating range? In this article I show a very simple but effective test that answer to this question, in particular for all these applications with direct visibility between the LoRa devices (for example with a gateway placed on a hill or over the roof of a tall building and nodes placed in the surrounding countryside).

Which is the LoRaWAN (and LoRa) Line-of-Sight operating range?

Since I live in a sub-urban area without nearby hills, in order to evaluate the maximum possible Line-of-Sight (so without obstacles in the middle) LoRaWAN range test I decided to install a LoRa-enabled development board (a TTGO T-Beam) on my quadcopter (a DJI Phantom 4 Professional) thus enabling a powerful testbed which rely on my drone (which is the LoRaWAN transmitting end node) and the existing LoRaWAN open network, in particular The Things Network (known as TTN).

The key idea behind the test is the following: keep the drone flying at about 100 meters height and observe how far the LoraWAN messages transmitted by the on-board TTGO T-Beam can travel, by observing the gateways location which can hear the messages. In order to do this, I set the TTGO T-Beam development board to send a message every ten seconds containing GPS latitude, longitude, altitude, number of satellites and HDOP, which is a parameter to determine the GPS accuracy. You can find the source code of this TTGO T-Beam implementation on the author's GitHub HERE.

Then, the data retrieved by the different LoRaWAN gateways together with TTN Mapper tool allow to determine the Line-of-Sight distance between each gateway and the flying drone, thus providing the LoRaWAN range test results. Finally, all the received packets and the relative distance from the quadcopter are plotted over the TTN Mapper map, as visible in the following paragraphs.

LoRaWAN range test: the setup

In detail, I used as aforementioned a DJI Phantom 4 Professional with a TTGO T-Beam LoRaWAN board installed under the frame, in particular in the back of the drone, keeping attention to avoid the contact between the antenna and the propellers. I decide to use the TTGO T-Beam board because it is a cheap and compact solution, based on a Semtech SX1276 LoRa modem (suitable for EU 868MHz LoRa channels frequency) together with a U-blox NEO-6M GPS module, an ESP32 Wi-Fi and Bluetooth Low Energy (BLE) System-on-Chip (SoC) and the full support to The Things Network. Also, the board is powered by a standard 3.7V 3500 mAh MR18650 Li-Ion battery, which keep the weight of the whole system under 100 grams, board and antenna included.

[gallery columns="2" size="large" ids="619,620"]

The test has been performed in a semi-urban environment with multiple low buildings, in the absence of mountains or hills. Then, the flight has been done during a cloudy day with almost no wind, an air humidity of about 80% and a temperature around 3°C. During the flight, the drone position has been almost fixed to the lift-off position, performing an ascending, hovering, and descending flight in the same place. The drone has reached a maximum altitude of about 109 meters, in order to respect the aviation regulators rules. The total flight lasted about 12 minutes and, during the hovering phase, the drone has been slowly rotate itself on the yaw axis.

On the communication side, as already discussed in the LoRaWAN detailed article, in order to fulfil LoRaWAN usage policy the LoRa-enabled board has been set to automatically send a LoRaWAN message every ten seconds with Spreading Factor set to seven, containing the updated GPS data (longitude, latitude, altitude, and HDOP). Finally, the endpoint application attached to the TTN's application server has been integrated with the TTN Mapper component, in order to decode the received messages' payload and plot the data over a map showing the LoRaWAN range test results.

LoRaWAN range test: the results

During the 12 minutes flight, 72 LoRaWAN messages have been sent from the TTGO T-Beam board mounted on the drone. Looking at the results on TTN Mapper, the messages have been received by 14 LoRaWAN gateways registered on TTN, therefore allowing to estimate the distances between them and the drone, together with the number of packets successfully received by each gateway and the percentage of correct packets reception. A map with the plotted results is visible as follows,  where messages received by TTN gateways are plotted on top of a TTN Mapper's map.

A more detailed results report instead, is available in the following table, where the number of packets correctly received, the distance and the relative average Received Signal Strength Index (RSSI) are also reported, allowing to better evaluate the possible LoRaWAN operating range achieved during this range test

Analysing the results, it is possible to say that LoRaWAN can achieve an operating range of several tens of kilometres in Line-of-Sight applications, since most of the gateways in this test were located between within a circular range with radius between 30 km and 60 km, with also a gateway located at 75 km over a hill. Despite the not-statistically meaningful results achieved, due to the very low amount of messages sent from the quadcopter and the unknown number of GWs active in the area, this preliminary evaluation shown the potential LoRaWAN operating range in a Line-of-Sight application.

Note: as you can see, there is a LoRaWAN gateway located at 3.9 kilometres which is performing like many others gateways located at 50 and more kilometres. Here is why: this nearby gateway is based on a Raspberry Pi plus a cheap LoRaWAN eight channel dev board which acts as LoRaWAN gateway, but unfortunately is located inside of a building at the fifth floor, that's why the RSSI is similar to others far away gateways. Poor RSSI is also due to the low antenna quality of this home-made gateway, which can't be compared to the high quality one installed on the other nearby outdoor gateways. 

Since the test has been done with the LoRa modem set to a Spreading Factor equal to seven, there should be more room for higher Spreading Factors, which allow signals to further travel, given the higher airtime and improved receiver sensitivity, as already detailed HERE. Even the average RSSI of some gateways suggest that the system could easily reach a greater distance, maybe also adopting an improved LoRa antenna on the TTGO T-beam transmitter board to gain some link budget in terms of dBm.

Conclusions

What a range! With this simple test it has been possible to show some interesting LoRaWAN operating range in a Line-of-Sight application, illustrating also the potential of LoRaWAN and thus all LoRa-based communications. Of course, in real use case scenario, like in a city or ground application, these range are difficult to reach. But, if you plan to install a gateway on a hill or on a tower, you should reach some interesting results, nothing like these ones but of course with several kilometres behind the two LoRa devices.

L'articolo LoRaWAN range test: a real Line of Sight Long Range test of LoRa communications proviene da Emanuele Pagliari.

It was December 2019 when I discovered a new interesting product by Heltec: the LoRaWAN Heltec CubeCell Capsule. At the time, I was fiddling with many LoRaWAN (what is LoRaWAN?) development boards, in particular the Pycom FyPy and LoPy 4, followed by the Heltec ESP32 Lora V2, which I used to create a single channel LoRaWAN gateway, as reported in THIS article, and many remote sensing applications using many ready-to-use Arduino IDE libraries. However, they were too power hungry and incomplete for the use case I had in mind at the time.

In fact, I was looking for something smaller, cheaper, Arduino IDE ready and suitable for an outdoor use case without buying any IP67 box or additional housing. Also, one of the main requirements was to find a solution with built-in battery charger and protection circuit, suitable to be used for solar-powered applications. My choice fell on the new LoRaWAN Heltec CubeCell Capsule because it met all my needs and because there were almost no second choice, at least at such low prices.

So, we are at the end of this crazy year, a year where many things happened and, among them, I had a positive experience with this product by Heltec. So I'd like to share with you my opinion about this product, its cons and pros, what can be improved and which are its use cases, since I could not find any decent review online. I hope it will help you too!

A year with the LoRaWAN Heltec CubeCell Capsule

Specifications and features

I don't wanna spend much time talking about the "numbers" of this development board, because you can easily find it online (HERE the official product page), but I just wanna share the main features that let me choose this solution for my application.

The Heltec CubeCell Capsule is based, as many other product of the same series, on the ASR6051 chip, which integrates a 24 MHz ARM Cortex M0+ Core and a SX1262 Lora modem, allowing the system to achieve an ultra low power consumption in deep sleep states (3.5 uA). It has 32 kB of internal flash memory plus 4kB of RAM, which is much lower then the ESP32 or ESP8266, but enough for remote sensing applications where you have to collect one ore more data through one or more sensors and then send them to your application server through LoRaWAN communication protocol.

It is fully compliant with LoRaWAN specifications, so it can be used as Class A or C device (you can check the difference between LoRaWAN device classes HERE) and it has a built-in battery charger module. That means that if you plan to use it with a battery and a solar panel (and, given the specs, it is the perfect use case), you won't need an external battery charger module. You only have to connect the wires coming from the solar panel to the two inputs on the development board. The same can be said about the battery, since there are two ready to use soldering pads on the board. There is also a battery protection circuit, so if your LiPo goes under the nominal voltage of 3.3 Volt, the board will shut off itself until the battery voltage returns above the minimum threshold.

The LoRaWAN Heltec CubeCell Capsule comes with a small size in a nice chassis made of durable plastic. The company says that it's an IP65 chassis (for the full closed one), which makes it suitable for many outdoor applications, of course not under direct rain. Its size is really small, for comparison, its diameter is about 2 cm, almost the same size of a 1.5 litre Coke bottle cap, while its height is between 5 and 6 cm with both the lateral shielding. They can be removed in order to access to real development board and the inputs.

Under the hood you can find a tiny 80 mAh battery (you have to purchase it on the Heltec store, they will solder it on the board, otherwise you can solder any battery on the two charging pads) and an RGB LED which is very useful for debug purposes, but of course you can also switch it OFF to reduce power consumption and an integrated copper antenna. On the other side, there are the inputs pins and two buttons: the BOOT button and RESET button.

[gallery size="large" ids="595,598,593"]

To flash and program the Heltec CubeCell Capsule you'll need the "programming bracket", which connects with the pins in the lower side and and offer a built-in microUSB and buttons to work and program on the development board in an easy way. It costs about three dollars, but I think that you can flash the board with a common USB-to-serial adapter by manually wiring the inputs, but, if like me your going to use many of these boars, I strongly suggest you to buy the "programming bracket". The board has 20 useful pins, with some typical applications (TX, RX, GND, 3 Volt power, SCL, SDA, solar panel input, etc, see the pinout diagram below), so only some of them can really be used for your applications. Given the small memory size and board type, they should be enough, since you'll probably going to use it for a couple of sensors. In the picture above, I plugged-in a Bosch BME280 pressure, humidity and temperature sensor, which I found to be enough reliable for this kind of applications.

The overall build quality is quite good. The plastics are really solid, the dimensions are very compact and board is complete, since it has all we need for remote sensing applications.

The software part

As almost any development board for this kind of applications, even the LoRaWAN Heltec CubeCell Capsule comes with fully Arduino IDE support, making the deploy of your applications faster and easier on the Arduino IDE. You can easily find all the installation guide on the official repository, with many ready-to-use usage example.

The libraries installation is almost the same as many other development boards, you only have to install Arduino IDE and then install the chipset libraries using the Arduino IDE Board Manager functionality, as shown in this tutorial. Otherwise, you can use Git and download the libraries into the Arduino IDE folder. Whatever you choose, you can easily find the step by step guide on the official repository linked above.

Let's talk a bit about the example available. You can check them on the online repository or, once you have installed it, directly inside your Arduino IDE. Among them, there are some simple and easy to understand example which illustrates how to setup a LoRaWAN connection between the Heltec CubeCell Capsule and the LoRaWAN network. Some of them also, show advanced capabilities with LoRaWAN network, allowing more complex applications with sensors and broadcasting functionalities.

Of course, you can also flash the AT example and use the development board with AT commands on the serial connection, in order to perform live tests on LoRaWAN or even Lora, since the board can also be used for simple Lora communications. In fact, there are many Lora basic examples which show how to use the board for Lora applications.

Last but not least, there are also many useful example to fiddle with on-board interfaces and features. For example, since the board has built-in battery pads, it is possible to detect the battery voltage and send it through LoRaWAN to your application server, in order to detect if the battery is charging or not during daylight. There also low power wakeup example, RGB LED examples and many others, providing to new users a good starting point with many simple and easy to understand examples.

The board also supports some interesting features, like the Adaptive Data Rate (ADR), which automatically changes the Data Rata of the LoRaWAN communication, thus the Spreading Factor. Then, it is possible to set Confirmed or Unconfirmed Uplink mode (I strongly suggest Unconfirmed mode), which enables or disables a downlink ACK message from the gateway  for each uplink message. You can of course join the LoRaWAN network through OTAA or ABP authentications and finally you can choose between different debug levels.

By default you can't lock the modem on a single uplink channel, but, editing the original libraries, you can manually chose the channel you prefer and even the Spreading factor, of course, which is changed by changing the Data Rate parameter.

Useful links

• Official LoRaWAN Heltec CubeCell Capsule product page: HERE 
• Official Arduino IDE libraries and example: HERE
• Arduino IDE CubeCell installation instructions: HERE
• Where to buy: HERE
• LoRaWAN Heltec CubeCell Capsule pinout: HERE

How does it work after a year of use?

One year has not passed yet but ... I'm pretty sure it gonna last at least until 2021. So, here my conclusion, pros and cons of this development board. First of all it has been very easy to program, since the examples provide a nice starting point to build over. I'm not a skilled programmer, but I could easily create my remote sensing node with some of the examples code and some own code. I decided to use a BME280 sensor because it has a pressure, humidity and temperature sensor all in the same package, allowing a very small and low power sensing node.

Battery life and behaviour

I decided also to collect the battery level data, in order to know remotely if something is going wrong or not, and also to study and analyse how a such tiny 80 mAh battery can survive to completely different weathers, since it has been exposed to temperature between -10°C and +40°C in this year of use. I have to say that the battery is the weakest point of this device, but ..... it depends on your use case. I can tell you that at the beginning of the remote sensing project, the LoRaWAN Heltec CubeCell has been placed at about one kilometre from my LoRaWAN gateway, so Spreading Factor 7 was completely enough to get my data. With this setup, I could reach a battery life of more than a week without any solar panel and with a message interval of five minutes, so about 400 messages a day with a payload size of 31 bytes (13 bytes of LoraWAN header plus my data).

After a month of testing, I decided to install a small solar panel, which let the real remote sensing node adventure begin. Therefore, with a 1 Watt 6 Volt solar panel, the tiny integrated battery could receive enough power to recover in a couple of hours under direct sunlight, allowing a fully autonomous remote node with some spare days of battery life during cloudy days. So, it has been a real success. However, late on last September 2020, I decide to move the node at about 2 kilometre away from my gateway, thus increasing the Spreading Factor to 9 in order to overcome the obstacles between the node and my house.

This, of course, increased the energy consumption of the node, given the higher symbol time of SF9 (you can check what is Spreading factor and its consequences HERE). Therefore, battery life went from a week at SF7 with a message every five minutes, to a couple of days with SF9 and the same time interval. But ... Autumn was coming, which means less sunlight, less energy, cold weather and foggy/cloudy days.

Unfortunately, the first cold nights in late October together with more than a week of heavy rain and foggy days, killed my sensing node battery life down to about 12 hours. In fact, the board could wake-up with the early morning sun (6-7 AM), charge the battery up to 4.2 Volt and slowly die to 3.3 Volt at about 10-11 PM, providing only daylight data. This is of course related to the tiny battery, which could not survive the continuous charge and discharge cycles for such amount of time (about 10 months).

So, at the beginning of November 2020 I decided to purchase a bigger 1000 mAh battery and connect it to the Heltec CubeCell Capsule. Of course, I have to modify a little the chassis, because the battery could not fit inside the casing. I made a small hole in the white component of the casing in order to let the two battery wire came out. Then I soldered them to the battery and fixed it to the CubeCell with some electrical tape. A bad looking solution but it solved my battery problem. I will see how many months this battery will last.

Operating range and RSSI

I thing that I liked a lot of this LoRaWAN Heltec CubeCell Capsule is that, despite the small integrated antenna, I could easily reach a good operating range. It's always difficult to talk about operating ranges, because it depends on many factors. First of all, your environment (urban environment, a hill, a forest, a city or countryside), then your gateway solution (in my case a Single Channel LoRaWAN gateway based on a cheap ESP32 dev board) and then your node positioning (over a roof, in a field, in building, etc). In my case, as I told before, at the beginning I placed it at about one kilometre from the gateway in a sub-urban environment with just a few houses and trees in the middle, so no hills, mountains or obstacles between the gateway and the node. The node has been placed inside a plastic solar shielding housing at two meters from the ground.

With SF7 I was able to receive messages with a Received signal strength indication (RSSI) of about -115 dBm, a bit higher than the minimum threshold of -120 dBm of SF7. 99%+ of the messages were successfully received in a week of tests, with just a couple of messages lost during a rainy day. For comparison, my Heltec LoRa V2 board with an external antenna, placed in the same place could obtain a better RSSI of about -111 dBm, on average. Anyway, this is a very good result for such a small device with an integrated antenna.

With SF9 I could reach about 2 kilometres operating range, with a typical RSSI of about -119 dBm and, of course, an higher gateway sensitivity. In this case I have to say that 100% of the messages have been received in a week of test, while, at the same distance, with SF7 only 80% of the packets could be received. Unfortunately I haven't performed any test at SF12 and higher distances, but i believe that it is possible to easily reach an operating range between 3 and 5 kilometres with such Spreading Factor. I also believe that in a obstacle free environment with a better gateway than mine, the operating range could further be increased.

Closing thoughts, I suggest you to keep this device between one and three kilometres of distance between your gateway, in order to use the faster and low power consumption SF7. Of course, if you have many lost messages, you could switch to SF9 or even SF12, but they are much power hungry given their higher symbol time, thus limiting your daily network usage. Anyway, for such device, the operating range are quite good.

Housing resistance and software upgrade

I placed the capsule inside a solar shield back in late January 2020, and I removed from in early November 2020 to change the battery, as told before and, of course, I checked all the components in order to detects some possible rust or dust inside the case, but I did not find anything, which means that the casing of the capsule works quite well, protecting the board from the humidity and corrosion. Even the more exposed pins didn't show any rust sign, which a very good news. Obviously, some spiders got inside the lower part of the Heltec CubeCell Capsule, but that's a common problem.

About the software evolution, I have to say that in the last year many updates have been released, as visible on the repository activity. I don't what have been improved, but the solution is still an active project, since the repo is well active and many new products based on the same chip has been release in the least months.

Conclusion and recap

For about 15 bucks, I found the LoRaWAN Heltec CubeCell Capsule a good and reliable solutions for some remote sensing projects. Ok, I have to replace the battery, but that was predictable, since the original one was really small and calibrated for a lighter use of the device, but the board had no issues in all this months. I think that I will use it again for other similar projects, because it's a complete and ready-to-use solution, given its features and also the pletora of example available, which makes the programming of this board simple, easy and even funny. of course it's not perfect, but still a good solution for the price.

Pros

• Fully LoRaWAN Class A & C compliant;
• Built-in solar pins and battery charger;
• Built-in battery pads;
• Small size;
• Many example and updated libraries for Arduino IDE;
• Good build quality and housing;
• Cheap.

Cons

• Only small batteries fit inside the housing;
• Need a "programming bracket" to easily program it;
• Average operating ranges;
• No external antenna connector;
• Low memory and useful pins.

L'articolo LoRaWAN Heltec CubeCell Capsule: my review after almost a year of use proviene da Emanuele Pagliari.

Among the main Internet of Things Wireless communication protocols discussed in this article, the most used for low power and short range communication is Bluetooth Low Energy (BLE), given its high efficiency and radio equipment low cost. Of course, it has many limitations in terms of data rate and operating range, but it is enough for many Wireless Sensors Networks built inside a small building like a flat or a greenhouse, or in an open field, like a garden.

Today we're going to see how Bluetooth Low Energy works and how we can use it for Internet of Things applications, analysing two ways to use BLE wireless communication protocol to retrieve data from many IoT sensing nodes.

We will also see the strengths and weaknesses of this protocol, both compared with Bluetooth Classic and even with the powerful and faster Wi-Fi. A shortest description of Wi-Fi and  other Internet of Things wireless communication protocols can be seen HERE.

What is Bluetooth Low Energy and how does it work?

Bluetooth low Energy is a short range communication protocol that can be used to create Wireless Personal Area Networks (WPANs), which typically have a range between few meters up to 20 meters in Line-of-Sight (LoS) applications. So, looking at the following graph, we're looking at the lower right corner. One of the most common protocol used for this kind of Wireless network is Bluetooth, which can be used in the Classic variant for synchronous data transfer operations, or Bluetooth Low Energy, which is often used for low power multi-nodes wireless sensors networks and indoor localisation through beacons, since it has a good range and a very low power consumption.

Bluetooth Classic vs Bluetooth Low Energy: use cases and physical layer differences

As mentioned before, Bluetooth Classic is the original standard version, which has been initially released back in 1999. The latest version of the Bluetooth Classic standard is called 5.2, and, like the previous, operates on 79 channels with a 1 MHz bandwidth and a 1 MHz spacing on the 2.4 GHz ISM band, which are defined as shown below.

Bluetooth Low Energy is available since the version 4.0 of the protocol, and, as name suggests, BLE sacrifices performance and operating range in favour of lower power consumption. Compared to the Classic variant, BLE operates in the same free ISM band of 2.4 GHz and uses the same Gaussian Frequency Shift Keying (GFSK) modulation and Frequency Hopping Spread Spectrum (FHSS) techniques to minimize the destructive effects of fading and channel noise from Wi-Fi networks operating on the same band (below you can see the Wi-Fi 2.4 GHz channels spectrum).

In contrast to Bluetooth Classic, the BLE variant uses only 40 channels in the 2.4 GHz band, with a channel spacing that goes from 1 to 2 MHz. Between the 40 channels provided by the BLE, three of them are reserved exclusively for the Advertising process, namely channels 37, 38 and 39. The remaining 37 channels, instead, are used for data transfer between Master and Slave. These three Advertising channels are located at the endpoints and in the middle of the 2.4 GHz band, in order to limit the interference with Wi-Fi networks, as visible below.

Typically, Bluetooth Classic is mainly used for all that types of connections that require continuous synchronisation (Synchronous Connection Oriented Link), such as, for example, a connection between a smartphone and a Bluetooth speaker, a pair of headsets, or during a real data transfer between two neighbour smartphones. BLE, instead, is mostly used for wearables, smart devices and cheap battery powered environmental sensors, since these devices communicate their data periodically to a central master that acts as gateway, so they perform asynchronous data communications (Asynchronous Connection Less Link) to one or more master nodes.

Bluetooth Classic vs Bluetooth Low Energy: data rates, power consumption and operating ranges

Given the two protocols different use cases, they have significantly different power consumption, thus operating ranges. Bluetooth Classic transmission speed (bitrate) depends on the type of Phase Shift Keying modulation adopted but, typically, the theoretical transfer rate goes from 1 Mbps up to 3 Mbps (with EDR). Bluetooth Low Energy instead, can reach a maximum data rate of about 2 Mbps with fifth version of the protocol.

The operating range of Bluetooth Classic technology depends on the power radiated by the antenna. Based on the latter factor, it is possible to identify three main power classes for Bluetooth Classic devices, which are shown in the following table. Generally, devices operating with Bluetooth Classic protocol belongs to Class 2, so they have a typical range up to 20 m in an open field.

Regarding Bluetooth low Energy, as opposed to Bluetooth Classic, there are no power classes, but an operating range between two extremes, i.e. the maximum and minimum power values at the transmitter output. These limits are respectively 10 mW and 0.01 mW, so they are much lower than the Bluetooth Classic devices. Unlike the latter, the operating range also decreases, ranging from a minimum of one meter to a maximum around 10 meters in an open field.

Bluetooth packets structures

BLE works slightly differently at higher protocol levels compared to Bluetooth Classic. In fact, BLE not only has less channels than Bluetooth Classic, but also its packets are smaller. Bluetooth Classic has different types of packets, depending on the type of logic transport used for the transmission. They typically are: Asynchronous Connection Less (ACL), Synchronous Connection Oriented (SCO) and enhanced Synchronous Connection Oriented (eSCO). However, a generic Bluetooth Classic packet has is composed of three fields: access code (68 or 72 bits), header (54 bits) and payload (from 0 to 2745 bits). Its structure is shown below.

The access code identify all packets broadcasted in the same physical channel, which will have the same value. The header instead, is a series of 54 bits that contains all the information about the connection control, to the logical transport address - used to identify the active slave of a piconet -, followed by the type of package used. Finally the payload, which contains the real data transported. In addition, there is also a second type of packet related to EDR (Enhanced Data Rate) variant of Bluetooth, which, unlike the first type, provides some additional control systems to take advantage of two simultaneous different modulations used for the transmission of the same package.

BLE packets are, as told before, smaller (in particular the advertising packets) in order to minimize antenna activation time for transmission and reception and, therefore, the power consumption. The structure of the typical BLE package is visible below and, as you can see, there are four parts: Preamble (8 bits), Access Address (32 bits), Protocol Data Unit (between 2 and 39 bytes) and a final Cyclic Redundancy Check (24 bits).

The Preamble consists of 8 bits and is used by the receiver for synchronisation. It is also useful to identify which packages are broadcasted on Advertising channels and in the Data channels. The Access Address  consists of 32 bits and has different values depending on the channel type: advertising or data channels. For example, the Access Address of any package transmitted on the Advertising channels has a hexadecimal value equal to 8E89BED6. The Protocol Data Unit (PDU) field has a variable length (from 2 to 39 bytes) and has a different structure depending on the type of the target channel (Data or Advertising). For Advertising channels, the PDU is composed by two fields: a 2 bytes Header and a 0 to 37 bytes Payload field. For Data channels instead, PDU structure has three components: a 2 bytes Header and a Payload with a size of up to 255 bytes, which could include a MIC check field.

Address mechanism: something that you must know before developing on BLE

Bluetooth low Energy has many different kinds of addresses. Typically, the broadcasted Bluetooth address of a device corresponds to the MAC Address of the radio equipment. However, many devices, specially smartphones, by default use a random type address, which, of course, is not the real MAC Address of the device. So, looking at the Bluetooth specification, there are many kind of addresses. The two main categories are: Public and Random addresses. Typically, wearables and cheap devices comes with a Public address, which is the bare MAC address of the device radio. Therefore, it will never change. However, as told before, complex devices like smartphones, smartwatches and even computers, typically use a Random address to improve the privacy and security, which can be categorised in two classes: Static and Private. Moreover, Private addresses con be classified into Resolvable and Non-resolvable. You can look at the following scheme to better understand the addresses categorisation.

As anticipated, Android smartphones use Private Resolvable addresses, which exploit a mathematical algorithm for the generation of a resolution key, which is periodically shared whit paired devices. The periodically shared is the reason why, while the address periodically changes, the devices already paired can still resolve it and make the connection without having to repeat the authentication steps.

Any kind of address consists of 48 bits. In Public type addresses, the first 24 bits are assigned by the manufacturer, while the second group of 24 bits is the the ID of the manufacturer itself. Random addresses instead, are randomly generated and, among them, those of Resolvable type are divided into two parts, the hash and the prand, while those of type Non-Resolvable contain 46 totally random bits. The solvability feature
is indicated by the 47 bit, which identifies a Non-Resolvable (value 0) or a Resolvable address (value 1), as visible below.

Some examples of Bluetooth Low Energy Advertising Packet Data Units (PDUs)

Advertising packets can have different types of PDUs, depending on the device interaction needed (broadcasting, advertising, connection, active or passive scan). Bluetooth Low Energy interaction depends on their operating state, but we will discuss about it later, in the following section. back to the PDUs, until Bluetooth 4.2 there were only seven PDUs, while with Bluetooth 5.0 - and above - additional PDUs (Extended PDU) have been added, thanks to the introduction of the concept of Secondary Advertising channels. I'll discuss only the primary PDUs, since they are the key PDUs for BLE functioning.

PDU ADV_IND

The ADV_IND PDU is used for indirect advertising events that include the possibility of connection and scanning by all other nodes listening. It is composed by the AdvA field, which specify the address of the Advertiser and if it is random or public. Then, there is an AdvData field, which contains the advertised data. Here below you can see the PDU structure.

The Advertising events of this PDU can end in three ways:

1. when a listening device reply with a CONNECT_IND PDU type, in case it is a initialiser node, thus establishing a connection with the Advertiser node;
2. when a listening device reply with a SCAN_REQ PDU type, in the case it is an active scanner. After that, the Advertiser device will send a SCAN_RSP PDU response to the scanner, thus leading to the end of the event.
3. if any device answer to the advertiser, the event ends after the PDU has been broadcasted on all the three Advertising channels.

PDU ADV_DIRECT_IND

The ADV_DIRECT_IND PDU type is used for Advertising events with the purpose to establish a connection to a device whose address is already known in advance. The AdvA field specify address of the Advertiser, while the TargetA contains the address of the target device.

The Advertising events of this PDU end in two ways:

1. when the target device, which is listening, reply with a CONNECT_IND PDU type, passing therefore to the connection state;
2. if the Advertiser does not receive any response from other devices, the node continues sending the PDU on the remaining channels, until the maximum time is reached.

PDU ADV_SCAN_IND

The ADV_SCAN_IND PDU type is used by Advertising events for the all these devices in the scanning state, which don't allow any connection. The AdvA field specify address of the Advertiser, while the AdvData contains any information or data that the advertiser wants to transmit to the scanners.

The Advertising events of this PDU end in two ways:

1. when the active scanner devices respond with a SCAN_REQ PDU type. Then the Advertiser will reply with a SCAN_RSP PDU type. Subsequently, the ADV_SCAN_IND PDU is also sent the other advertising channels.
2. when nobody replies on all the three primary Advertising channels, the event ends.

ADV_NONCONN_IND PDU

The ADV_NONCONN_IND PDU type is used for Advertising events that do not allow neither the connection nor the active scanning by other nodes, since during the
this type of events the Advertiser does not listen on the channels. The AdvA field specify address of the Advertiser, while the AdvData contains any information or data that the advertiser wants to transmit to the scanners.

It is a type of PDU used to perform non direct broadcasting. The events characterised by this PDU end after sending the package on all three Advertising channels.

Others PDU and Extended PDU

Among the other types of PDUs, it is necessary to mention the SCAN_REQ and SCAN_RSP PDUs used in the scan events. Therefore, there is also a CONNECT_IND PDU, which is used to initialise a data transfer over Data Channels, thus the real connection between two devices. Finally, there is an additional ADV_EXT_IND PDU, which has been introduced with Bluetooth 5.0 and it's used to switch from the primary Advertising channels (37, 38 and 39) to the secondary ones, i.e. the Data Channel, normally intended only for data exchange in Bluetooth 4.2. On Secondary Advertising channels there are also additional PDUs, all characterised by the prefix AUX_ which, however, will not be explored in this article.

The key of Bluetooth Low Energy efficiency for Internet of Things applications

The key of BLE efficiency is certainly the lower number of channels (40 compared to 79 defined for the Bluetooth Classic), of which only three, those of Advertising, are actually used for advertising, scanning and establishing a connection between two nodes. This, combined with smaller packets size and a fair low transmitting power, makes possible to reduce the time in which the antenna and all the other radio equipment remain active during transmission or reception, allowing more stand-by phases and therefore reduced power consumption. All these stuffs together make Bluetooth low Energy suitable for different Internet of things applications where many IoT battery powered sensing nodes need to communicate their data to a central gateway using a wireless communication protocol. As already said, BLE is the mostly used protocols for wearables, smart devices and cheap battery powered environmental sensors, which communicate their data periodically to a central master that acts as gateway, assuring good battery life in a tiny format. However, there are many other features that makes BLE Internet of Things friendly and efficient. Let's see them in the following paragraphs.

Generic Attribute Profile (GATT): Services and Characteristics for IoT communications

Another key feature of Bluetooth Low Energy that has been partially taken and improved from the Classic variant in order to reach a more efficient resource utilisation, is the Generic Attribute Profile (GATT), which establishes how to exchange profiles and data over an already established BLE connection between one peripheral (GATT Server) and one central device (GATT Client). GATT uses of a generic data protocol called ATTribute Protocol (ATT), which is used to store Services, Characteristics and related data in a lookup table using 16-bit IDs for each entry. GATT can handle only one connection at time, thus when a peripheral connects to a central device, the last one will immediately stop advertising itself, so that other devices will no longer be able to see it or connect to it until the existing connection is interrupted. A behaviour that must be know when dealing on wireless sensor networks with multiple peripheral devices that must connect and exchange data with one central device, a recurrent scenario in many Internet of Things applications which involve the use of Bluetooth Low Energy. The connection procedure between GATT server and GATT client is shown below and, when there is a very large amount of devices, a smart multiple access system should be implemented, in order to optimize the GATT server access.

Once a client is connected to a server, Profile, Services and Characteristics manage the data exchange process between the two nodes. A Profile is simply a pre-defined collection of Services that has been defined by the Bluetooth SIG. A Profile can combines multiple Services, which depends on the device nature. A Service instead, is used to separate data into one or more Characteristics. Each Service distinguishes itself from other services with a unique numeric ID called a UUID, which can be either 16-bit or 128-bit. As Profiles, also Services UUID are defined by Bluetooth Developer Portal, however, users can easily create custom service for specific purpose. The last elements of GATT are the Characteristics, which encapsulates a single data points that could be an array of data, given its maximum size of 512 bytes. As Services, also Characteristic identifies itself though a 16-bit or 128-bit UUID. The entire GATT structure can be seen in the following picture. So, every time that a GATT Client connects to a GATT Server, it writes or reads data over one or more Characteristics. Therefore, Characteristics are a key point of any BLE connection and one of the possible ways to use BLE for Internet of Things applications where many BLE sensing nodes have to communicate their data to a central gateway.

A well defined and limited number of active status

Bluetooth Low Energy owes its efficiency to well defined status, which defines the behaviour of a BLE device during many operations. In fact, there are five Link Layer states: Advertising, Standby, Initiating, Scanning and Connection. A flow diagram of each status possible transaction can be seen here below.

In the Standby state, which is the state where any BLE device spend most of the time, the Bluetooth radio is practically turned off. When it is in this state, the node does not establish any connection, because does not transmit any packets and does not even listen to them. A device in Standby can switch to one of the three active states as a result of a command received from the Host Controller Interface (HCI). In the Connection status, the Data channels are used for the effective exchange of data packets between the Master and the Slave. This phase is always preceded by an event of Advertising or the state of Initiating, necessary for the establishment of the connection between two devices. Following a command received from the Host Controller Interface (HCI), the Connection status can switch back to the Standby status.

The Advertising status is the fundamental state of Bluetooth Low Energy, since it leads to the establishment of a connection, to the discovery of new nearby devices and other operations. When a node is in the Advertising state, during a certain time interval, defined as an Advertising event, the device transmits Advertising Bluetooth packets on the three dedicated channels. The transmit and listening time for each packet must be less or equal to 10 milliseconds for each Advertising channel. Each Advertising event, therefore, has a variable duration but it must be shorter than 30 milliseconds. The time between two Advertising events can be defined as advEvent, and corresponds to the sum of advInterval and advDelay time intervals. The advInterval identifies a multiple of 0.625 milliseconds and goes from a minimum of 20 milliseconds up to a maximum of 10,485 seconds, while the advDelay identifies a random value between 0 and 10 milliseconds generated for each Advertising event. The advDelay has been introduced to minimize the risk of packets collision of other nearby devices.

The Scanning status is used to detect nearby Advertising devices in order to get more information about them without establishing a real connection. There are two types of scanning: passive scanning and active scanning.

• Passive Scanning: when a Bluetooth Low Energy node is in passive scan, it does not transmit any package on the Advertising channels but it listen for incoming Advertising packets for  a certain time window, called scanWindow. The scan process can be repeated after a certain interval of time, defined by the scanInterval, with a duration equal to or less than the scanWindow.
• Active Scanning: unlike the Passive Scanning, during an Active Scan some packets are sent to the Advertising nodes which broadcast them self with ADV_IND or ADV_SCAN_IND Packet Data Units, in order to request additional information. After the receipt of one of these PDU, the scanner device can transmit SCAN_REQ type PDUs to the advertiser in order to obtain more information. To minimize the
  collision risk, the scanner implements a backoff system, characterised by backoffCount and upperLimit variables, with the aim to reduce the number of SCAN_REQs transmitted in case of no response. After sending the request, the scanner listen on the advertising channels for a SCAN_RSP PDU: if it is not received, the backoff mechanism handles the possible retransmission and the waiting time. An example of active scanning is shown below.

Finally, the is the Initiating state, where the device keeps listening on the Advertising channels for the time interval defined by the scanWindow variable. The listening operation is repeated after a certain interval of time, defined by the scanInterval variable. The initialisation state is therefore very similar to a passive scanning, with the difference that when the device receives a packet with a ADV_IND or ADV_DIRECT_IND type PDU, it can reply - if the advertiser's address is in whitelist - with a CONNECT_IND type PDU, making the node switch to Connection status and ending the Advertising event, as shown in the following example.

Wireless Mesh Networks to reach an higher operating range

The biggest drawback of BLE technology is its limited operating range, which, in a real environment with walls, obstacles and interfering 2.4 GHz Wi-Fi networks, barely reach a two to five meters operating range. A good range for small wireless sensors networks, like in a small flat or greenhouse, but very limited for IoT applications inside medium sized houses and buildings. Depending on the applications, there are two solutions:

• the simplest one is to place more grid powered devices (aka, BLE servers or namely gateways) inside the building in order to reach a full coverage, like if you are working with Wi-Fi access points and you wanna cover an entire building using many access points placed in the right places. It's a very simple and effective solution which fits well for some kind of applications, where, for example, you have a good number of battery powered BLE sensing nodes and the possibility (both economically and in terms of space/networking configuration) to place more gateways. The main drawback is an higher deployment cost to reach a perfect coverage, because, whether you like it or not, there will always be one or more sensing nodes placed in a corner or near the boundaries of your network, which imply a meticulous placement of your gateways;
• the complex but cheaper solution is to implement a BLE Wireless Mesh Network, thus allowing to any sensing node to reach your central gateway in a smart and efficient way. Wireless Mesh Network is cooperative network topology consisting of several intelligent nodes that act as receiver, transmitter and packets forwarder towards the recipient node, allowing to connect between them devices that cannot be reached in a direct way but only through multi-hops communications. With Bluetooth 4.1 standard, it has been introduced the possibility to make a device both acts as Master and Slave, thus allowing a possible Bluetooth node to act as an intermediary in a communication between two other devices. This could significantly extend the operational range of BLE networks, allowing to cover an entire building. However, this solution is a bit complex to implement even if Bluetooth 5.0 has introduced some new useful functions dedicated to Wireless Mesh Networks. Also, nodes acting as packets forwarder have an higher energy consumption, since they have to spent more time listening for incoming packets, limiting the battery life of constrained devices.

How can we use it for Internet of Things applications?

Well, now that you learnt how Bluetooth Low Energy, we can see how effectively use it for our wireless sensors networks or, more in general, for different kind of Internet of Things applications. As you should have understood in the previous section, there are two possible ways to use it for data communication between a Master node (e.g., a BLE to Internet gateway) and a Slave device (e.g., a battery powered sensing node):

• Implementation of a GATT server and usage of Services and Characteristics to transfer data in both direction between two devices (client and server);
• Usage of Advertising and Scanning status for mono-directional communication between one or more nodes.

There are many difference between these two possible ways. The first one needs an already established connection between the two devices, so it requires some time, because the GATT server, which has the role of Master and defines one or more Services with one or more Characteristics, has to advertise itself in order to be found by the Slave node, which acts as client. Once the connection is achieved, the real data transfer on the Data channels can happen, allowing the client (the Slave node) to transfer a good amount of data in both directions by simply writing or reading on the desired Characteristic. However, there are two big drawbacks: first, as told before, the advertising, scanning, initiating and connection process takes some time (more than you could think), especially on low power devices which have limited computing capabilities, and, as I explained before, once a device is connected to a GATT server (which, in a IoT application, could be our gateway) other nearby sensing nodes can't find it (because it stops advertising itself), thus wasting power keeping scanning for it. This leads us to the second drawback: data can be exchanged only with one Slave device at time, which could be a problem for densely populated BLE networks, given the connection and disconnection times.

However, typically, battery powered sensing devices in a Wireless Sensor Network have a smaller amount of data to transmit in mono-directional way toward the BLE network gateway. Here it comes the second communication ways, which fits really well for these kind of applications, since the limited payload of the Advertising packets (27 useful bytes) is enough to transmit an identifier ID (if the BLE address is not enough) and many sensors data (you can play with the right variables to reduce and optimize the payload size). In this case, the gateway acts as Passive Scanner, which listens for incoming Advertising packets from many sensing nodes, retrieving their payload. In this way, it is also possible to collect data almost simultaneously from different slaves, since three advertising channels are available, making this solution suitable for high density BLE networks. Of course, the biggest drawback is the mono-directional communication type and the lower (almost null) security of the communication, since by default any encryption is active on advertising packets' payload. The latter problem could be partially bypassed applying an encryption to the payload, while the first one requires a role exchange between the Master and Slave to be overcome.

Well, these are the must-know things regarding Bluetooth Low Energy. Of course there are a lot more things left, but I believe that this article is a good starting point for BLE Internet of Things beginners.

L'articolo How does Bluetooth Low Energy work? An in-depth study for Internet of Things Wireless Sensors Networks proviene da Emanuele Pagliari.

Working with Internet of Things applications in 2020 almost surely means working with many Wireless communication protocols, based on different technologies. Nowadays, many home or industrial automation applications use Low Power and Long Range communication protocols to enable what we call Wireless Sensors Networks, which are the basis of the Internet of Things world.

However, there are many different Wireless communication protocols that can be used in these kind of applications. Which are the most suitable for a certain kind of application? Which are their characteristics and differences? How can these Internet of Things Wireless communication protocols be classified?

In these article I'll try to classify the main and most used Internet of Things Wireless communication protocols adopted in many modern applications.

Which are the most common Internet of Things Wireless communication protocols?

Among the different technologies available on the market to connect several devices for smart city, smart farming or industrial Internet of Things (IoT) applications from small to large range area Wireless Sensors Networks (WSNs), the main alternatives are Wi-Fi technology (IEEE 802.11 a/g/n/ac/ah), Bluetooth technology (IEEE 802.15.1), both Classic and Low Energy (BLE) variant, ZigBee technology (IEEE 802.15.4), LoRaWAN protocol and LTE-M, followed by Narrowband Internet of Things (NB-IoT) Protocol and the upcoming fifth cellular generation network (5G).

When dealing with large WSNs, it is common have to deal with wide-range wireless networks characterised by subnets with smaller ranges based on more energy-saving protocols, in order to ensure an adequate endurance even for battery-powered end-node devices. Thus, it is useful to classify the aforementioned protocols on their typical coverage range and applications use cases. Therefore, it is possible to divide them into three main classifications: Short Range Communication Protocols, Mid Range Communication Protocols and Long Range Communication Protocols. A brief comparison of the main characteristics of the aforementioned standards can  be seen in the following graph.

Short Range Internet of Things Wireless Communication Protocols

There are many short range communication protocols that can be used to create Wireless Personal Area Network (WPAN), which typically have a range between few meters up to 20 m in Line-of-Sight (LoS) applications. The most common protocol used for this kind of Wireless network is Bluetooth, which can be used in the Classic variant for synchronous data transfer operations, or BLE, which is often used for low power multi-nodes networks and indoor localisation through beacons, since its good range paired with a very low power consumption fits perfectly for asynchronous data communication between peripheral battery powered nodes and a central master node. Usually this kind of WPANs have a typical star topology, but when dealing with applications dedicated to environmental sensing and the IoT use cases, it is quite typical to use mesh Wireless networks, in order to increase the operating ranges. A short analysis of Bluetooth Classic and Low Energy variant is done below.

Bluetooth Classic Protocol - IEEE 802.15.1

Bluetooth Classic is mainly used for all that types of connections that require continuous synchronisation (Synchronous Connection Oriented Link), such as, for example, a connection between a smartphone and a Bluetooth speaker, a pair of headsets, or during a real data transfer between two neighbour smartphones. The latest version of the Bluetooth Classic standard, called 5.2, operates on 79 channels with a 1 MHz band and a 1 MHz spacing. It adopts Gaussian Frequency Shift Keying (GFSK) modulation, and uses the mechanism called Frequency Hopping Spread Spectrum (FHSS) to minimize the destructive effects of fading and channel noise from Wi-Fi networks operating within the same 2.4 GHz ISM band.

The transmission speed (bitrate) depends on the type of Phase Shift Keying modulation adopted from the standard. Typically, the theoretical transfer rate goes from 1 Mbps up to 3 Mbps, depending on the modulation variant used and the Bluetooth standard used. The operating range of Bluetooth Classic technology depends on the power radiated by the antenna. Generally, devices operating with Bluetooth Classic protocol belongs to Class 2, so they have a typical range up to 20 m in an open field.

Bluetooth Low Energy Protocol - IEEE 802.15.1

Bluetooth standard has also a Bluetooth Low Energy (BLE) variant, available since the version 4.0 of the protocol. As name suggests, BLE sacrifices performance and operating range in favour of lower power consumption. The considerable difference in the use of channel and protocol resources, has made it necessary to divide the equipment related to the two standards, giving rise to Dual-Mode chipsets, which are able to operate with both Bluetooth variants, and Single-Mode chipset, able to support only one of the two standards (at the manufacturer's discretion). As Bluetooth Classic, also BLE operates in the free ISM band of 2.4 GHz and uses the same modulations and FHSS technique, but it works differently at higher protocol levels. In contrast to Bluetooth Classic, the BLE variant uses only 40 channels in the 2.4 GHz band, with a channel spacing that goes from 1 to 2 MHz. Between the 40 channels provided by the BLE, three of them are reserved exclusively for the Advertising process, namely channels 37, 38 and 39. The remaining 37 channels, instead, are used for data transfer between Master and Slave.

As opposed to Bluetooth Classic, there are no power classes, but an operating range between two extremes, i.e. the maximum and minimum power values at the transmitter output. These limits are respectively 10 mW and 0.01 mW, so they are much lower than the Bluetooth Classic devices. Unlike the latter, the operating range also decreases, ranging from a minimum of one meter to a maximum around 10 m. This limited operating range can be considerably increased by using mesh network topology instead of the typical star topology.

The key of BLE efficiency is certainly the lower number of channels (40 compared to 79 defined for the Bluetooth Classic), of which only three, those of Advertising, are actually used for advertising, scanning and establishing a connection between two nodes. Also, compared to Bluetooth Classic, BLE packet are smaller. BLE is the mostly used protocols for wearables, smart devices and cheap battery powered environmental sensors, which can communicate their data periodically to a central master that acts as gateway, assuring good battery life in a tiny format.

For a detailed explanation of Bluetooth Low Energy protocol, its Internet of Things use cases and its limits, you can check my dedicated article.

Mid Range Internet of Things Wireless Communication Protocols

Mid range communication protocols can be used to create a Wireless Local Area Network (WLAN), which usually have a coverage between 10 to 100 m without any obstacles. However, using directional antennas can increase operating range up to hundreds of meters for some particular applications. Among many protocols, the mostly used are Wi-Fi IEEE 802.11 and ZigBee IEEE 802.15.4 protocols. While Wi-Fi has now become present in almost any smart device, ZigBee has achieved a relevant role for wide IoT WSNs with a wide range, such as entire buildings in industrial environments. However, even if Wi-Fi and Zig-Bee use the same carrier frequency of 2.4 GHz, they are completely different with distinct applications.

Wi-Fi Protocol - IEEE 802.11 a/b/g/n

The Wi-Fi term refers to a family of wireless standards related to IEEE 802.11 protocol, in particular, the most common and widely used versions are the Wi-Fi a/b/g/n and the last announced Wi-Fi 6. Wi-Fi uses two free ISM bands: 2.4 GHz and 5.8 GHz. However, mostly Internet of Things application use 2.4 GHz. given its higher operating range and properties, which enough appropriate to most IoT use cases. The Wi-Fi 2.4 GHz band uses 14 channels with a bandwidth of 22 MHz each and spacing of 5 MHz, but usually only the first 13 channels are usable in Europe.

Some of the main advantages of the Wi-Fi standard are the high diffusion and device integration, but, above all, the high transmission capacity (11-300 Mbit/s), low latency and the operating range, wide enough to cover small houses with a single central Access Point (AP), since it can easily reach 50 m of range with obstacles and walls. In a free open space environment, the operating coverage can go up to 100 m and more. However, the biggest draw back of Wi-Fi protocols is the high power consumption, which, for IoT applications, makes it suitable only for some particular use cases, like data transfers between gateways, nodes which can be powered from power grid or devices with high deep sleep times, such as my solar powered ESP8266-based weather station.

ZigBee Protocol - IEEE 802.15.4

ZigBee was developed in 2004 as an alternative to Wi-Fi and Bluetooth for low-power applications in the field of Wireless Mesh Networks (WMNs). Therefore, compared to Wi-Fi, it boasts extremely low power consumption and a very low bitrate (20-250 Kbit/s), too small for enhanced data transfers between multimedia devices but enough for IoT applications.

ZigBee nodes are characterised by a low power nature, that allow them to be easily battery powered for years, but also, their low power radio trans-receiver limits the operating range to a small range, usually between 10 to 20 m. Thus, ZigBee protocols is usually associated as an alternative to Bluetooth and Bluetooth Low Energy, given its power consumption efficiency, range and data rates, as shown in the comparison figure below.

Anyway, given the protocol mesh nature, a network of ZigBee devices can easily scale up to 100 and more meters range when many nodes are involved. However, it is decidedly less widespread than standards such as BLE and Wi-Fi, as a limited number of devices support this technology, which today remains mainly conned to the industrial sector. Also the license costs of ZigBee are slightly higher than BLE devices, another reason why this standard, although interesting, has not had a great response in customer-oriented applications as happened for the other two standards.

Long Range Internet of Things Wireless Communication Protocols

Long Range communication protocols are often used to create Low Power Wide Area Networks (LPWANs) with an operating range that goes from 300 m up to 10 km, but, using certain protocols that rely on existing mobile networks, it is possible to a create network with many nodes located at tens of kilometres from each others. Also, some protocols can be used for mobility applications, adding more possibilities and use cases. However, such wide networks could have different implementations costs that rely on the protocol used, which also depends on the applications and usage.

In fact, some protocols use existing mobile networks managed by operators, while others lean on an existing free open architecture network, managed by many community members such as companies and also users. The most common and used LPWANs has been analysed and characterised by their costs, characteristics, advantages and disadvantages in the following.

LoRaWAN Protocol

A detailed description of LoRaWAN protocol can be found in a dedicated article (you can find it HERE). However, here you can find a shorter description of this protocol. LoRaWAN is a Long Range communication protocol often used to create Low Power Wide Area Networks (LPWANs) with an operating range that goes from hundreds of meters up to 10 kilometres. It is based on LoRa modulation (PHY Layer) while the Medium Access Control (MAC) layer is an open network architecture regulated by the LoRa Alliance. The most used and large LoRaWAN network is The Things Network, with more than 10'000 LoRaWAN Gateways and 110'000 community members.

LoRaWAN has different end nodes classes: Class A, B, and C. All LoRaWAN devices must implement Class A, whereas Class B and C are extensions of Class A devices. These classes, defines the behaviour about downlink packets from gateways to end nodes. Usually LoRaWAN gateways acts as Class C devices, since they are constantly listening for incoming transmission. Also, in order to transmit and receive data over LoRaWAN network, LoRaWAN end nodes must be registered and enabled on the Application Server provider.

Given the LoRaWAN protocol nature, there are many limitations regarding payloads sizes, usage policy and operating range. That's because LoRa modulation is characterised by a Spreading Factor (SF) which defines the airtime duration of the chirp. Increasing the SF increases the symbol time, allowing the signal to travel over a longer distance. A lower SF allows the greater data rate and lower symbols airtime, while an higher one allows the highest transmission range with the lowest data rate, thus higher energy consumption. Also, as shown in the following table, SF affects the maximum packet payload, which is equal to 222 bytes with the lowest SF (SF7), while the minimum, instead, is reached with SF set to 12, with a limit of 51 bytes for user’s data.

For a detailed explanation of LoRaWAN protocol and its limits, you can check my dedicated article.

Narrowband Internet of Things (NB-IoT) Protocol

Narrowband Internet of Things (NB-IoT) is a LPWAN protocol created by 3GPP which focus on indoor coverage for low power and low cost IoT applications. As LTE-M, it uses a subset of the existing LTE networks managed by many operators, in order to guarantee an high connection density over a wide regions. NB-IoT uses OFDM modulation for downlink communication and SC-FDMA for uplink communications, while the bandwidth is limited to a single narrow-band up to 200 kHz. Given its high link budget, it is mostly used for urban IoT applications with battery powered device (e.g., smart meters).

Given its very narrow band, it is usually allocated inside guard-bands of existing LTE networks using one or more Resource Blocks of 180 kHz each. Otherwise, it can be deployed as standalone network as a result of one or more GSM carrier frequency re-farming operation. It is a cheaper-to-implement protocol, since relays on the existing LTE infrastructure of radio base stations. The implementation of the standard requires only a software upgrade of the infrastructure.

Compared to LoRaWAN, it has an higher per-nodes cost, since each node needs a subscription with an Internet Service Provider, but the overall coverage should be greater, allowing also an high devices density per squared kilometer. It has a power consumption comparable to LoRaWAN, allowing the creation of battery powered devices that can last for some years.

NB-IoT is believed to be a great alternative to LoRaWAN for Long Range Internet of Things applications, and is a far way better the the old but still used GSM, given its higher efficiency and lower end nodes costs.

LTE-M Protocol

LTE-M protocol, also known as LTE Machine Type Communication protocol, is a type of LPWAN radio standard developed by 3GPP to power a wide range of cellular devices and services. As the name suggests, LTE-M uses the same carrier frequency adopted by LTE networks, which can be different from region to region. However, in order to limit the power consumption of the transceiver, the signal bandwidth is limited to 5 MHz or 1.4 MHz, while downlink and uplink data rates are more than ten times lower than a common LTE connection, since the typical uplink data rate for an LTE-M device can reach up to 7 Mbit/s, while the downlink data rate can reach up to 4 Mbit/s, while in some version it is limited to 1 Mbit/s.

One of the main advantage of LTE-M over NB-IoT and LoRaWAN protocols is its higher data rate, followed by the mobility opportunity offered by this connection, which overcomes some of LoRaWAN and NB-IoT great limits. However, its deployment cost is higher, since a contract with LTE-M operators is needed. Also, the power consumption is higher than LoraWAN and NB-IoT, making it suitable for mobility applications with limited battery life.

Wi-Fi ah (HaLow)

Wi-Fi HaLow is a new Wi-Fi standard announced back in 2016. Almost all Wi-Fi standards (IEEE 802.11 a/b/g/n/ac) operates at either 2.4 GHz or 5 GHz, which allow them to reach a relatively high data rate but a lower sensitivity over wide operating range with obstacles and walls. Therefore, these Wi-Fi versions are often limited to Wireless Local Area Networks (WLANs) within an operating range below 50 m. Wi-Fi HaLow solved the limited range problem of typical Wi-Fi standards using 900 MHz as carrier frequency, which can easily penetrates through walls compared to 5 and 2.4GHz.

Also, it has a lower power consumption when compared to the more used Wi-Fi standards. Given its low power and wider operating range, which can reach up to 1 kilometre, it could be an interesting standard for LPWANs IoT applications. However, considering the need for new radio equipments, since it uses a complete different frequency than the other versions, it is actually rarely used. Even if HaLow was released in 2016, actually there are almost no products on the market that uses this standard. This could partly depend on the lack of a global standard, but it is likely also due to the fact that there are competing technologies on the market that better address the needs of IoT.

5G Networks

Currently in an early stage, 5G networks will probably revolution the Internet of Things world, allowing unprecedented devices density for squared kilometre. Its very low latency nature, combined with an ubiquitous coverage, will support the development of Smart City, Farming and Industry applications with thousands of sensing nodes, vehicles such as autonomous cars, trucks and even drones, but also real time services of data analysis over large area networks, exceeding all the limits of current protocols. However, it is too early to talk about 5G IoT devices, since networks are still under deployment and costs are actually too higher for that kind of use cases.

L'articolo Internet of Things Wireless Networks: which are the most common IoT Wireless communication protocols? proviene da Emanuele Pagliari.

If you have been fiddling with some Internet of Things development boards and Wireless Sensor Networks, you should already have heard of LoRaWAN communication protocol and other Wireless communication protocols. During my master degree, I worked many times with LoRaWAN protocol, both for my final thesis and some homemade projects, like the LoRaWAN Single Channel Gateway which I illustrated in THIS tutorial.

But what is LoRaWAN? How can a 10 dollar board achieve an operating range of many kilometres? What's the difference between LoRaWAN and LoRa? Are they the same thing?

I will try to answer to all these questions in this article, where I will explain what I learned during my master degree in Communication Engineering working on this wonderful but limited Long Range communication protocol widely used in many Internet of Things applications.

LoRaWAN: the cheapest Internet of Things Long Range communication protocol

What's the difference between LoRa and LoRaWAN?

LoRaWAN is a Long Range communication protocol often used to create Low Power Wide Area Networks (LPWANs) with an operating range that goes from 300 meters up to 10 kilometres. Among the main LPWANs protocol, LoRaWAN is one of the most know and used, given its open architecture. Talking about LoRa and LoRaWAN, it must be specified that the two terms refer to different things: LoRaWAN is a protocol which PHY layer is based on LoRa modulation while the Medium Access Control (MAC) layer is an open network architecture regulated by the LoRa Alliance. LoRa instead, is a proprietary modulation based on Chirp Spread Spectrum (CSS) which refers to the Physical layer. LoRa protocol is also patented by Semtech Corporation, which is the only LoRa transceiver chips producer. Therefore, in the OSI protocol stack, LoRaWAN (Network Layer) rely on LoRa (Physical Layer), as visible below, since it defines the network media access rules, the authentication method, device profile and data encryption.

Another difference between LoRa and LoRaWAN is the network topology, since LoRa allows only Point-To-Point links, while LoRaWAN, given its nature of Network Layers, defines all the needed rules to create a multiple stars network topology composed by many LoRaWAN end nodes and gateways. Gateways acts as bridge between the LoRaWAN network and IP-based networks, delivering data from end nodes to one or more applications servers and vice-versa.

How LoRa modulation work?

LoRa modems modulate symbols into increasing and decreasing frequencies chirps, respectively called up-chirps and down-chirps, as visible in the following illustration.

Each LoRa transmission has a Preamble and a Start-Frame-Delimiter (SFD), which precede the encoded core data in order to initiate and lock the LoRa receiver, in order to correctly listen the incoming transmission. In turn, SFD and Preamble have different polarity, so they use up-chirps and down-chirps, respectively, depending on these polarity settings.

LoRa modulation has many parameters, which can partially be modified, depending also on the operating region of the system. They are:

• Carrier Frequency: it defines the carrier frequency of the medium used for both transmission and listening operations. It also depend on the operating region: in Europe, the LoRa operating carrier frequency is the EU 863-870MHz ISM band, while in US it is the 902-928~MHz ISM band;
• Signal Bandwidth: it  represent the width of the LoRa RF signals. It is typically set to 125kHz, but can be increased up to 250kHz or even 500kHz in some regions for particular modulations parameters;
• Coding Rate: it is a parameter which defines the Forward Error Correction (FEC) rate used by LoRa transmitters and receivers in order to reduce the destructive effects of the RF interference. It affects the symbol airtime, since it increases the symbol overhead to make it more noise-resistant. By default its value is set to 4/5;
• Spreading Factor: it represent the chirp spreading parameter, defining how many chirps are sent per second. I ranges among SF7 and SF12. In detail, a large SF increases the symbol airtime and the energy consumption, thus improving the communication range, but reducing the available data rate and messages' payload size;
• Transmission Power; it is the energy irradiated by the LoRa node's antenna. Moreover, it can range from -4 dBm up to +20 dBm (+14 dBm in Europe), but different regions could have different power limits;
• Chirp Polarity: it defines the polarity of the transmitted chirps. It is often defined by the different protocols implementations, since, as example, LoRaWAN gateways transmit packets to end-nodes using an inverted polarity modulation, so that these messages are discarded by neighbour gateways, while end-devices transmit packets using non-inverted polarity, in order to be received only by the gateways;
• Sync Word: it is a one-byte value parameter defined by the last two up-chirps of the Preamble and used to differentiate LoRa networks using the same frequency bands. Any device configured with a given Sync Word will discard any incoming transmission if the Sync Word is diffrent from the defined one.  Typically, the Sync Word parameter for private LoRa networks are 0x12 for Semtech SX127x devices and 0x1424 for SX126x devices, while public LoRa networks (such as LoRaWAN or TTN) are represented by values equal to 0x34 for Semtech SX127x devices and 0x3444 for SX126x devices.

How many LoRaWAN device classes exist?

LoRaWAN end nodes can also be classified into three categories: Class A, B, and C. All LoRaWAN devices must implement Class A, whereas Class B and C are extensions of Class A devices. These classes, defines the behaviour about downlink packets from gateways to end nodes. A Class A device support bi-directional communication but, while uplink messages can be sent at any time, downlink messages can be received only during two specific windows at specified times after an uplink transmission, allowing the lowest energy consumption mode. Class B devices are suitable for downlink related activities, since a time-synchronised receiving window is periodically opened through beacons. Class C devices instead, keep the receiving window open unless they are transmitting again, strongly increasing the power consumption. Usually LoRaWAN gateways acts as Class C devices, since they are constantly listening for incoming transmission.

In order to transmit and receive data over LoRaWAN network, LoRaWAN end nodes must be registered and enabled on the Application Server provider, which manages the open network gateways. Therefore, LoRaWAN device can join the network in two ways: through an Over-The-Air-Activation (OTAA), or with an Activation-By-Personalization (ABP) method. Both methods works well, but the first one is more secure, since each times that the end node sends a join-request, it receives a join-accept with a NetID, DevAddr and an AppNonce which are used by the device to generate a NwkSKey and AppSKey in a secure way. An ABP device instead, has already both DevAddr, AppSkey and NwkSkey, which are sent over the network at each transmission in order to identify itself.

Which are LoRaWAN payload, ranges and bitrates?

LoRa modulation is characterised by a Spreading Factor (SF) which defines the airtime duration of the chirp. Increasing the SF increases the symbol time, allowing the signal to travel over a longer distance. Limiting the study to the free 868 MHz European band used by LoRa, SF can vary between 7 and 12, where SF equal to 7 allows the greater data rate and lower symbols airtime, while SF equal to 12 returns the highest sensitivity and transmission range with the lowest data rate and higher energy consumption, given by the longer transmission duration. SF and the relatives bit rates, are reported in the following illustration, which also show other modulation informations, like the signal bandwidth (typically 125 kHz in Europe), the minimum receiver sensitivity and the relative operating range, power consumption and airtime.

One of the most important thing to know when working with LoRaWAN is the maximum packet payload for each SF. Given LoRa low power and low data rate nature, optimal for many Internet of Things applications, the packet payload is very susceptible to the used SF, since this parameter acts on the transmission data rate. LoRaWAN network layer typically uses 13 bytes as packet header for the operation of the protocol, a not negligible value that at high SF significantly affects the maximum payload of the package. Maximum payload size is reached with SF7, which allows up to 222 bytes of user's data inside a single Lora packet. The minimum, instead, is reached with SF set to 12, with a limit of 51 bytes for user's data. Payload limits, data rates, bitrates, receiver sensitivity and typical operating range related to each SF with a bandwidth of 125 kHz at a carrier frequency of 868 MHz, are shown in the following table.

Despite this, the real world LoRaWAN operating ranges could be very different. In my Line-of-Sight LoRaWAN range test, for example, I could achieve an operating range of several tens of kilometres without any obstacles in the middle, with a peak at about 75 kilometres. You can check more detail about my LoRaWAN Line-of-Sight tests HERE. However, in a semi-urban environment, the operating ranges are different, as visible in THIS article.

Which are LoRaWAN European channels and frequencies?

LoRaWAN protocol uses eight uplink (from end nodes to gateways) channels defined inside the EU863-870 MHz free ISM band. Uplink channels can also be used as downlink channels on the first receiving window, but there is also a ninth channel defined at the frequency of 869.525 MHz used only for the second receiving window. Both uplink and downlink channels of the EU863-870 MHz free ISM band are shown in the following picture.

There is also a ninth uplink channel, which has a fixed frequency of 868.8 MHz frequency, but uses an FSK modulation. Another key feature of LoRaWAN protocol is the Radio Medium Access, based on ALOHA protocol, which was developed at the University of Hawaii back in 1970s.

Which are LoRaWAN fair usage policies?

LoRaWAN network has some strictly policy rules, which must be respected for a fair network usage. These are:

• any device has a daily maximum cumulative airtime of 30 s for uplink messages;
• any device has a maximum of 10 daily downlink messages, which includes ACKs.

Since airtime depends on SF and messages payload, the daily messages limit strictly depends on these two parameters. For example, for a fixed 10 bytes payload, this translates to up to 20 daily uplink messages with SF set to 12 or around 500 daily uplink messages with SF7. Also, LoRaWAN devices must respect bandwidth duty cycle, which depends from region to region. For EU868 MHz free band, duty cycle goes from 0.1 % to 10 %, depending on the channel used. This means that every time a device transmit over a LoRaWAN channel, it can not transmit on this channel for a certain amount of time, which is usually computed by the device itself starting from the previous transmission airtime.

Finally, another parameter that LoRaWAN devices must respect is the maximum transmit power, which, for the EU868 MHz band, is set to +14 dBm, as defined by the European Telecommunications Standards Institute (ETSI) European laws.

L'articolo What is LoRaWAN Internet of Things protocol and how does it work? proviene da Emanuele Pagliari.

Two years ago I began my adventure in the Wireless Sensors Network (WSN) world and, among the main existing wireless protocols, one of the most widely used is, of course, LoRaWAN. In this tutorial I going to show you how to build an outdoor Single Channel LoRaWAN Gateway based on one of the cheapest ESP32 development board available on internet: the Heltec ESP32 LoRa V2 dev board.

A Single Channel LoRaWAN Gateway based on an ESP32 dev board is a very affordable starting point to begin LoRaWAN prototyping without the need to buy a full LoRaWAN Gateway, which has eight working channels and a more complex transceiver, thus an higher cost (but you'll need it once you'll work with multiple LoRaWAN end nodes, given the Single Channel solution limitations).

First, I'm going to explain a bit, what is LoRaWAN (HERE a detailed explanation) and what is the difference with LoRa. Then, I'm going to explain step by step what you need to create a Single Channel LoRaWAN Gateway to place outdoor, maybe on a roof like mine, because if you will use LoRaWAN, you'll use it for Long Range Communication between one or more end nodes and the gateway, so, the higher you place it, the wider the radius of coverage will be. Finally, I'll show you some range tests and explain which are the limitations of such system.

A Single Channel LoRaWAN Gateway based on Heltec ESP32 LoRa dev board

What is LoRaWAN?

I already answered in a detailed way to this question in a dedicated article (you can find it HERE). However, here you are a short description: LoRaWAN is a Long Range communication protocol often used to create Low Power Wide Area Networks (LPWANs) with an operating range that goes from 300 meters up to 10 kilometres. It is based on LoRa modulation while the Medium Access Control (MAC) layer is an open network architecture regulated by the LoRa Alliance. LoRaWAN end nodes can also be classified into three categories: Class A, B, and C. All LoRaWAN devices must implement Class A, whereas Class B and C are extensions of Class A devices. These classes, defines the behaviour about downlink packets from gateways to end nodes. Usually LoRaWAN gateways acts as Class C devices, since they are constantly listening for incoming transmission.

In order to transmit and receive data over LoRaWAN network, LoRaWAN end nodes must be registered and enabled on the Application Server provider, which manages the open network gateways. That's why, in the last part of this tutorial, we will register our gateway on the things Network.

Single Channel LoRaWAN Gateway Requirements

We need many components plus the ESP32 with Semtech SX1276 LoRa modem development board. In my case, I decided to use the Heltec ESP32 LoRa V2 board based on the ESP32 microcontroller. There are two version of it: the first one has a SX1276 LoRa modem and is suitable for 868/915 MHz EU/US LoRaWAN carriers, while the second one is based on the Semtech SX1278 modem and is suitable for 433 MHZ CN bandwidth. So be sure to buy the right one based on your development board connector. Finally, You'll need a pole where to fix the IP65 waterproof box, a power supply able to deliver up to 1A at 5 Volt through a typical USB connector, and a USB-to-microUSB cable (at least five meters) to deliver power to the board placed on the roof while keeping the power supply in a dry and secure environment. You will also need many screws to fix the IP65 box to the pole. I also used some Lego bricks to fix the board inside the box ... but you can use different solutions.

Summarising, you need:

• one ESP32 development board with a built-in LoRa modem and antenna connector;
• one external antenna with the right connector and length for your frequency and dev board;
• an IP65 box;
• a pole;
• a 5 Volt 1A USB power supply;
• a USB-to-microUSB cable, with a length of at least 5 meters, depending also on your installation;
• something to fix the board inside the box;
• many screws and rods to fix the box to the pole.

Total cost should be around 30-35$.

The ESP32 SoC

ESP32 is a cheap and low power SoC which integrates an IEEE 802.11 a/b/g/n and both Bluetooth Classic and BLE IEEE 802.15.1 radio equipments. It is widely used for many industrial applications and also IoT products, since the whole SoC with a 2.4 GHz Printed Circuit Board (PCB) antenna has a package size of seven for seven millimetres and a low price. Also, many IoT manufacturers have released different kind of development boards based on ESP32 SoC, allowing developers to chose the right solution based on their needs. In fact, different boards could have various PCB layouts with pre-installed sensors, relays, RGB LED, display, external antennas connectors, LoRa modem (such as the Heltec ESP32 Lora V2, used in this project), GPS receivers, batteries and even cameras for almost any application. Its high integration also, ensures that it is reliable and resistant to extreme operating temperatures (between -40°C and +85°C), making it suitable for applications in harsh environments. ESP32 SoC is made by the Chinese company Espressif Systems, and it is the successor of the Wi-Fi-only ESP8266 SoC, which i have used in another project. It integrates a Tensilica Xtensa LX6 dual-core 32-bit CPU whit a clock that can achieve up to 240 MHz. There is also an Ultra Low Power (ULP) co-processor and a Real Time Clock (RTC) to enable deep-sleep functionalities, useful for battery powered devices with long stand-by times. Then there are 520 KB of SRAM, followed by 448 KB of ROM for booting and core functions, and up to 16 MB of embedded ash memory, which is plenty for almost any end node implementation. The SoC also integrates all the radio components needed for the functioning, since clock generator, receiver, transmitter, balun and antenna, are all inside the same package, making it a ready to use solution. Full Wi-Fi and Bluetooth protocol stack are also supported, making it easer to develop application based on these interfaces. The whole chip is manufactured by TSMC foundries using a 40 nanometres process, which ensures a good trade-off between costs and integration, thus low power consumption. All the SoC integrated components are shown in the following figure.

Hardware setup: connecting the Heltec ESP32 to the antenna

In this project there isn't much to do on the hardware side. We just have to connect the development board - in this case the Heltec ESp32 LoRa V2 - to the antenna using the bundled SMA connector. I decided to replace the bundled antenna with a "bigger one", in order to achieve an higher gain (5 dBi). Also, the antenna adopted can be tilted, so that I can place it in a vertical position without waterproofing issues. Once this operation has been done, we can go go to the software flashing. It's strongly suggested to use the Heltec ESP32 LoRa with the antenna connected, otherwise you can burn the built-in modem. This applies also for any other external antenna device, so be careful!

Software setup: compile and flash the LoRaWAN Single Channel Gateway implementation of the Heltec ESP32

At this point, we have to work on the software part. I use the Arduino IDE to program my ESP32 and 8266 boards. However, you can use any other IDE you want. If you decide to use Arduino IDE, be sure to import the right libraries and COM ports driver. You can check this tutorial.

Now we have to simply compile and flash the firmware to our LoRaWAN ESP32 development board. Initially, we have to download the LoRaWAN Single Channel Gateway implementation for ESP32 and Semtech-based dev boards, like the one used in this tutorial. As already stated, I'm not the developer of the LoRaWAN implementation, so I'll link the original author (Maarten Westenberg) of the code, where you will also find the updated version of the code: GitHub repository.

Clone or download the whole repository, decompress it and go to the "src" folder, where you will find the source code of the LoRaWAN Single Channel Gateway implementation for any ESP32 board with a Semtech Lora modem.

There are many files in this folder. Among them, we have to modify at least the "configNode.h" file, where we have to place our Wi-Fi network SSID and password. You can place more than one Wi-Fi SSID, so that if it can't be found, the LoRaWAN Gateway will fall back on the second or third Wi-Fi network in the list. If you are using a different ESP32 development board, you also have to change your hardware configuration inside the "configGway.h" file, where you have to specify your pin configuration and the OLED display installed on your development board. You can also act on other parameters such as Spreading Factor, Channels, Carrier frequency based on your country (EU is 868 MHz, USA is 915 MHz, pay attention to this parameter!) and so on, but in my case, I only had to set the OLED display to 1, which is suitable for the Heltec ESp32 LoRa V2 board.

[gallery size="large" columns="2" ids="466,467"]

Safe the configurations and then open with your Arduino IDE the "ESP-sc-gway.ino" file. A pletora of additional files will be opened inside the IDE, but you don't have to touch them. Now, if you have already installed all the ESP32 libraries, you can now import the additional libraries which have been downloaded together with the source code from the repository. You just have to import them using the "Sketch menu option" inside Arduino IDE. Select all the libraries inside the downloaded "lib" folder and import them. Now you should be able to compile the firmware without any dependency error.

To do this, you have to select your ESP32 LoRa development board inside "Tools" menu inside Arduino IDE. Then, connect it to your computer using the right cable and select from "Tools" menu the right port. At this point, you can press the compile and flash button. If all goes well, your ESP32 board will restart after a couple of minutes as a LoRaWAN Single Channel Gateway. You can monitor it both using the serial monitor function or directly from your browser (of course, both the PC and the GW should be connected to the same network) by typing the device IP in your browser URL bar. The IP is printed on the serial monitor console each time the Gateway reboots, or you can look for it using many network tools or by checking your DHCP server.

I also have to say that I made some changes in the original code, because I implemented a different kind of OTA update and an additional DHT11 sensor, in order to measure the temperature over the roof of my house. Finally, I overcome the maximum payload limit of the received messages, which is, by default, set to 64 bytes, replacing the HEX value to the 184 bytes equivalent, since over this value the system seems to truncate the messages.

Software setup: LoRaWAN Single Channel Gateway web interface & settings

The LoRaWAN Single Channel Gateway comes with a rich and useful web server which can be accessed through the IP address of the device over the same LAN. The web server interface provides many useful information for debugging and statistics. For example, it is possible to see the last received message's SF, device's classes, RSSI, node identifier and other statistics, as visible below, which represents a portion of the default web server page.

In the same web page all the LoRaWAN Gateway parameters can be seen, such as the IP address of the device, the LoRaWAN router IP and URL, the connected Wi-Fi SSID and the GW ID, which is needed for the registration on The Things Network, as we'll see later. There are also many information useful for system debugging, such as the number of Wi-Fi connection attempts and the available free memory. It is even possible to enable a logging system which can then be download through the web interface. The Web interface not only provides statistical tools, but also many controls, since there are buttons to enable/disable some features and to change GW settings. For example, it is possible to enable or disable Channel Activity Detection (CAD), needed for enabling the reception of messages with different Spreading Factor over the same channel.

Then, it is possible to manually change the channel form the default one or to setup an automatically frequency hopping to change the LoRaWAN channel among those available. Thus, it is possible to reset board statistics, change the debug level and I decided to add a button to reboot the Gateway remotely. All these remote control solution are mandatory in a context where the GW is not easily accessible, such as in my final installation, where the LoRaWAN ESP32 GW is placed over the roof of my house.

Software setup: the Things Network Gateway registration

If you want to use the developed system, you have one last easy step to do: register on The Things Network (TTN) and connect the Heltec ESP32 GW to it. In order to do this, simply go HERE.

TTN is a free to use network infrastructure with the goal to provide free LoRaWAN network coverage around the world. Thanks to its community, The Things Network is the biggest and most used LoRaWAN network, since there are more than 10'000 LoRaWAN Gateways around the world and about 108'000 community members. TTN provides a set of software tools which allows users to create their own LoRaWAN application or to simply setup a GW. Therefore, any LoRaWAN nodes (both GWs and end nodes) must be registered on TTN platform in order to operate correctly.

The developed LoRaWAN Heltec ESP32 GW can be easily registered on the network thought the console section, where the user simply has to add a new LoRaWAN Gateway by clicking on the "register device" label.

Then, you have to chose a name and the right parameters. You will also need one parameter, which is the Gateway ID and it is uniquely related to the LoRa modem onboard, so that each node has a unique ID. You can find it inside the LoRaWAN Web server interface under the voice "Gateway ID", and it's a 16 characters string. Put it into the right TTN field and complete the registration process, then your GW is ready to provide LoRaWAN connectivity to yours applications.

The final installation

If you arrived here, you can already use your LoRaWAN Single Channel Heltec ESP32 Gateway but ... in order to reach better performances, there is one more thing to do: place it as high as you can. I know, it's not a simple process but, thrust me, it is well worth, since it's the only way to reach a coverage of more then 3-4 kilometres.

To do this, I placed the board inside an IP65 box, while the antenna has been placed and isolated on the side, in order to keep the system as waterproof as possible. Here below you can see some pictures of the system and some details of the IP65 adaptation.

[gallery size="medium" columns="2" ids="431,427"]

In order to fix the board inside the box, I used some Lego bricks, and I finally placed the power cable on the bottom side, where it has been fixed. In the picture you can also see the DHT11 sensor located in a bottom hollow.

[gallery columns="2" size="medium" ids="428,429"]

Finally, I placed it over the roof of my house, fixing it to the TV antenna pole, at about 14 meters height from the ground.

The system is up and it's running since late February 2020 (yes, it survived a pandemic). It has seen snow, ice, frozen winds, heavy rains, hail (what a hail!) and many thunderstorms, but it's up and it's running flawlessly.

Closing thoughts: achieved operating ranges!

In this section I'll briefly show you what kind of coverage I can reach with this system. I live in a very small town, with less than 700 inhabitants, so there are a few houses, mostly 2 or 3-floors houses, so there is any tall building between my LoRaWAN Single Channel gateway and the two final LoRaWAN end nodes I installed in the country side.

Using the lowest LoRa Spreading factor - SF7 -, I can easily cover one node (A in the picture) placed at 1.25 Km from the GW, across the "city", and a second one (B in the picture) placed in the countryside behind my house ad 1.92 Km.

The first node is in Non Line-of-Sight (NLOS) setup, given the sub-urban environment with many buildings and trees between the two devices. The partial urban environment with its buildings limit the operating range of LoRaWAN communication, since the observed Received Signal Strength Indicator (RSSI) is near at the minimum acceptable level for SF7, with a mean value around -118 dBm. Therefore, only 83% of the messages are successfully received by the GW, but, for this kind of application (a weather station) it's enough.

The second node is in an almost obstacles free environment, with a direct Line-of-Sight (LOS) between the two devices. the result is a "good" RSSI of about -115 dBm, which should allow a greater distance on such environment. That's enough to reach a 98%+ correct packets reception, achieving a reliable Long Range communication.

Drawbacks

As stated in the introduction, this system is cheap, works well and can be used for two, three and even more LoRaWAN end nodes but ... there are many limits. First of all, all the end nodes must use the same channel, so if you're gonna send a lot of messages, you gonna have some collisions problems and lose them. Second, it's not a fully compliant full LoRaWAN Gateway, because it has only one operating channel and because the uplink operations have some issues, since too many uplink messages makes my gateway reboot. Also, a gateway like this won't really help the LoraWAN community, since it has only one channel, so please, consider a powerful and complete one once your prototyping is complete and you're going to deploy your applications. Finally, there is another "serious" issue which explain why I decided to fix the system with a Spreading Factor equal to seven (SF7) to both the end nodes and the gateway itself. If you enable Channel Activity Detection (CAD), you will be able to receive messages with different SF on the same channel, but your sensitivity on chirps with higher spreading factor will decrease a lot, so the system performance for Long Range applications will be awful. That's one of the reason I decide to keep the system fixed to SF7. However, you can fix the LoRaWAN gateway to SF9 of higher for longer distance applications, and you will easily reach 3-4 km (I can easily get 5 Km with SF12) and more. So, once my prototypes will be complete, I think I'll switch to a complete LoRaWAN Gateway, because these limitations are getting harder to accept.

That's all!

L'articolo How to build an outdoor Single Channel LoRaWAN Gateway based on Heltec ESP32 LoRa dev board proviene da Emanuele Pagliari.

Ad inizio 2018 ho creato - assieme ad alcuni miei colleghi di Università - Cryptominando.it, blog italiano incentrato sul mondo delle criptovalute ed applicazioni della tecnologia blockchain.

L'avventura è iniziata un po' per gioco la sera del 18 Gennaio 2018, quando, riuniti in quel di Lagrimone, sull'appenino Parmense, abbiamo acquistato il dominio e creato il sito web utilizzando il CMS Wordpress.

Dopo poche settimane ci siamo resi conto che non si trattava più di un gioco, di un passatempo, ma di un vero e proprio lavoro. Gli utenti sui social crescevano a vista d'occhio, le visite aumentavano giorno dopo giorno e con esse anche gli apprezzamenti da parte della community. Crescendo abbiamo poi partecipato ad eventi e fiere, anche internazionali, dove abbiamo avuto modo di conoscere ed apprezzare la realtà di questo settore in ambito aziendale.

Ma facciamo un passo indietro e scopriamo perché è nato cryptominando.

Progetto Cryptominando: blog italiano su criptovalute e blockchain

L'idea

L'idea alla base del progetto cryptominando, era di fornire notizie fresche, approfondimenti e guide per far avvicinare gli utenti neofiti al mondo delle criptovalute ed esplorare le applicazioni della blockchain.

Nel momento in cui abbiamo deciso di creare il blog infatti, sulla scena italiana vi erano poche realtà nostrane n questo settore. Alcuni siti web trattavano solo notizie, altri solo guide, altri ancora solo di mining. Altri ancora, trattavano solo alcune criptovalute specifiche.

Mancava qualcuno che coprisse tutto, o quasi, il settore, in maniera continuativa e tempestiva. Ed è proprio su questo fattore che abbiamo deciso di puntare, garantendo un servizio di informazione gratuita con una certa tempestività e costanza. Molti piccoli blog infatti, passata la bolla a cavallo tra il 2017 ed il 2018 hanno chiuso i battenti. Ma noi no, anzi abbiamo premuto il piede sull'acceleratore.

La linea editoriale

Nel nostro progetto abbiamo optato per una linea editoriale inizialmente focalizzata sulle guide e sulle rubriche, così da approfondire l'ABC delle criptovalute e della blockchain. Successivamente, consolidata l'utenza e le fondamenta costituite da wiki e tutorial, ci siamo focalizzati sulle notizie, cercando di garantire la massima tempestività.

La strategia si è rivelata vincente, consentendoci di acquisire e fidelizzare l'utenza che giungeva sul nostro sito dalle ricerche su Google, merito anche della forte attenzione alla SEO che abbiamo applicato nei nostri articoli.

La scelta dei migliori contenuti abbinati alle giuste KeyWords, studiate analizzando le tematiche più ricorrenti sulle principali community Telegram e Facebook di criptovalute, ci ha spesso consentito di essere sempre sul pezzo. Tra i contenuti proposti, io personalmente mi sono occupato spesso del mining di criptovalute, scrivendo articoli piuttosto tecnici e complessi riguardanti gli algoritmi di mining, l'hardware da utilizzare ed il funzionamento di alcuni protocolli.

Tali contenuti, complice la "scarsità" di materiale in rete, si sono rivelati spesso un vero e proprio successo, catturando l'attenzione anche degli utenti più geek, che di solito snobbano i siti web italiani affidandosi solamente a quelli internazionali.

Il vero punto di forza di cryptominando però sono state le guide. Abbiamo infatti redatto alcune delle guide più complete e dettagliate fra quelle disponibili in lingua italiana. Dalle tematiche più semplici, fra cui, ad esempio, "Come usare Coinbase", etc, fino a quelle un po' più tecniche, ovvero "Come creare uno Smart Contract Ethereum", etc. Stesso discorso per quanto riguarda gli approfondimenti, in cui sono stati illustrati i concetti alla base del funzionamento della blockchain ed in cui sono stati spiegate possibili applicazioni, problemi, evoluzioni etc.

Eventi & Media Partner

Con l'aumento della popolarità del sito web, lo staff di Cryptominando ha avuto modo di partecipare a diversi eventi inerenti al mondo delle criptovalute nel Nord Italia, fungendo anche da Media Partner ufficiale.

Proprio grazie a questi eventi, abbiamo avuto modo di proporre interviste di alcuni esperti e personaggi del settore, oltre ad aver la possibilità di redarre contenuti esclusivi.

Tra gli eventi a cui abbiamo partecipato, segnaliamo Codemotion ed il Mobile World Congress 2019, durante il quale abbiamo avuto modo di tastare con mano alcune applicazioni della blockchain in ambito aziendale, nonché di assistere ad annunci e keynote dei massimi esponenti del settore.

Un po' di numeri

In quasi un anno e mezzo di attività, sono stati pubblicati più di 1350 articoli. In totale, sono state scritte circa 770mila parole, mentre io personalmente ho battuto ben 263mila parole in quasi 400 articoli.

Durante questo periodo, cryptominando ha registrato più di due milioni e mezzo di visualizzazione di pagine. Adsense, una delle tre piattaforme di Advertising da noi utilizzata, ha registrato ben 1.3 Milioni di impressioni, per oltre 2.8milioni di unità pubblicitarie visualizzate.

Mentre il numero di utenti univoci totali si aggira intorno alle 600mila unità.

Il mese con più visite è stato Novembre 2018, con quasi 370mila visite ed oltre 100mila utenti univoci.

Il giorno con più visite è stato il 17 Settembre 2018, con quasi 40mila visite quotidiane ed oltre 17mila utenti univoci.

Tra i social di Cryptominando, la community Telegram vanta ben 2200 Membri, mentre il canale oltre 3500 Membri. Si tratta del canale Telegram italiano di criptovalute con il maggior numero di utenti.

L'articolo Progetto Cryptominando: blog italiano su criptovalute e blockchain proviene da Emanuele Pagliari.

At the beginning of 2018 I created together with my University colleagues Cryptominando.it, an Italian blog focused on the world of cryptocurrencies and blockchain applications.

The adventure started for fun on the evening of January 18 2018, when we met in Lagrimone, near Parma. We bought the domain and created the website using the WordPress CMS.

After a few weeks we realized that it was no longer a game, but a real job. Users on social networks were growing fast, visits were increasing day by day and with them also the appreciation from the community. As we grew up, we also participated to events and fairs, including international ones, where we had the opportunity to met and appreciate the reality of this sector.

Cryptominando Project: Italian blog about cryptocurrencies and blockchain

The idea

The idea behind cryptominando project, was to provide fresh news, insights and tutorials to bring newcomers to the world of cryptocurrencies and explore the applications of blockchain technology.

When we decided to create the blog, on the Italian scene there were few Italian websites in this field. Some websites only treat news, others only guides or only mining. Others one treat only with some specific cryptocurrencies.

Someone who covered everything, or almost the sector, in a continuous and timely manner was missing. And it is precisely on this factor that we decided to focus, ensuring a free information service with a certain timeliness and constancy. Many small blogs in fact, have closed their doors after the crypto bubble between 2017 and 2018 . But we didn't!

The editorial line

In our project we have opted for an editorial line initially focused on tutorials and columns. Subsequently, consolidated the users, we focused on the news, trying to ensure maximum timeliness.

The strategy proved to be successful, allowing us to acquire and retain the users who came to our site from searches on Google, also thanks to the strong focus on SEO that we have applied in our articles.

The choice of the best content combined with the right KeyWords, studied by analyzing the most common issues on the main Telegram and Facebook communities, has often allowed us to be always on the piece. Among the proposed contents, I personally have often dealt with cryptocurrency mining, writing technical and complex articles about the mining algorithms, the hardware to be used and the many protocols.

Such contents, have often proved to be a real success. The real strength of cryptominando, however, were the tutorials. In fact, we have written some of the most complete and detailed guides among those available in Italian. From the simplest topics, including, for example, "How to use Coinbase", etc., to the more technical ones, such as "How to create a Smart Contract Ethereum", etc.. The same goes for the in-depth studies, in which the concepts underlying the functioning of the blockchain were illustrated and in which possible applications, problems, evolutions etc. were explained.

Events & Media Partners

As the website became more and more popular, Cryptominando staff had the opportunity to participate in various events related to the world of cryptocurrencies in Northern Italy, also acting as official Media Partner.

Thanks to these events, we were able to propose interviews with some experts of the sector, as well as having the opportunity to write exclusive content.

We partecipated to events like Codemotion and the Mobile World Congress 2019, during which we had the opportunity to touch some of the applications of the blockchain within many companies.

A few numbers

In almost a year and a half of activity, more than 1350 articles have been published. In total, about 770,000 words have been written, while I personally have write as many as 263,000 words in almost 400 articles.

During this period, cryptominando recorded more than two and a half million page views. Adsense, one of the three Advertising platforms we use, recorded 1.3 million impressions, for over 2.8 million advertising units displayed.

While the total number of unique users is around 600 thousand.

The month with the most visits was November 2018, with almost 370 thousand visits and over 100 thousand unique users.

The day with the most visits was 17 September 2018, with almost 40 thousand daily visits and over 17 thousand unique users.

Among Cryptominando's social networks, the Telegram community has 2200 members, while the channel has over 3500 members. It is the Italian Telegram channel regarding cryptocurrencies with the highest number of users.

L'articolo Cryptominando Project: Italian blog about cryptocurrencies and blockchain proviene da Emanuele Pagliari.

In this tutorial we will see how to build an home made weather station based on the cheapest Arduino compatible board with Wi-Fi connectivity: the ESP8266. We'll create a solar powered weather station for monitor outside temperature, humidity, pressure and also Dew Point through the Bosch BME280 sensor.

We will create a small Wireless Sensor Network based on Wi-Fi communication protocol. However, if you like to place your weather station far a way from home, you have to use a different wireless communication protocol to retrieve data, such as those one discussed in this article. Starting from this implementation, you could add many others sensors and features. In my case in fact, this weather station is just one of the ten nodes of my IoT network, but we'll talk about it later.

So, let's see what we need to create a fully autonomous ESP8266 solar powered weather station with Bosch BME280 Sensor!

Wi-Fi solar powered weather station based on ESP8266 and Bosch BME280 sensor

Requirements

We need many components plus the ESP8266 Board. In my case, I decided to use the NodeMCU v3 board based on the ESP8266 12E microcontroller. You can easily find it on Aliexpress for a pair of bucks. As sensor, I used the Bosch BME280, a tiny and very reliable sensor. It cost around 2.5 dollars on Aliexpress. Then we need many cables for the wiring. I suggest you to buy at least twenty standard cable for Arduino applications, those with standard PINs connection. They are very cheap but also not so reliable, so be sure to buy some spare parts. I used this kit. The last stuffs we need are the charge/discharge board, the battery and, of course, the solar panel.

As battery you can use/buy any 3.7 Volt battery you want. Be sure to use at least a 1000 mAh battery in order to have enough charge for cloudy days. I used my "ex-drone" battery, a huge 5200 mAh Lithium battery based on two connected 18650 cells. Then you need a solar panel. You can use many solutions but, since the charger board accept as input voltage a value between 5 a 7 Volt, I suggest you to use a 6 Volt solar panel. I used this one, a tiny panel that you can buy from China for one Dollar. At the end, we need a diode and an automatic charge/discharge board with battery protection circuit. I used the cheapest one: the TP4056 Charger Module.

We also need some raw material and an IP67 box for the boards and battery housing. Something like this. In order to make the temperature measurement work properly, we also have to create a solar shield. Infact, since the temperature accuracy is influenced by the sun and soil radiation, we need a proper solar shield. You could buy some ready to use solution but they cost too much.

I decided to create an homemade solar shield using many stacked planpots. You'll need 10 planpots with a diameter of 18 or 20 centimeter, and one planpot of 20 or 22 centimeter. Then, you need many studs and washers, with the right size threaded rod (at least 60 cm, in order to obtain three pieces of 20 cm). At the end you have to paint the structure with a lucid white color, in order to improve the reflectivity of the device.

Finally, you may need some waterproofing membranes and a back panel for fix all this stuff on a pole at 170 centimeter of height from the soil.

Summarising, you need:

• one NodeMCU ESP8266 Board;
• one Bosch BME8266 Sensor;
• many cables with standard PIN dimension;
• a DIODE;
• one TP4056 Charger Board;
• one or more 6 Volt Solar Panels;
• an IP67 box;
• ten 18-20cm diameter planpots;
• one 20-22cm planpot;
• lucid white color;
• one threaded rod with many studs and washers;
• a 2 meter pole;
• many waterproofing membranes.

Total cost should be around 30-35$.

Hardware setup: connecting ESP8266 and Bosch BME280

First of all we need to connect properly the ESP8266 board with the Bosch BME280 sensor. The Bosch BME280 needs four connections to work. Starting from the left, we have the VCC (3.3-5 Volt) PIN, followed by the GND PIN. Then, we have signal clock line (SCL) and the data connection wire (SDA). In this project we'll use the BME280 sensor in I2C mode.

Using four cables with PINs, connect the Sensor to the NodeMCU ESP8266 Board in this way: VCC to the 3.3 Volt port, GND to the Ground port of the board, while SCL to the port D4 and SDA to D3.

Hardware setup: connecting ESP8266, battery and solar panel

At this point, we have to connect the solar panel and the battery to our charge/dischage board. The setup is very simple. The battery must be connected to the bottom of the board. You have to but the wires on the the right positive and negative poles. Usually on the TP4056 board, these connections are marked up with "BAT+" and "BAT-" stamps.

You also have to do the same things for the solar panel on the upper part of the board. Remember also to put the DIODE on the positive wire. At the end, you can connect the ESP8266.  Your final scheme should be like the one below:

The hardware setup is done. Now we have to write the right code and put it one the ESP8266 board.

Software Setup: reading sensor data and send them to a server through POST method

At this point, we have to work on the software part. I use the Arduino IDE to program my ESP8266 board. However, you can use any other IDE you want. If you decide to use Arduino IDE, be sure to import the right library and COM ports driver. You can check this tutorial.

As reported above, I used the REST approach with the classic GET and POST methods over HTTP protocol. There aren't sessions or cookies. In my project, I create an own web server, but you can use free tools like ThingSpeak to display your data on the web. This free solutions have many limits in terms of request/day, so if you want to collect data from many sensors in real-time (so each second), you have to pay at least a Student License (if you are a students, of course), which is 80 USD Year. take a look to the difference between FREE and Students solutions:

I decided to create a "rough" web server with a very minimal PHP web page and a Mysql database where the data are stored, all on my hosting server. But first, let's see how collect the data from the sensor.

Connect EPS8266 to Wi-Fi

In order to send our data to the web server, we have to connect our ESP8266 weather station to our wireless network. To do this, we simply have to import the right library (ESP8266WiFi.h) as reported above, then we have to define the wireless network SSID, the password and use the right method to switch on Wi-Fi and establish a connection. In order to enable the Wi-Fi connection, I use the following function, which I re-called in the setup() method to initialise the connection. You can check the code here:

When the connection is established. The program will print in the output console "WiFi connected". At this point we can send our data to our main server!

Reading Sensor Data

In order to make your Bosch BME280 reachable by the ESP8266, you need the right library. You can find it here: BME Library. You simply have to import it in your Arduino IDE Library folder. Then, just import it in your main, as you can see below:

At this point, we have to define all the variables regarding temperature, humidity, atmospheric pressure and Dew Point. We also have to define many parameters. Check below:

Here we have the parameters and variables explained:

• ALTITUDE: is the altitude in meters over the sea of your locations. It's used to compute the pressure;
• I2C_SDA 4: is the PIN where you collect the wire regarding the SDA port of the BME280 Sensor;
• I2C_SCL 5: is the PIN where you collect the wire regarding the SCL port of the BME280 Sensor;
• BME280_ADDRESS 0x76: is the memory address of you sensor. Usually it's 0x76 but sometimes it is 0x77;
• cTemp: support variable for the temperature;
• humidity: support variable for the humidity;
• DP: support variable for the Dew point;
• pressure: support variable for the pressure.

We also defined the BME sensor in a simpler way, as reported below:

Adafruit_BME280 bme;

Now, we can define the sensor initialisation function:

This function will be called in the Setup() method in order to check if the sensor is available or not.

At this point, we need a function which uses the temperature and humidity to compute the Dew Point. I found it on the web, but there are many implementations. Check it:

And then, we have the Loop class, where we read the temperature from the sensor. I added an IF to check if the values are fake or real, then, if the values are real, we read humidity and pressure, then we compute the Dew Point. All the results are then printed in the output console.

At the end of the sketch I use the sleep method to send the ESP8266 board in Deep stand-by, in order to save energy, since the device will be solar powered. I set a sleep time of 300 seconds, but you can chose any interval you prefer.

ESP.deepSleep(300e6);

When the board is in deep sleep, it must be woken up using the Reset PIN. To do this, you simply have to connect through a wire connected between the RST PIN and the wake PIN. In this way, the system will wake up automatically.

Send data to the server through a POST method

Now we have the most interesting part: send the data to the server. As reported above, I chose the REST approach and I created my own web server, database and web page. But you can easily use ThingSpeak. The implementation is quite the same.

The REST approach uses the method POST and GET to send and retrieve data over HTTP protocol. So, in order to send our data to the server, we have to import the HTTP functionalities. On the ESP8266 board, they are already implemented inside the ESP8266WiFi.h library. We have three things to do . First, we have to create a string with our data retrieved from the sensor. Second, we have to create a TCP connection using WiFiClient class and then POST the string to the server in the right path.

As you can see in the screen, I created the string, which will become our URL, appending the variables definition and the measured values. Then I setup the WiFiClient in order to create the TCP connection. This method try to establish a connection on the 80 port with the chosen server, defined in the server variable at the beginning of the sketch. If the connection fails, an error message will be printed. At the end, I complete the URL adding the path where I want to post my data. In my case this is the PHP file where I perform the GET method over the URL. It depends on the web server or service that you are using, so it could vary a lot.

You should obtain something like this:

www.server.com/add_data.php?temp=14&hum=87&pr=1024&dp=11

At this point, we can perform the true POST method. There are many ways to do this, I chose this one:

Starting from the string seen before, this method will POST this URL to the server. It's like copying and pasting your URL in the browser address bar and then press enter. You can find all the code in my Gitlab repository: HERE

NB: in the sketch that I have uploaded on Gitlab you will find also the code parts related to the CoAP implementation, which I'll discuss in another tutorial in the next weeks.

At this point, the sketch is ready and can be written on your ESP8266 board.

Writing on the ESP8266  the sketch and testing it

In order to write the code on your board, you have to properly setup the Arduino IDE as explained in the first paragraph. Go to tools and select the right board. In my case, I had to chose the Nodemcu v1.0 in the IDE menu. You also have to chose the right COM port.

At this point, you can compile and write the sketch on your ESP8266 board. To do this, you simply have to press the arrow button under the Edit menu. Arduino IDE will compile the code and check for errors. If all is right, the sketch will be uploaded to the ESP8266.

Before uploading, remember to remove the wire connection between the RST and WAKE PIN, otherwise the upload will fail.

At this point, you can check if the device works using the serial monitor. You can find it under the tools menu in the Arduino IDE. Remember to chose a baud rate as set on the ESP8266 board. If all is ok, in the output console you will see the read values of temperature, humidity etc and the URL string.

Web server setup

Now we have the final step. Here I'll briefly show you the setup for my self made server. However, I must tell you that this is a very spartan solution... you can easily do it better! Let's start!

I created three files: one in order to create the web page with the collected data and the graphs, one to catch the data through the GET method of the HTTP protocol and to insert them into the database; another one with the parameter to connect to the MySQL database.

The structure is the following: at the begin I collected the parameters to connect to the database, located in the connect.php, then I prepared the MySQL statement, where I declared the query used to insert data inside the database. Also, inside the query, I used the GET method to collect data incoming from the ESP8266 & Bosch BME280 weather station. The PHP file is add_data.php and you can easily find it on my Gitlab repository.

In the visualisation web page, I first connect to the database, then I created a small table where I put the last data retrieved from the database using the right query. At this point, I created the graphs used to display the data. I decided to use the Chart.js javascript library to create them. The graphs are quite simpler, they show the last 24 hours lectures of all the data. The data to show inside the graphs are retrieved using the right queries and parsed into arrays. Then I printed them using the echo function inside the dataset for the graphs. Also, the pages automatically refresh every 60 seconds and show the last data.

You can take a look to the final result HERE.

Final Installation

At this point, we can finalize the project. I decided to put all the hardware equipment inside a tiny IP67 box. I soldered all the wires and I covered them with waterproofing membranes, in order to obtain a waterproof solution.  In order to make the temperature measurement work properly, I created a solar shield using THIS tutorial. It works really well! Otherwise, you could buy some ready to use solution but they cost too much.

At the end, I painted the structure with a lucid white color, in order to improve the reflectivity of the device. Finally, I put the solar panel over the solar shield and I fix the whole ESP8266 Weather Station on a pole at 170 centimeter of height from the soil. Here you can find some shots of the final installation.

[gallery type="slideshow" size="large" ids="306,305,304"]

After more than four months of activity with many weather conditions (from heavy rain to snowfall and ice, with also 10°C under zero), the system is still working fine.

Accuracy

The weather station is quite accurate. I have an analog weather station near the Wi-Fi ESP8266 & Bosch BME280 solution and I often compare the results. I can say that, after four months of activity, the pressure is really accurate, while the temperature during the day light is overestimated by 1-1.5 °C. That's due to the quality of the sunlight shelter, since during the night the temperature values between the ESP8266 station and the analog station are the same.

I noticed only an issue: during heavy rain or fog, the Bosch BME280 overestimate the humidity to 100%. When the real humidity is above 95-96%, the ESP8266 reads 100%. Unfortunately I can't fix it.

For this tutorial it's all. I hope you enjoy it and I remember you that you can find all my codes HERE. Next step? make a LoRaWAN weather station to place in the country side.

L'articolo How to build a Wi-Fi solar weather station with an ESP8266 and a Bosch BME280 sensor proviene da Emanuele Pagliari.