This is a Multidisciplinary IoT project undertaken at Haaga-Helia University of Applied Sciences (terokarvinen.com), conducted in the fall of 2018. The project instructor is Tero Karvinen.
The project is also available in Github (BSD 3-Clause license).
The goal of the project is to design and build a IoT device that can send and receive sensor data utilizing LoRa.
The device should be able to function in Finnish outdoors climate for an extended period, acknowledging the seasonal changes.
LoRa stands for Long Range. It’s a digital wireless data communication technology that uses license-free sub-gigahertz radio frequency. LoRa is designed to enable very long transmission distances (more than 3 kilometers, even 10 kilometers) with low power consumption. This is ideal for IoT devices that have to function in an enviroment with limited or no internet connection using minimal power. This technologie can be used in two ways. Either as point-to-point connection between devices or LoRaWAN (Long Range Wide Area Network) which can connect multiple devices on the same network. At the moment Digita offers a 868mzh LoRaWAN network in Finland.
This project has a spiritual predecessor Nuotiovahti that has detailed some requirements that this project aims accomplish.
Note that this is a separate project, that does try to recreate some of the results that the Nuotiovahti project did, but with using different technologies. The idea for the sensor data transmited is from this project, a chip that can optically detect flame by the light emited by the fire.
The purpose of all this is to provide an alternative solution for a small sensor, that can be used in outdoors like conditions where there are limitations on internet access and power delivery. It should be designed to require no maintenance during its power cycle.
The aim is to make the IoT device affordable so it can be deployed cheaply and if needed, in great numbers.
This project has a few first:
My first arduino project
My first IoT project
My first C++ programming project
First project in Haaga-Helia to utilize LoRa
Why the name Lora Tocsin?
Lora of course reflects the communication technology used. Tocsin is a French word meaning alarm bell or other signal sounded by a bell. Since the sensor is meant to detect flame, an idea of old school fire bells came to my mind. The word tocsin reflects this perfectly.
The requires the study of LoRa and how to utilize it, also C++ programming language has to understood in some extend to be able to program the IoT device. Since this projects has a lot of firsts, trial and error in the learning process has to be accepted. The project instructor gave great advice in the basic material needs to start the project. These are :
- Arduino Uno for prototyping
- NodeMCU ESP-32S for the production platform
Also needed are the flamesensor for producing data and a LoRa chip so the paltform can communicate using LoRa.
There are two publications that have been included in the project study materials:
The preliminary plan is that this project is going to be done in three phases :
- Prototyping and testing
- Production device assembly testing
- Outdoors testing
Project kickoff! Started by buying a Arduino development set. The project is not going to need all of the materials included but it has all the basics and also some extra to be used in future projects. The project instructor loaned me a few KY-026 flame sensors to try out. I have been doing basic studies and try outs with C++ and now its time to test the arduino board for the first time.
Installing the Arduino IDE was a project of its own. The project is using computers with Antergos operating system installed and at first install attempt there was errors with Java. I made sure that the java version in use was correct but could not get the Arduino IDE to start properly. After reading through the archwiki page of the subject, I got the program running without a hitch.
This dilemma comes around once in a while = READ THE MANUAL FIRST, BEFORE TRYING BLINDLY!
The fisrt test was just a basic blinking lights test, just to get the hang of it. Arduino seems pretty basic and easy to start of with. The manual inculded in the arduino development set proved useful.
The purpose of the second test was to try and use the flame sensor and output data if the sensor detects anything. This was a bit more complicated than the first test but eventually I got the thing to work. The sensor is quite sensitive to ambient light, especially with led lamps. This has to be tuned in the protyping process so hopelly only fire is detected.
The project workpace has moved from my home to the 3D lab in Haaga-Helia. The lab provides much better resources for the prototyping and is also a better working space than my kitchen table.
Also the materials have arrived!! ESP-32S and the new flame sensors came in the post. Just in the nick of time for the end of the first project week.
The testing of the new flame sensors didn’t prove to be that successful. The pin layout should be the same but the sensor does not produce the same results as with the KY-026 sensor. This needs more testing to determine if the sensors are flawed or is it just the coding.
So the flame sensors ended up being duds, ran the same test with the borrowed sensors and the new sensors and the end result was that the new ones didn’t produce the results that are needed. Ordered new ones, but until they arrive I have to stick with the ones that are borrowed. The LoRa modules have not arrived either, so until I have the necessary components I’l have to make use of my “spare time”.
This week I started testing the ESP-32S microcontroller, once I had gotten familiar with Arduino the transition was quite smooth.
I had problems connecting the ESP-32S to the Arduino IDE, the ESP-32S connects, but I cannot upload any code successfully to the board. When the board boots up, it just prints error messages when I tried doing just a basic blinking led light test. I have been using the Antergos operating system thus far in the project and after tinkering with the problem for a while, I decided to try using Ubuntu (since it has good support they say, please read further) to run the Arduino IDE to check if I get the same error. I also had a notion that my mind was running in circles around the problem and was getting me nowhere.
First things first, If using ESP-32S with Ubuntu DO NOT, I repeat, DO NOT install the Arduino IDE from the default Ubuntu repository. The version is old and you cannot install the necessary add-ons. The best practice is to install the Linux package straight from the source ( https://www.arduino.cc/en/Main/Software ).
I was able to run upload the code without a hitch, and the board functioned without problems. There were problems connecting to the device. It did connect eventually, but he wait was a bit long (1 minute). I noticed that by pressing down the ‘IO0’ (IOzero) button next to the reboot (‘EN’) button before and during the start of the upload, the connection time was minimized to a few seconds.
By the way, working with the ESP-32S using a breadboard saves a lot of time if you are testing or prototyping. You can even align the board numbers to meet the ESP-32S pin numbering. There are quite a lot of board blueprints available, but I found this on the most useful to work with, since it has the identical markings with the actual board.
Since I got this working on Ubuntu, I headed back to Antergos to get the same results. Using Arduino IDE with Arduino Uno in Antergos, the packages you basically need installed are:
- jre8-openjdk (jre10-openjdk works also)
ESP-32S needs a few additions to this, these are:
- python (preinstalled in my system)
- esptool.py (serial bootloader utility)
- ESP-32 board versions installed to Arduino IDE
I reinstalled all of them, except java and python. Once I did this, everything ran as smooth as with Ubuntu. (quick install script in github).
Since I don’t have The LoRa modules yet, I got the idea of testing and working with the build in wifi module. the idea being that if one microcontroller is a LoRa transmitter and the other a LoRa receiver, the reveicer should also be able the send the received data to a server via the internet, using wifi. This way you don’t have be depended on a serial connection and you just need stable, continues power to run the microcontroller. Why I’m not considering running the receiver on battery at this stage, is because wifi uses more energy that LoRa and since the receiver is running both, it would also run out of power faster than the transmitter.
The first successful test (there were a few unsuccessful ones, but those, where do with coding error and typos) was just to test login in to a wifi network and printing out the IP address. Feeling a bit encouraged by this, I decided on setting up the flame sensor to detect flame (or bright light) and sending the data to a temporary server using the WiFi connection. Setting the flame sensor was a breeze, now that I’m more familiar with the ESP-32S. I used a python SimpleHTTPServer a a test server and the data that is sent, is only ‘Fire=1’ (Fire=true).
HOUSTON! WE HAVE A CONNECTION!
This will be known as my first functioning IoT device!
I actually coded two different versions the previous test. One is using HTTP natively, the other makes a socket connection if you want to specify a port other that 80. Which one will go into production, is still undetermined.
I could say that this was a pretty good week for the project. I’m still missing two vital components, but was I was able to make progress that can be used at a later project stage.
I had an idea of designing and programming a webserver/interface for this project, to be used with the production model tests of the device. Not sure if I can rearrange my calendar for that.
The Lora modules and flame sensors are still in delivery, this is getting to be a bit frustrating.
This week I started to experiment with the power saving functionality of the ESP-32S. Since the LoRa transmitter only has two functions, detecting flame and sending the data of that detectiong, it doesn’t have to fully powered on all the time. The preliminary idea is that the LoRa transmitter sends out data every ten minutes. The sensor takes three sensor readings in a ten second time frame (one reading every 3.3 seconds) and determines the true/false value depending on that, this way there is a small space for error.
The conclusion based on this is that the transmitter needs to be fully operational only about 15 – 25 seconds every ten minutes (or 1.5 – 2.5 minutes every hour). The most effective way of saving saving power, especially if it’s running on battery.
In the ESP-32S the power saving mode is called ‘deep sleep’ mode. It’s built in, so I just had to figure out the coding and test the results.
NOTE! It seems that there is a bug that prevents ESP-32 devices from waking up, while in deep sleep mode, it is supposed to happen randomly.
I’m not sure if the ESP-32S model is affected by this problem, since this did not occur in my testing. In any case, I added a small delay in the setup() method that should counter this. Just to make sure.
The tests were carried out in two phases. First test was just to test that the functionality works, the second test integrated the deep sleep mode with the WiFi-flame sensor code I tested last week.
I found out that the deep sleep mode is quite close to a full reboot, the ESP-32S boots up every time from the start.
This integrated quite well with the WiFi-flame sensor module, I also refactored the code so the sensor takes the three readings in a ten second interval.
I also tested that the ESP-32S reconnects to the wifi network (or tries to), if a network connection is lost. The idea was to surround the ESP-32S with steel and aluminium foil, at first this sounded as a good idea.
The problem was that the WiFi connection was not cut or disturbed, believed it or not… After this I just rebooted my wireless access point and waited for the ESP-32S to loose connection and reconnect.
Since this is about all I can do with the programming before the LoRa chips arrive, I concentrated on searching for an optimal battery for the transmitter and an enclosure that could withstand the Finnish outdoors. This is actually more time consuming than it sounds.
After some time searching, I think I have found the most optimal candidate to be used as the production model battery. May I present the Saft 14500 lithium AA battery.
It has a nominal voltage of 3.6V, capacity of some 2.6 Ah (2600 mAh) and can operate in temperatures ranging from -60 C to +80 C. Ok, maybe the temperature is add talk, but at half that range it would still be a good choice. Winters in the southern part of Finland seldom go under -25 C. These cost about 5 – 6 € a pop so the price is in my comfort zone.
The ESP-32S can manage 6 – 20 voltage input power, the recommendation being 7 – 12 voltages. I was planning on running these in series using two (7.2 V) or three (10.8 V).
Also had some success in the enclosure hunting. The first idea was just a box that I can make watertight by using silicone and duck tape. Then I thought that there should be a possibility for servicing the device, like changing the batteries or such. so it needs to have a door of some sort. The price should also be reasonable, to keep the cost’s down.
This complicated thing a bit, but finally I found what I was looking for.
Now this is a Cocraft small utility box, it should be watertight, cold and shock resistant. Best of all, it has a door that shuts tight. There is quite a lot of extra space, if you consider the probable transmitter size (a little bigger than the setup in the picture). The reason for this space, is thermal insulation. I had the idea of using the Finnfoam XPS insulation, it’s used in houses but should meet my demands. The price is also OK, 8€ for a 30mmX600mmX2500mm board.
The box is also clear plastic, so the flame sensor should be able to take sensor readings through it.
I also started programming the server side for this project, which I mentioned last week. There is a separate Git repository for this -> LoRa-Server
I guess you can call this an OK week for the project, getting a bit anxious regarding the LoRa chips.
This has been a bit of a slow week in the project. Since I cannot experiment with the LoRa chips, the project progress has slowed down.
I started testing the enclosure this week. The main interest was the advertised water resistance and how much the clear plastic interferes with the flame sensor, if it’s located inside the enclosure. If the sensor has an adequate range while inside the box, this would make the assembly much easier.
I first had an idea of using colored powder for the water resistance test, but decided on ordinary baking flour since it’s cheaper and forms lumps if in contact with moisture. The idea was to close the case and dip it in water for an hour or so.
So the first test was not that successful. The box was under water for an hour and some lumps formed, this means that there is at least one leak in the box.
This got me thinking. Originally the box was compartmentalized, but I took the inner walling out to make more room. Perhaps the cast iron teapot filled with water used as a weight, pressed the center of the lid enough to cause a small leak from the sides. To get an answer for this, I performed the test again, but with the inner walls attached.
After another hour under water, the results were more reasurring.
This means that in the production device, inner walls are necessary. Luckily, the walls comes out individually so this room for some customization.
The next test was the sensor range, once inside the enclosure. I used the latest test code for this (the one with the flame sensor, wifi and sleep mode), This way I also can test if the plastic would, for some reason block wireless signals.
The power source used was a lithium 9V battery, Note that this is not the Saft battery mentioned earlier since this is just a test setup.
This test was performed in a dark room using a candle. The device was placed at close range (30cm) away from the candle, once the ‘TRUE’ signal was received by the temporary http server, the device was moved 10-20cm farther away. The final range I was able to get was 105cm, which is pretty good. This range has to be retested of course, when the outdoors testing begins. Since camp fires produce more Infrared light.
I would also like to make a small announcement..
THE LORA CHIPS HAVE ARRIVED!!!!!!!
Next week I can start building and testing LoRa. Needs some soldering but I think I will manage.
So at last the LoRa sensors are here, I can turn the development speed up a notch.
The LoRa chips don’t have any pins or antenna installed in them, so I have to start soldering them before the testing. It’s been about 20 years since I have done any soldering, so there was a “small” amount of stress involved in this process. I used the prototyping breadboard as a base, so the pins would align correctly. NOTE! The RFM95W chip’s pin holes are narrower than the ones used in the arduino (2.54), so there has to be a bit realigning when doing the soldering.
The LoRa connection can be made in two ways, point-to-point or LoRaWaN. In both cases a LoRa sync word is used, so the receiver can determine on what package to accept. With point-to-point you are bound by the transmission range available between the two points, this can be up to 10km. On LoRaWaN the limit is only the available network in use, in the Helsinki area that is quite large. To use LoRaWaN you need a network provider, in my case Digita.
As far as I know, you can only use either one technique.
Note that point-to-point connection does not mean that only two devices can communicate with one another, since the receiver and transmitter use the same sync word, the sync word can be same in multiple transmitters.
This is the idea to be used in this project, I intend to use point-to-point connections between the devices. Once this has been tested and found viable, I will consider using LoRaWan for the communication if there is time left. I still have extra parts, so this could be done in the testing phase.
For this phase of the project, I followed the instructions from RandomNerdTutorials
The tools and equipment used for this were:
- Soldering iron (I have an old one, have to buy a new one for the production version soldering)
- Solder (with lead)
- Desoldering pump
- A stand with a magnifier glass and clippers
- A lot of patience.
I have the production antennas in order, but they did not arrive for the first soldering session. This time I had to use a makeshift antenna. This can be done by soldering any conductive wire inside, as long as the length is in accordance with the target frequency. In this case 868mhz needed 86,3 mm of wire.
I’m quite surprised that everything soldered nicely in the first run, only once I had to use a desolder pump to correct a mistake, in which I managed to solder two pins together….
I did this two times since the transmitter and receiver need their own LoRa chips. Once both chips were soldered, installed and wired, there was only initial testing left.
Before you can add the Lora functionality to Arduino IDE, you must add a new library. This can be done from the Arduino IDE top panel = Sketch -> Include library -> Manage library. From there do a search using the key phrase ‘Lora’. I used the LoRa library by Sandeep Mistry (version 0.5.0).
Once the test code was written, I performed the first connection test.
This is actually surprising, since it’s the first test. The signal strength is also excellent. The distance in this test is only about 50 cm, so it should be good.
So the next day things became a bit complicated. I was planning on starting to build the preliminary production code, but I started retesting the devices. It seems that everything didn’t go as planned. At first the receiver could not receive the packages send by the transmitter, the code had not changed so I decided to change the lore chips between the ESP-32S devices to troubleshoot the problem. Once the transmitter sent the message, I found a possible reason for the problem.
The message was scrambled and signal strength was worse than before. It turned out that the antenna in the transmitter chip had malfunctioned, probably because of bad soldering. I resoldered the antenna, and the connection was ok again.
Once the first problem had been resolved, it was time to integrate the already tested code with the new LoRa code.
I noticed that there are some limitations on what pins are available if the ESP-32S is using wifi, to make the prototype assembly as easy as possible. I modified the pin map that i used earlier to include the LoRa chip and made notes on pins that I should not use.
The transmitter device will use flame sensor, LoRa communication and deep sleep functionality. The device takes three sensor readings and determines is the value is true or false. After this it sends the data using LoRa and goes to deep sleep for 10 minutes. It does this 6 times every hour. To separate the device, if there is more than one in use , there will be a unique id assigned to it. This UID will be included in the message transmitted.
The receiver will use WiFi and LoRa of communication. LoRa to capture the message send by the transmitter and WiFi to pass the message forward. In this phase, the receiver is designed to be used without a battery, meaning that it has to be plugged in to a power source. The WiFi is most likely quite power hungry, so using this with a small battery like the transmitter, would most likely lead to a short power cycle. The receiver will have an array containing the transmitter uid’s in use. First it will check that the package is sent from a known transmitter, after this if will check if the sensor value is a number and is it be 0 or 1. Once the sender and message have been validated, it resends the message using the WiFi.
Once the codes were assembled, the first test was as successful as I thought it would be.
Before I can start constructing any enclosure, a test must be performed that the materials don’s actually hinder or block the LoRa transmission. This test was quite simple, cover the transmitter with the enclosure and put the insulation material between.
Fortunately, this had no effect on the signal strength.
I also did a bit of range testing with this prototype setup. The test was conducted in my apartment building(8 floors + an attic and a cellar), the transmitter was placed in the cellar and the receiver in the attic. I was surprised that I was able to get a signal through 9 floors, since there is quite a lot a concrete in between. The prototypes were assembled in breadboards, so I hope that the enclosure materials don’t affect the range too much.
There was one test left before I could even think of starting the enclosure assembly, that is a power consumption test.
I tested this with two code modules, one using deep sleep and the other using just the delay() method. This is the only way I can actually test if the deep sleep function saves any power. There are three states that are to be tested, flame sensor measurement, LoRa transmission and the deep sleep or delay state.
The results are as follows, the values an in milliampere.
LoRa using deep sleep:
LoRa transmission ~ 102 mA
Flame sensor reading ~ 58 mA
Deep sleep ~ 15 mA
Delay ~ 57 mA
Based on this, the deep sleep function actually saves quite a lot of power. By making a crude calculation, the average power consumption using the deep sleep function would about ~ 17 mA. This is based on the assumption that the sensor measurements and LoRa transmission is made every 10 minutes.
This week was quite productive, I’m pleased that the LoRa chips could finally be tested and now I have the notion that the project is moving forward faster.
Next week, device and enclosure assembly!
So this was the week I had waited and feared, making the thing actually work. Acquiring the materials luckily had no hick up’s.
This phase was primarily done in two locations, my home and my parents’ house workshop. My wife gave a tiny hint, that using a Dremel clone to cut through the circuit board and plastic could be too loud for our cat (and our neighbors apparently), so the mechanical phase was done in the previously mentioned workshop.
First part was cutting the insulation material to fit the enclosure, this is also to be used as a base to attach the component boards to the enclosure. This was actually harder than I thought, cutting a straight line with a saw or a knife by hand proved to be a challenge.
I took a while, but finally I had insulation peaces that would fit in, in some fashion. Once this was done, it was time to begin working in the workshop. Things that needed to be done was cutting the circuit board, hard PVC plastic (for circuit board and component stand) and enclosure to an appropriate form. Also needed to drill holes in the circuit board and PVC base, so the components could be mounted. The idea being that the components should be changeable, in case of component failure or maintenance.
Once back home, the assembly could start. The form cut insulation material is to be glued to the enclosure, with the hard PVC base plates, the components are mounted by using screws.
The final component soldering was a quite stressful process, since so many things could go wrong. This was done in phases, so I could perform a test after each one.
First, I started to solder the ESP-32S and LoRa chip. This was the hardest phase and the longest one. Luckily (I have been using this word often in this project) everything went all right and the components worked as they should.
Second part was to solder in the battery holder, that would function as the power supply. This was relatively easy, since there were only two wires to solder.
One thing I noticed in testing, was a decline in signal strength. It wasn’t huge, but still, before this project phase the RSSI was around -30 to -40, in these tests it was around -40 to -48. Not sure if this continues in the outdoor testing phase, I hope it’s not because of bad soldering.
The final part was to solder in the flame sensor. At this point I think I had mustered some self confidence, since the soldering and final product assembly felt easy and was done with some relief. When everything with the transmitter was completed, every component worked as they should.
I still have to solder and assemble the receiver module, but I’m confident that after this, it shouldn’t be an overwhelming obstacle.
It seems that the final project phase is approaching, that is outdoor testing. More on that and the receiver assembly next week, stay tuned.
This week wasn’t that productive as it might have been. Got struck by the flu season and thus, the outdoor testing had to be postponed a few days.
Since the transmitter has been assembled, the only thing left to assemble was the receiver. At first, I thought that this would be a quick solder and assembly, but since the board and enclosure used for the receiver are much smaller, it took a while to get the connections soldered properly. The enclosure is not water tight or weather resistant, so in the testing phase it will be located indoors.
To make the testing monitoring more easy, I published a small site (http://lora-tocsin.erkinjuntti.eu/) from which I can check the last LoRa transmission from the test location. This is a stripped version of the LoRa-Server project. Just an API for the transmission and a page to display the data. The LoRa-Server project will be published at the same address, once the project is finished.
I have had some testing sites in consideration. First one was Nuuksio, the Nuotiovati project used that location or testing. I decided that it was a little too remote for my purposes, especially since LoRaWan has not yet been utilized in this project. The other one was a rural Sauna cottage in the Meilahti area of Helsinki. This proved to be a bad idea, since the sauna is a private rentable sauna that is meant to be old fashioned and has no electricity or running water inside. Bringing a led lighted sensor inside would contradict the business idea of that location.
So I decided on testing the device in two locations. First one to be used for the initial testing is located in the Meilahti old villa area of Helsinki. The area is private, so the risk of possible vandalism to the device is small. Also the house that is located on that estate, is going to be the base for the LoRa receiver.
The second test location is located in Seurasaari, a museum island that is located about 3 kilometers from the city center. It’s also conveniently close to the previous location, this is in hopes that the transmitter can send a signal that far, the distance is about 1.1 kilometers.
Since this is city property, I have to apply a permit to conduct my test there. The application process took a few hops between different organizations, but in the end, I managed to get an approval to conduct the testing between 3.12 and 9.12.2018.
As you can see from the photos, the winter had already started. The temperature was around -1 Celsius, with a small snow fall on the ground. Considering the original idea of the project, this could be seen as ideal for testing.
The test started on 29.11.2018 at 19:30.
The first testing phase had the the following goals:
- To find out if the device can actually perform in outside winter conditions.
- How long the batteries can supply sufficient power for the device to operate.
- What is the range for detecting fire.
The first test was simple. I placed the device in the open, near a fireplace. Checked that the LoRa receiver would receive the LoRa message and just left it there. The transmitter makes a sensor reading and send the data using LoRa every 15 minutes.
I also conducted the range test. I found out that the fireplace that I intended to use was just a pile of bricks with a smoking pop on top. I feared that the brick installation would be damaged in some way if I moved the smoking pot. So I restarted the grilling season for the range test, for this I used a small grill that is used in the summer. Luckily I had raked the site a day before, so there was no imminent danger of a possible forest fire.
I’m pretty content with the range that the transmitter was able to make a sensor reading. The result was 350cm, the test was conducted pretty much the same way as the range test I did before (week4). I set the device about 50cm from the fire and checked the sensor reading, if true I would move farther away.
The first test ended on 2.12.2018 at 17.41. That was the last signal that the transmitter was able to send. The outdoor temperature during the test was from -2 to +2 Celsius. There was not enough rain or snowfall to mention and the weather was a very windy. The batteries lasted for ~ 70 hours. This was actually a disappointment, since I had hoped that the batteries would have lasted at leats 168 hours (one week). The case showed no condensation of moisture inside and was in sound condition, by this I determine that the enclosure can withstand outdoor conditions to some extend.
Since I still have time on my hands before I can start he Seurasaati testing, I decided on trying the same test but with regular alkaline AA batteries. The idea is to get a hands on experience on how different batteries perform. For the Seurasaari experiment, I was thinking of trying a different brand of lithium batteries.
I think this was a pretty ok week for the project, sadly the flu stalled me a bit and I wasn’t able to do the LoRa signal range test I had planned to do. This has to be done during the testing in Seurasaari to determine the actual range of the transmitter device.
The alkaline battery test, that was being initiated last week lasted for around 25 hours. The environment was pretty much the same as with the Saft 14700 battery test, light snowing and temperature average was about -1 Celsius degrees. This was expected, since the battery voltage was significantly lower (4.5 V) than with the test before that. Also, alkaline batteries are known to perform worse in colder temperature.
Sadly, the testing in Seurasaati had to be canceled. The LoRa signal range was not enough to reach the intended location of the receiver, which would have been located approximately 1.2 kilometers from the testing site. This was a disappointment in a way, but at least I got to test the LoRa signal range.
The range test was to be a prelude for the Seurasaari outdoors test. The transmitter was installed to the testing location, this was done using ropes to avoid any possible damage to the gazebo.
If the Seurasaari test would have continued, the possibility of theft or damage to the transmitter was a danger that just had to be accepted.
After the transmitter installation to the gazebo was finished and it was determined that both of the devices were in working condition, I could start the range test. This was conducted in a pretty straightforward fashion. I would take my laptop with the receiver attached and started walking towards the location where the receiver was intended to be placed.
From what I understand, for signal transmission LoRa uses a protocol called “chirp” protocol. It seems that this is a quite old method of transmitting signals, developed in the 1940’s for sonar and radar applications. There are two factors that I can change in the programming of the devices, that affect the range of the device. These are bandwidth (BW) and spread factor (SF). General idea being, that using a larger spread factor with lower bandwidth increases the overall range of the signal, but decreases the payload size. More info on this can found from this exploratory engineering article.
I started the test with the default configuration of the LoRa library used, which in my understanding is SF 7 and BW 500khz. One LoRa message was sent every minute. Since my payload is small, roughly 9 bytes, it should be in the limits of the possible SF/BW combinations available to me.
First range test ended after about 250 meters, beyond that I could not receive a signal. so I reconfigured the transmitter and receiver settings for SF and BW (at least the SF should be the same on both devices). I found out that by using an SF factor of 12 with a BW set to 125khz, I could extend the range to approximately 439 meters. After this, I the transmitted signal was not received. I also tried to measure the time difference between signal transmission and signal reception, this was degrading the farther I got and the last signal took over two minutes to be revised. There is a possibility that the time was actually shorter and that the message in between was simply lost, because the messages were not numbered by transmission and thus the same message was always send.
The area, that this test was conducted in was not completely even. It had wooden and brick structures and also some natural rock formations between the devices. I might have once again overestimated the capabilities of the devices and formed my expectations, according to that, but in all honesty, I’m pleased that the signal could carry as far as it did.
This was the last week for the project and no further testing was conducted after this. I could say I feel quite accomplished, considering that 8 weeks ago this was all new to me.
As I stated in the introduction (read it first, if you skipped all 8 weeks of project reports), this project held many first’s for me. When the project started, I had little knowledge of C++ or Arduino coding or designing and assembling an IoT device of my own. LoRa as a concept was completely new for me.
The Project planning was done as best as possible from the beginning. Thanks to this, and also to the project instructor’s advice, the project had a clear goal from the very start.
This gave me a huge advantage, since this saved a lot of time from aimless searching and wondering. This project intended on being a “proof of concept”, but I think it developed a bit further than that.
As a side project, also a web application was coded for this project to manage the LoRa transmitters (if there would more than one).
A quick glance on the 8 weeks of this project.
Since most of the specialized equipment ( ESP-32S, RFM95W LoRa chip, flame sensor [KY-026] ) was acquired from China by mail order. The biggest problem the project faced, was getting the necessary material to Finland in time. As any project, this one had a limited time frame and in most cases, that’s the most precious recourse since often it’s quite limited.
Gradually the project moved forward. I started with the basic’s in Arduino coding, using the Arduino UNO as a test bench.
One could say that this project officially started with two blinking led lights on a bread board.
From there I moved on testing with theESP-32S and by the end of week 2, I managed to get the flame sensor working and sending the data to a test server using the WiFi module in the ESP-32S.
After this the ESP-32S deep sleep functionality was successfully integrated, the idea was to cut the power consumption to a minimum. Also perfected the WiFi code that the device reconnects in events when connection is lost.
The enclosure for the LoRa transmitting device was selected and tested for water tightness on week 4. Also got good results with testing the flame sensor range, measuring up to 105cm with a small candle.
On week 5 the RFM95W LoRa chips finally arrived and I could begging trying them out. The chips had no pins or an antenna installed in them, so I got to do some soldering, first time in some 20 odd years.
A first LoRa point-to-point connection was made on week 5, I used the Sandeep Mistry LoRa library for Arduino to accomplish this. Also managed to get the lure signal transmitted through 9 concrete floors in my apartment building while testing.
The power measurements were promising, the device would draw a maximum of 100 mA when using LoRa for transmitting. By using the deep sleep functionality, the transmitter could draw an average of 17 mA when in operation.
There were two enclosures prepared in this project. A watertight case for the transmitter, that proved to be weather resistant (at least in -2 celsius degrees) and a small enclosure for the LoRa receiver. These were assembled in weeks 6 and 7.
On week 7 started the outdoor testing, that continued to week 8. The transmitter managed to keep functioning for 70 hours in mild winter conditions, before it could no longer transmit any LoRa signals.
In night conditions, the flame sensor could pick up a sensor reading from 350 cm away.
The transmitter had a range boundary that was found out in the outdoors testing, this was 439 meters.
After this, it was concluded that the project had reached its designated goals.
The project managed to produce a working transmitter and receiver prototypes, that utilized LoRa to communicate with one another. Considering the measured power consumption, this proves that this kind of setup is ideal for to be used in sensors, that need to transmit data in areas that lack WiFi or ethernet connection. The LoRa range that was recorded during testing proved this to be a viable option for a traditional internet connection in an IoT device.
The original idea was, that the device should be affordable. The material costs for the transmitter ended up being around 23.5€. The receiver was a bit cheaper, since it didn’t need the same amount of material, the cost being around 17€. Note that this is single shelf prices. In my opinion, this is acceptable for a prototype. The overall material costs for the project were much higher, but they are not to be discussed in this.
There is room for improvements in the future, if this project is to be continued.
- Shrinking the transmitter device to a smaller size.
- Better power management in operation.
- Testing this kind of setup using LoRaWan.
- Display to show operational data in the receiver device.
I hope that these results and the project in general, would encourage students on trying LoRa with their IoT projects. At least inHaaga-Helia.
Also, I’m suggesting that Haaga-Helia would partner up with Digita, so the school could get LoRaWan access for students to use.
By all accounts, I would consider this to be successful project. All of the original goals were met. There was an idea of trying out LoRaWan with this project, but sadly the project time frame was against me.
While the project was quite time consuming, it was a great experience. I learned C++ and Arduino coding, build my first IoT device and managed design and implement a working solution to house the IoT device.
This project was conducted in a smaller time frame than a normal Haaga-Helia multidisciplinary course, that is 16 weeks. I dare to say I’m proud of myself to be able to accomplish this in only 8 weeks.
While working on this project, I was fortunate in getting an internship at CoreFactory, a company that produces IoT solutions. It seems that I will be doing a bit more coding on this kind of field.
For now, this is the last report of this project. I will update this, if any, major changes occur. If you are reading this, I thank you for your interest in this project.