1. Learning Centre
  2. Announcements @ AllThingsTalk

Considerations within Wireless Sensor Networks

Be aware how you use sensors, as they may show different or faulty data.

Introduction

First to mention, as we live in the Industry 4.0 era, or better said, the Information Age, more and more data are collected every day. When talking about security and privacy on one side, there are increasing concerns regarding sensor network on the other side. Why should we even use such networks?

Well, everything is interconnected. Even as we think it isn't, we should dig deeper. Try to look at the IT network for example. Internet on which you are reading this article is created from OSI model [1]. That means the very text is remotely "called" from some servers and that presents an Application layer; the very structure of the web-page is Presentation layer, and all the way through the PC, router, switches, cables and the very data as bits - is the OSI model. Behind that structure, you can take the second example: the very Nature. If you take the apple, it is an Application layer, everything you see on the tree and the tree itself is the Presentation layer, all the way down through leaves, branches, roots, to the soil, water, photosynthesis and the very seed from where everything was created. Now, not to get too deep or long, let me explain how I see this matter within IoT world.

What is a Wireless Sensor Network?

Wireless Sensor Network (WSN) are consist of small, often autonomous devices located over a wide area that can sense and report several parameters about their surroundings [2], such as environmental ones (humidity, temperature, vibrations, etc.). These parameters are quite important nowadays, when pollution took its effect in sudden catastrophic events such as floods, fires, earthquakes, etc. Also, we see climate change impacts in agriculture, where long droughts increase the severity of mudslides, as water can't penetrate into the soil. Therefore, measuring lots of environmental parameters with IoT devices is the reality that many developers, makers and enthusiasts are trying to implement within their existing or completely new business value proposals.

Let's mention a bit about devices herein. They are the "core" of sensor data retrieval. Consisting of battery power source (maybe with the help of solar or some other energy harvesting sources), antenna for radio communication (LoRa, NB-IoT, Sigfox, etc.), PCB that holds all the components, device housing (often IP66) and the very brain of device - microcontroller (MCU). Within everything mentioned in the previous sentence, MCU is the part where data from sensor(s) are gathered, maybe structured in some format with basic onboard processing and kept on the device / or sent to a server for the more detailed post-processing. But, the very point where data is post-processed, whether on Cloud or at physical presence in-house, is the crucial point to be aware of. Even if post-processed data can be super quality, some simple mistakes can affect data quality ingested from sensors, and those can ruin the whole business value proposition. Let's explore why.

Considerations when deploying sensors

Although you can use the tested sensors that you know they are calibrated and show the almost exact values while testing them in controlled environment(s), that may not be the case while putting them into the real-world, harsh and unprecedented nature's behaviour. Let me tell you a short story, about my experience with two same sensors, that have the good level of quality. 

I designed two use cases of measuring humidity and temperature outside, as this was needed for the project purposes. I tested 10 of same sensors for those parameters and it was obvious they are well calibrated and ready to be connected to Arduino MKRFox 1200 and recorded data will be sent to the Cloud, where visualisation would take place. That was great, until I placed them outside and got different measurements. Firstly, I thought there were some issues in the code, but after all, it's the same one, just the second code was slightly modified with the MCU's sleep mode interval and the code structure. So, that wasn't the issue. I decided to leave them "as is" for couple of days and to see what's happening. Once, when I was looking at the second device and related data measurements, I noticed that humidity and temperature was at the almost same level, around some 30 (degrees Celsius and percentage for the humidity), which was not the case on the first sensor data. I took a look on the sensor and it was good, working, not damaged. Then, I decided to put it into the house and to see what will happen next. Temperature and humidity got back to the "more usual" ratio (as it was fine autumn day - not too hot and not too cold). Then I realised the issue! When the first device was only 3 meters away, it was in the shadow at that time, away from the sun! The first one was under direct sunlight and even on the metal pad. The very reason of different reading was just the placement point of sensors. 

The Solution: Cluster of sensors

When Wireless Sensor Networks are deployed over a target area to supervise certain phenomena of interest, each node takes readings from the local environment, processes and transmits a certain number of packets containing the sensed data to the Central Unit (CU). From several to thousands of sensors connected into a desired cluster, we can have two common modalities [3]: unscheduled and scheduled-based transmissions. In a cluster-based architecture, there are two distinct phases:

  • The cluster formation phase, where all the active nodes transmit a control packet directed to the sink node in order to be part of the cluster. 
  • The steady state phase, where all the nodes in the system transmit their data packets to a cluster head (CH), which in turn transmits an aggregated data packet to the sink node.

It is important to be aware, if you are looking to design or use cluster-based systems, related networks have two aspects that are largely overlooked: the transmission probability used during the cluster formation phase and the way in which cluster heads (central units) are selected. Both of these issues have an important impact on the performance of the system. Solution for these are found in three different transmission probability strategies: optimal, fixed and adaptive for cluster formation phase, and intelligent schemes based on the fuzzy C-means and k-medoids algorithms for cluster heads. More details about this research can be read here.

As more companies are being interested in IoT and how to create their business solutions, one of the hardest issue is developing the sensor networks to work efficiently. There are many aspects why IoT is not yet used as it was projected in previous years, especially when we come to clustered networks. If you are going to delve into such business, make sure you have firstly one sensor work good, then connecting a small network and expanding it to the large area. 

Conclusion

Issues addressed and explained in this article are just some of the unprecedented sea of IoT tricky behaviour. Even when you think that your sensor devices work good, take care the environment in which you are placing them. Take a good understanding of my example; it is a simple issue, but no one can think of all use cases that can be tested even in laboratory (controlled) environment, let alone when you place it outside. But don't be discouraged, every and each lesson is highly valuable, and learning upon that you will build your success step by step, nevertheless how hard it may seems sometimes. 

If you have a specific idea or project in IoT that you would like to share, don't hesitate to contact us directly.

And a good advice: Sharing IoT data and projects are vital for your growth