Low Cost Wireless Sensor Network on 433MHz Band

48,094

405

77

Introduction: Low Cost Wireless Sensor Network on 433MHz Band

Many thanks to Teresa Rajba for kindly giving me her acceptance to use data from their publications in this article.

*In the image above - the five sensor-sender units that I used for testing

What are wireless sensor networks?

A simple definition would be: the wireless sensor networks refers to a group of electronic devices distributed on a certain area for monitoring and recording environmental data, that are wirelessly transmitted to a central location to be processed and stored.

Nowadays Wireless Sensor Networks can be used in several ways, bellow are just a few examples:

  • Areas of ecological surveillance of forests, rivers, lakes, seas and oceans;
  • Possibility to alert in case o terrorist, chemical, biological, epidemic attacks;
  • Monitoring systems for children, elderly people, patients or people with special needs;
  • Surveillance systems in agriculture and greenhouses;
  • Weather-Forecast monitoring system;
  • Surveillance of city traffic, schools, car parks;

And many, many other applications.

In this paper I want to show the results of an experiment with wireless sensor networks that have been used for monitoring temperature and humidity data, with a slow and relatively predictable variation. For this experiment I chose to use sensor-senders that I built by my own using affordable modules. The receiver is also DIY, the communication is unidirectional (on the 433 MHz radio band), meaning that the sensors only transmit the data and the central location only receives. There is no communication between sensors and from receiver to sensors.

But why choosing to use multiple transmitters and only one receiver? Obviously the first reason would be “making it simple”. The simpler is the assembling, the less likely it is to fail, and it definitely is much easier to repair and replace the single components in case of malfunctions. Power consumption is also lower, the batteries will last longer (sensors will only consume while monitoring and receiving, the rest of the time the device will be in deep sleep mode). The fact that it is simple makes the device also cheap. Another aspect to keep in mind is the coverage area. Why? It is much easier to build and use a sensitive receiver than to have a sensitive receiver and a powerful transmitter at both the sensors and the central module (this is necessary for a good bidirectional communication). With a sensitive and good-quality receiver it is possible to receive data from a long distance, but emitting data for the same distance requires high emission power and this comes with high costs, electricity consumption and (let’s not forget) the possibility to overrun the legal maximum transmitter power on the 433 MHz band. By using a medium-quality receiver, cheap but with a high-quality antenna (even DIY) and cheap transmitters with a good-quality antenna, we can achieve excellent results at a fraction of the cost of existing wireless sensor networks.

Step 1: Theoretical Considerations

The idea of building a wireless sensor network for monitoring temperature and humidity of air and soil in different areas of a greenhouse came into my mind a long time ago, almost 10 years. I wanted to build a 1-wire network and to use 1-wire temperature and humidity sensors. Unfortunately, 10 years ago humidity sensors were rare and expensive (although temperature sensors were widespread) and since spreading wires all over the greenhouse didn’t seem an option I gave up on the idea pretty quickly.

However, now the situation has radically changed. We are able to find cheap and good-quality sensors (temperature and humidity), and we also have access to cheap transmitters and receivers on the 433 MHz band. There is only one problem: if we have more sensors (let’s say 20) how do we solve the collisions (please keep in mind that this is a one-way communication), meaning, overlapping the emission of 2 or more sensors? While searching for a possible solution I came across this very interesting papers:

Wireless sensor converge cast based on random operations procedure - by RAJBA, T. and RAJBA, S.

and

The probability of collisions in Wireless Sensor Network with random sending - by RAJBA S. and RAJBA. T

Basically, the authors show us that the probability of collisions in a wireless sensor network can be calculated if the packets are emitted at certain time points according to a poissonian (exponential) distribution.

