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.

Teacher Notes

Teachers! Did you use this instructable in your classroom?
Add a Teacher Note to share how you incorporated it into your lesson.

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.


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 ...


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.


  • 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() {
  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);
//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

2 People Made This Project!


  • Indoor Lighting Contest

    Indoor Lighting Contest
  • Make It Fly Challenge

    Make It Fly Challenge
  • Growing Beyond Earth Maker Contest

    Growing Beyond Earth Maker Contest

58 Discussions


4 weeks 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.

8 replies

Reply 4 weeks ago

Yes, you can use also the DHT22 sensor, with the DHTStable library you can use also other sensors. The DHT11 is not suitable for measuring temperatures below zero degrees.


Reply 25 days ago

Since I don't have a way to program the ATtiny85 and don't like the idea of building or buying a programmer for this project until I know I can integrate the sensors into Home Assistant, would something like https://amzn.to/2LFPY7q work instead of the bare chips (yes, I knmow I'm paying for the convenience).


Reply 24 days ago

The Digispark board it's easy to program and it is easy to upload sketches on it but for this to happen there are downsides... The available flash memory is only 6kb (from 8kb). The sketch I am using will not fit in 6kb (6734 bytes but 6012 bytes available). Also the current consumption can not be reduced to 4.7 μAmp because there are some other component on the board which use some current: led's, stabilizer, zenner's... Lastly, I think the digispark board is a little bit big for the battery holders that I'm using in my project. As for the integration with Home Assistant there is quite a bit a coding work to do...


Reply 24 days ago

Then I'll get the bare chips and a cheap programmer. As for the Home Assistant integration, my 433mhz receiver is a Sonoff bridge running Tasmota so I should be able to handle that fairly easily.


Reply 22 days ago

I have my list of items from Amazon together (I know its more expensive but at least its all from one website, plus I have prime). I'll be updating my blog with progress (https://smccloud.com/). What antenna are you using in your sensors, it isn't listed.


Reply 4 weeks ago

DHT22 works the same way as DHT11 and is much better and stable.
DHT11's are unstable and stops working after 2-3 years. Ok for hobby use and testing. Look for BME280 made by Bosch. They measure temp,humidity and air pressure.


4 weeks ago

I would like you to know that at least in the United States, the 70cm Amateur Radio band extends from 420 to 450 MHz. Using the frequency 433 MHz in the U.S. requires an Amateur Radio Operator's License. If you put such a system together don't be surprised if letters from the Federal Communications Commission arrive or Amateur Radio Operators come knocking on your door!! Don't say we didn't tell you ahead of time!

1 reply

4 weeks ago

Be very careful if using any transmitters in the 433MHz band. Why? This radio spectrum is allocated for Amateur Radio use which requires a license in most/all countries. Details of the allocation in Europe can be found at:

In the U.S. the FCC website or another good source is ARRL.org. Allocations are often granted as shared with primary and secondary users. Such is the case in the U.S. with Amatuers sharing the space with radio location services. Specifically, amateurs (or "hams" as they are more commonly known) use this spectrum for satellite communication, voice and data transmission. The same may be true in other parts of the world, such as noted in the above URL.

The fact that someone may obtain transmitters easily from sites like eBay or others does NOT grant any privileges to anyone to use the transmitters. Again, these may be shared radio spectrum so don't be upset if your project experiences interference from licensed users. In such cases it will be you who is out of luck. Aside from the humorous stories where a DIYer sets up a remote to control the lights in his backyard but also opens all of the garage doors in the neighborhood, there are incidents where (in the U.S.) the FCC steps in and slaps a $10,000 fine to the belligerent guy knowingly causing interference who refuses to back down.

All I'm saying is that you need to be aware of the situation before hitting the power switch.

3 replies

Reply 4 weeks ago

This is not an issue in Europe since most weather stations , car keys , lamp switches etc
are using 433.92 MHz at less than 100mW.


Reply 4 weeks ago

Do you need a license for a car key fob, whats the difference? I think it may be the transmitting power....


Reply 4 weeks ago

You are perfectly right, I have also drawn attention to some aspects of using the 433MHz frequency in my article.


4 weeks ago

Fantastic work and amazing documentation. Thank you so much for sharing this interesting project. Especially for citing the theoretical articles. As an academic it is very exciting to see the scientific articles being referred to so I can dig deeper!! I will read them too asap. Fantastic work.

1 reply

Question 4 weeks ago

I installed the library DHT-sensor-library-master from Github and I get the following errors for the ATtiny85 Tx.
Is this the library I should use?

C:\Users\user\AppData\Local\Temp\arduino_modified_sketch_408022\sketch_jul19b.ino:2:92: fatal error: dht.h: No such file or directory

#include <dht.h> // https://github.com/RobTillaart/Arduino/tree/maste...

2 answers

Answer 4 weeks ago

Yes, that is the library I have used in my project. It seems your library does not installed correctly, or maybe you have another dht library with the same dht.h header and they are in conflict?


Reply 4 weeks ago

I also have an error in the Tx library file as follows.

C:\Users\user\Dropbox\Arduino\libraries\rc-switch-protocollessreceiver\RCSwitch.cpp:550:32: error: 'digitalPinToInterrupt' was not declared in this scope

if (digitalPinToInterrupt(i) == interrupt) {