Summer Project Part 1: LoRaWAN Signal Mapping!
What? A new series (hopefully)! My final project for my Masters in Science course at University is taking place this summer, and on the suggestion of Rob Miles I'll be blogging about it along the way.
In this first post, I'd like to talk a little bit about the project I've picked and my initial thoughts.
As you have probably guessed from the title of this post, the project I've picked is on mapping LoRaWAN signal coverage. I'm specifically going to look at that of The Things Network, a public LoRaWAN network. I've actually posted about LoRa before, so I'd recommend you go back and read that post first before continuing with this one.
The plan I've drawn up so far is to build an Internet of Things device with an Arduino and an RFM95 (a LoRa modem chip) to collect a bunch of data, which I'll then push through some sort of AI to fill in the gaps.
The University have been kind enough to fund some of the parts I'll need, so I've managed to obtain some of them already. This mainly includes:
- Some of the power management circuitry
- An Arduino Uno
- A bunch of wires
- A breadboard
- A 9V battery holder (though I suspect I'll need a different kind of battery that can be recharged)
- Some switches
(Above: The parts that I've collected already. I've still got a bunch of parts to go though.)
I've ordered the more specialised parts through my University, and they should be arriving soon:
I'll also need a project box to keep it all in if I can't gain access to the University's 3D printers, but I'll tackle that later.
I'll store on a local microSD card for each message a random id and the location a message was sent. I'll transmit the location and the unique id via LoRaWAN, and the server will store it - along with the received signal strength from the different gateways that received the message.
Once a run is complete, I'll process the data and pair the local readings from the microSD card up with the ones the database has stored, so that we have readings from the 'block spots' where there isn't currently any coverage.
By using a unique random id instead of a timestamp, I can help preserve the privacy oft he person carrying the device. Of course, I can't actually ask anyone to carry the device around until I've received ethical approval from the University to do so. I've already submitted the form, and I'm waiting to hear back on that.
While I'm waiting, I'm starting to set up the backend application server. I've decided to write it in Node.js using SQLite to store the data, so that if I want to do multiple separate runs to compare coverage before and after a gateway is installed, I can do so easily by just moving on to a new SQLite database file.
In the next post, I might talk a little bit about how I'm planning on generating the random ids. I'd like to do some research into the built-in
random() function and how ti compares to other unpredictable sources of randomness, such as comparing clocks.