An extract from the above paper lists the characteristics of the studied network.

  • quite a large number of sensor-sender units N;
  • sensor-sender units remain completely independent and switching them on or off is of no influence on network operation;
  • all sensor-sender units (or a part of them) may be mobile provided that they are located within the radio range of the receiving station;
  • the slowly changing physical parameters are subjected to measurements what means there is no need to transmit the data very frequently ( e.g. every several minutes or several dozens of minutes);
  • the transmission is of one-way type, i.e. from the sensor-sender unit up to the receiving point at T average time intervals. Information is transmitted in the protocol at tp duration time;
  • any selected sensor starts transmitting randomly at Poisson times. PASTA (Poisson Arrivals See Time Averages) will be used to justify the sending of probes at Poisson epochs;
  • all sensor-sender units remain randomly independent and they will transmit the information at a randomly selected moment of time of tp duration and of T average time of repetition;
  • if one or more sensors start transmitting while the protocol of tp duration is being transmitted from another sensor, such a situation is called the collision. Collision makes it impossible for central base station to receive the information in a correct way.

It fits almost perfectly with the sensor network I want to test ...

Almost.

I’m not saying that I completely understood the mathematics in the paper, but on the basis of the data presented and on the conclusions I have been able to understand a bit what it is about. The only thing is that a value used in the paper made me worried a little :). It is the variable tp - duration of the data transmission that is assumed to be 3.2x10-5 s. So the transmission time of the collected data would be 3.2 us! This can not be done on the 433 MHz band. I want to use either the rcswitch or the radiohead to program the transmitter sensors. Studying the codes of the two libraries, I came to the conclusion that the smallest transmission time would be 20ms, well above the value of 3.2 us. With the 2.4 GHz transmitters, it's possible tp time so small… but that's another story.

If we apply the formula proposed by the authors of this paper the result will be:

Initial data( an example):

  • Number of sensors N=20;
  • Data transmission duration tp=20x10-3 s (0.020s)
  • Average transmission interval T=180s

The formula:

Probability of collision on T interval is

if we take into account the initial data the probability of collision on T interval will be 0.043519

This value, which indicates the likelihood of having 4.35 collisions per 100 measurements is, in my opinion, quite good. The probability could improve if we increase the average transmission time, so at a value of 300s we would have a probability of 0.026332, ie 2.6 collisions per 100 measurements. If we consider that we can expect packet data loss anyway during the system's operation (depending on weather conditions for example) then this number is really excellent.

I wanted to do a simulation of this type of network but also a sort of a design assistant, so I made a small program in C, you can find the source code on github (also a compiled binary that is running in windows command line - release).

Input data:

  • sensor_number - the number of sensors on the network;
  • measurements_number - number of measurements to simulate;
  • average_transmission_interval -average time between successive data transmissions;
  • transmission_time - the effective duration of data transmission.

Output:

  • the calculated maximum measurement time;
  • the list of collisions between two sensors;
  • number of collisions;
  • theoretical probability of the collisions.

The results are quite interesting :)

Enough with the theory, I would not want to insist more on the theoretical part, the articles and the source code are quite eloquent, so I better go to the practical, effective implementation of the wireless sensor network and to the test results .

Step 2: Practical Implementation - the Hardware

For transmitter-sensors we will need the following components:

Total 3.63 $;

The receiver used for the tests is an Arduino UNO (only for testing) and a H3V4F receiving module (0.66$) with a cheap arc antenna (0.32$).

Sensor-sender schematics

The transmitter-sensor units are powered with 3xAA, 1.5v batteries (in the fourth compartment of the battery holder there is the electronic assembly). As you can see the transmitter’s power supply and the temperature-humidity sensor is hooked to the PB0 pin of the microcontroller (the transmitter and the sensor are powered when the pin is set to HIGH). So when the microcontroller is in deep-sleep mode, it can reach a 4.7uA current consumption. Considering that the wake-up time of the transmitter-sensor would be about 3s (measurement, transmission etc.) and the average time between transmissions of 180s (as the example in the previous chapter), the batteries should resist quite a lot. With some good quality alkaline batteries (i.e. 2000 mAh), autonomy could be over 10 months as calculated on omnicalculator.com (where the total current consumption is: sensor - 1.5mA, transmitter module - 3.5mA and ATtiny85 microcontroller - 5mA, total 10mA).

In the photo below you can see the almost finished sensor-sender assembly.

Below is the photo of the test receiver unit.

Step 3: Practical Implementation - Software

The software uploaded running to the attiny85 microcontroller, the main component of the sensor-sender units, has the purpose to read the data provided by the sensor, convert it to be transmitted by radio, and transmit it within Poisson time frames (exponential distribution or PASTA - Poisson Arrivals See Time Averages). Also, by using a simple function, it monitors the status of the batteries and gives a warning if the required voltage for the sensor is no longer provided. Source code is available on github. The code for the test receiver is very simple I'm posting it below.

//modified rcswitch library from https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver<br>// the code is a modified version from examples of the original rcswitch library
#include <rcswitch.h>
RCSwitch mySwitch = RCSwitch();
unsigned long data = 0;
void setup() {
  Serial.begin(9600);
  mySwitch.enableReceive(0);  // Receiver on interrupt 0 => that is pin #2
}
void loop() {
  if (mySwitch.available()) {
    unsigned long data = mySwitch.getReceivedValue();
    //output(mySwitch.getReceivedValue(), mySwitch.getReceivedBitlength(), mySwitch.getReceivedDelay(), mySwitch.getReceivedRawdata(),mySwitch.getReceivedProtocol());
    int humidity = bitExtracted(data, 7, 1); //less signifiant 7bits from position 1 - rightmost first bit
    int temperature = bitExtracted(data, 7, 8); // next 7bits from position 8 to the right and so on
    int v_min = bitExtracted(data, 1, 15); 
    int packet_id = bitExtracted(data, 3, 16); //3bits - 8 packet id's from 0 to 7
    int sensor_id = bitExtracted(data, 6, 19); //6bit for 64 sensor ID's - total 24 bits  Serial.print(sensor_id);Serial.print(",");Serial.print(packet_id);Serial.print(",");Serial.print(temperature);Serial.print(",");Serial.print(humidity);
    Serial.println();
    mySwitch.resetAvailable(); 
  }
}
//code from https://www.geeksforgeeks.org/extract-k-bits-given-position-number/
int bitExtracted(unsigned long number, int k, int p) 
{ 
    return (((1 << k) - 1) & (number >> (p - 1))); 
}

I've tried to include as many comments as possible to make thing easier to understand.

For debugging I used the softwareserial library and the attiny85 development board with the USBasp programmer(see also my instructable about this). The serial link has been made with Serial to TTL converter(with a PL2303 chip) connected to the bent pins (3 and 4) of the development board (see picture below). All of this has been of an invaluable help to complete the code.

Step 4: Test Results

I have created 5 sensor-sender units that collect and send values measured by the DHT11 sensors. I recorded and saved measurements, with the help of the test receiver and a terminal emulation program (foxterm), during three days. I chose a 48 hour interval for study. I was not necessarily interested in the measured values (sensor 2, for example, it shows me wrong values) but in the number of collisions. In addition, the sensors were placed very close (at 4-5 m) by the receiver to eliminate other causes of packets loss. The test results have been saved in a cvs file and uploaded (look at the file below). I also uploaded an excel file based on this csv file. I took some screenshots to show you how a collision looks like (in my tests of course), I added comments as well to each screenshot.

You may wonder why I did not use a data loader service for example ThingSpeak. The fact is that I have many records, many sensors and data coming often at irregular intervals, and online IoT services only allow data at a certain number of sensors and only at fairly large intervals. I'm thinking in the future to install and configure my own IoT server.

In the end, 4598 measurements on 5 sensor-sender units (aprox. 920/sensor) resulted in a total of 5 collisions for a period of 48 hours (0.5435 collisions/100 measurements). Doing some math (using the wsn_test program with initial data: 5 sensors, average time 180s, transmission time 110 ms) collision probability would be 0.015185 (1.52 collisions/100 measurements). The practical results is even better then the theoretical results isn't it ? :)

Anyway there are also 18 packets lost in this period, so the collisions does not really matter too much in this regard. Of course the test should take place over a longer period of time to get the most conclusive results but in my opinion is a success even in this conditions and fully confirms the theoretical assumptions.

Step 5: Final Thoughts

Immediate application

In a large greenhouse several crops are grown. If the irrigation is manually made with no climate monitoring, without any automation, without data records there is a risk of over or under irrigation and also the water consumption is high, there is no evidence for water consumption optimization, there are risk for crops in general. To avoid this, we can use a wireless sensor network :)

Temperature sensors, air humidity sensors, soil humidity sensors can be placed all around in the greenhouse and with the help of transmitted data several actions can be made: start-stop electric valves for letting the water flow where is needed, start-stop electric fans to reduce temperature in different areas, start-stop heaters as needed and all the data can be archived for future analysis. Also, the system can provide a web interface that is accessible everywhere and email or SMS alarms in case of abnormal condition.

What's next?

  • Testing with a larger number of sensors;
  • Real-time testing with remote sensors in the coverage area;
  • Installing and configuring a local IoT server (on a Raspberry Pi for example);
  • Tests also with transmitter(transceiver)-sensors on 2.4Ghz.

so... to be continued... :)

DISCLAIMER : Using the 433MHz frequency band in your region may be subject to radio frequency regulations. Please check your legality before trying this project.

Sensors Contest

Runner Up in the
Sensors Contest

3 People Made This Project!

Recommendations

  • The 1000th Contest

    The 1000th Contest
  • Battery Powered Contest

    Battery Powered Contest
  • Hand Tools Only Challenge

    Hand Tools Only Challenge

77 Discussions

0
Phil_S
Phil_S

10 months ago

Nice project and I like the use of the Attiny85.
Didn't read in detail, but the use of randomness to avoid data collisions must be a bit suspect.
Some form of coding (Manchester for example) would help
I wonder if you really save a lot in the long run.
Proprietry systems like Digi XBee come with all networking built in and the new Series 3 have MicroPython on board so no need for an external microcontroller. At about £15 for the long range Pro version, they seem to me to be good value, plus you get the universal Zigbee application layer.
You can flash the firmware for any of the Digi legacy versions and I use them for virtual wire communication.
The excellent Digi configuration software makes setting up fairly straightforward.

0
a-morpheus
a-morpheus

Reply 9 months ago

can you send a link to the £15 item that you reference? I only find much more expensive ones.

0
a-morpheus
a-morpheus

Reply 9 months ago

thanks! It looks like it uses about 10x (?) more power though, which would be a big disadvantage

0
Phil_S
Phil_S

Reply 9 months ago

Not a problem, just sleep it.
The trade off is a much easier setup and an API which is an industry standard.
I use 433-MHz modules as well, but by the time I've added encoders and decoders, it's no contest.
Xbees come with builtin encryption, automatic channel selection and so on.
Throw in three types of firmware, easy to configure sleep for end devices like remote meters, plus Bluetooth and MicroPython, it's good value.
I run XBees with a single AA Lithium @ 3.6-V and they run for a long time (years)

0
a-morpheus
a-morpheus

Reply 8 months ago

I've been thinking about it more and maybe the Wemos D1 mini (not Pro since that's overkill) would be a better solution. I realized I'll be inside a large sort of factory space and having a wifi hub somewhere (e.g. Raspberry Pi Zero W) is an option and I don't have to have independent transmitter-receiver systems. The problem with the Digi XBee3 Pro 9XB3-24Z8UM is it's about $20 per unit. The D1 mini is about 10 times less at $2. I would like to have the option of say, 10 sensor stations and so that's $200 vs. $20...a real consideration. The D1 mini apparently consumes 77 microAmps in deep sleep, https://www.element14.com/community/people/neilk/blog/2019/02/14/investigating-the-power-consumption-of-a-wemos-d1-mini-esp8266, so I guess if it can shutdown the whole sensor station when sleeping and only measure and transmit briefly (not sure how long that 'brief' will need to be yet) then a battery pack could also last a long time. ?

0
andrei.erdei
andrei.erdei

Reply 8 months ago

I am also thinking to go with the esp8266 but with the esp8285 module. This module has less extra electronics (ch340) to consume extra power so you can go bellow the 77 uA current consumption in deep sleep. And it also cheaper ($1.5) then the Wemos D1 mini. It is true that it has less inputs but for two or three sensors there is enough.

0
a-morpheus
a-morpheus

Reply 8 months ago

that's interesting...I'll have to look into the esp8285 too.

0
pgs070947
pgs070947

Reply 8 months ago

It's a trade off between cost and convenience.
When I first dabbled with sensor networks, there wasn't the choice of hardware that there is now.
The Espressif stuff has really taken off and I am now trying the Sonoff modules, but so far, they have a lot of limitations without some serious hacking. XBees have digitals and analogs that are easy to set up, whereas the Sonoff (ESP8266) takes time. What I do like though is being able to control things through an application on the phone.
Whn you compare even the Digi stuff against the commercial (NEST, Hive, Philips) offerings, Xbee looks cheap. What XBee does very nicely is transmitting serial data, like a wired system.
Given a choice, though, I would always hardwire sensors. I use Maxim/Dallas One Wire as well.
As far as brief transmissions go, the XBee will do do a complete frame or packet in milliseconds, plus you get acknowledgements, retries and encryption. Plus by meshing, the system gets more robust by adding more nodes.
It might be possible to use the low cost wireless network in conjunction with a few XBees

0
myk3yth
myk3yth

10 months ago

I've got a lot of LoRa modules in various frequencies.

I like the idea of central computing, just using the LoRa to transmit the data back to a base station for collection.

The power requirements are low and thus the use of a small solar panel and battery would suffice.

Good instructable!

0
ragothaman.ramanujam
ragothaman.ramanujam

11 months ago on Step 5

Thanks for publishing this wonderful project. If the sensor output is in MQTT, it will be versatile one with options like GUI dashboard and data manipulation options. Please consider.

0
andrei.erdei
andrei.erdei

Reply 11 months ago

Thank you for your tips!

0
moonguru
moonguru

1 year ago

With the receive side, I got interference from a commercial
indoor/outdoor wireless thermometer. I also got interference from a
wireless doorbell. However, a little bit of s/w got rid of most interference for my system based on your approach making it quite usable. Systems like this would be fine in a greenhouse isolated from these interfering sources. As RadioHead doesn't seem to
work with an ATtiny85, I cannot compare it with RCSwitch. RadioHead may be better at rejecting interfering signals?
Incidently, I tried a system based on a DS18B20 and using your approach but just using temperature and sensor ID information (humidity not needed) and works good.

2
andrei.erdei
andrei.erdei

Reply 1 year ago

I do not think that the interferences can be solved using another library. The major cause for the interferences is the transmitters-receiver modulation, the ASK radio modules are very cheap but their major drawback is the low immunity to interferences- https://www.rfwireless-world.com/Terminology/Advan...
For better results radio modules with FSK modulation can be used but the price range is quite different...
Anyway my goal was to put in practice a low cost sensor network and to prove an interesting mathematical theory... it looks like I succeeded... :)
Maybe you can show that you "make this project" above?

0
wolliswo
wolliswo

1 year ago

Ganz tolle Geschichte,

dank der Google Übersetzung auf deutsch.
Ich bin zwar kein Fachmann aber der guten Beschreibung nach traue ich mir sogar zu das System für meine Region nach zu bauen.
In De ist die Funkfrequenz 888 mherz glaube ich frei zu benutzten.

Lg
wowo

0
andrei.erdei
andrei.erdei

Reply 1 year ago

Viel mehr Erfolg !!! - same google translate :)

0
moonguru
moonguru

1 year ago

I am very impressed with this project, so well documented and explained. I notice in your Tx circuit there is a 5.1k resistor missing from the data line of the DHT11 to Vcc?
I would like to substitute the DHT12 for the DHT11 so that temperatures below Zero can be measured as well as getting improved accuracy. As the DHT12 uses an I2C bus with SDA and SCL compared to the DHT11 which just uses a single serial line, would there be much change to the software to suit the ATtiny85? If this is not possible then maybe I should try a DS18B20 as I only require temperature and not humidity?

0
andrei.erdei
andrei.erdei

Reply 1 year ago

About the resistor...I used dht11 modules with the resistor already soldered...

0
andrei.erdei
andrei.erdei

Reply 1 year ago

Why not use DHT22? It also measures temperatures below zero and needs little modification in the software?

1
ShaunM57
ShaunM57

1 year ago

Do you think the DHT22 would work instead of the DHT11? I am thinking of making one of these for my garage and in the Minnesota winter I'm guessing it gets below the 0C rating of the DHT11.