Netvox Payload Decoder for The Things Network

I’ve published an example payload decoder for Netvox sensors using The Things Network. It’ll also work with Chirpstack with some simple modifications.

What is a payload decoder?

A bit of background, LoRaWAN is an open protocol that defines communication between low powered sensor devices and the Internet. It is great but it does not define data payload formats. It’s much like HTTP, it defines a mechanism for communication but not what that communication is.

The current state of play is that the various sensor manufacturers devise their own payload formats for data sent from or to their sensors. There are some efforts to define standards (such as Cayenne LPP) but none are widespread. The difficulty is that there are so many different types of sensors that designing a protocol to fit inside a few Bytes and yet cover all eventualities isn’t simple.

So at the moment when you add a sensor to a LoRaWAN network, you need to translate the payload into something useful.

Netvox Payload Decoder in The Things Network

If you want to get started with Netvox sensors then you can start off with this Netvox payload decoder Javascript code, it’ll load straight into The Things Network.

I will keep adding more sensors to it as time goes on.

View and download it on Github.com

LoRaWAN Security

This week, a security company called IOActive published a white paper on security vulnerabilities in LoRaWAN. You can read it here. I was also in the audience at a talk they gave during the Things Conference 2020 in Amsterdam last week on the same subject of security in LoRaWAN.

This report has caused a slight stir in the LoRaWAN community, to that end the LoRa-Alliance published a blog post on security. You can read this here.

I’ve read both and having been involved in security conscious areas of computing for many years (Voice-over-IP before IoT/LPWAN), there’s nothing in either report that I can’t agree with in some way. I do feel the IOActive report is a little bit sensationalist but hey, they’re a business trying to get their name out there so I can let them off. Plus, everything they talk about I have seen before in the VoIP world so it’s not new to me. Here’s my own thoughts on this subject.

There’s really two aspects to the report, the first is that LoRaWAN version 1.0 AppKeys are brute forceable. This is true, any encrypted or hashed password is brute forceable given enough time and resource. This information is neither new or surprising. The problem here is that it’s not that hard to do in a lot of cases, often due to poor management of these keys. LoRaWAN 1.1 adds extra security to mitigate this risk, I wont go into details here, the spec is published by the LoRa-Alliance if you want to read it plus these reports cover it too.

The other aspect the reports deal with are implementation issues and human factors. These are frequently the cause of cyber security problems in all areas, certainly it is the case in the Voice-over-IP world as well as IoT.

With respect to LoRaWAN, the issue is one of management of the AppKeys. Here’s a run down of the problems. I have seen each and every one of these problems in the real world several times!

  • Keys sent and stored in a non-secure fashion. I’ve seen both manufacturers and end user emailing spreadsheets or text files containing AppKeys in plain text. Then keeping hold of these files on their computer in case they need to refer to them later on. This is bad. If someone ever got hold of these files then they have a copy of the keys. Keys should be treated in the same way as passwords (although many people are terrible at that too). There’s an old saying, if you wouldn’t write something on the back of a postcard and drop it into a post box, then don’t send it in an email, there’s no way of knowing who might see that email.
  • Poor quality, non-random or non-unique keys. The most common one is where devices all share the same AppKeys, either from the manufacturer with little consideration given to changing them or installers being lazy and provisioning the same AppKey to all devices because it’s quicker. Also, non-random keys such as the DevEUI repeated twice, 32 zeros, “1234” repeated etc… These are all similar to using “password123” for a login password, they are easily guessable and not secure.
  • Hard-coded keys which can’t be changed. This one is down to manufacturers of devices. Would you sign up to a social media website and post your photos on it if they forced you to use a set password with no way of changing it (especially if they’d emailed it to you in plain text)? Hopefully the answer is no.
  • Insecure out-of-band management. Some devices are configurable over Bluetooth or NFC using a mobile app. It seems in some cases, there’s no security on this. You can download the manufacturer’s free app and connect to a device if you are close enough to it, then read the AppKey from it. Personally I think this is a limited attack vector, it requires the attacker to be physically close to the device. Having said that, if you’ve also used the same AppKey on all your devices, now your entire system is compromised because someone got hold of a single sensor.

So what should you do? Should you rip out all your LoRaWAN systems and hide in a cupboard for the rest of the year? Absolutely not, in fact mitigating these risks is not very hard. I can confidently say that I’ve been implementing these measures and instilling secure ways of handling LoRaWAN keys in all our staff for a long time. What this means for us and what I would encourage anyone reading this to do is as follows.

  • Use unique AppKeys on each and every device you install. Don’t even use common ones for testing, it’s just a bad habit to get in to. This website can be used to generate random 128bit keys for use as AppKeys. When we provision devices for customers, we always use this or similar tools to generate unique keys and securely load them onto the devices.
  • Keep your keys safe. Don’t email them, an Excel spreadsheet with a password applied is still pretty poor security. We provide a securely encrypted portal to allow our customers to submit keys to us (or for us to send keys to our customers). This software generates a single-use obscure link, without the link it’s not easily possible to decrypt the keys even if someone had access to the server the portal is hosted on. We can also provide a password as an extra layer of security which is sent separately to the link itself. We use open source software called PrivateBin to do this. We also never store keys and I regularly train staff on the virtues of key security.
  • Keep your infrastructure secure. Your LoRaWAN Network Server has copies of all your keys stored on it. Make sure this is secure, use secure random passwords to log in to it. Make sure any other access to the server (e.g. ssh access) is secure. I wont go into details here, if you’d like to talk about this then feel free to get in touch.
  • Communicate. If you see someone doing something you feel is bad practise, say so. If you deal with us and we advice you that you are doing something we feel can be improved, don’t take it personally, we are trying to help. Similarly, we are very open to discussion and suggestions you might have for us. We keep in touch with our suppliers and manufacturers to advise and take advice on security. We also actively lobby manufacturers of devices to improve security and keep developing firmware to implement new standards.

I encourage the LoRaWAN community to openly discuss these issues so they can be debated in an organised manner. I have seen the IOActive report being dismissed as FUD, this is counterproductive, there are real issues to address, defensiveness and an unwillingness to debate are not helpful in my opinion (although it’s a reaction I have encountered many times in the technical/computing industry). I am always happy for anyone to talk to me about an issue they feel they have found and I am always willing to assist in talking to device manufacturers about fixing problems and improving security in an open and honest fashion.

LoRaWAN GPS: Technology Options

We stock a range of LoRaWAN GPS asset tracking sensors including Abeeway’s Micro Tracker (plus their industrial version) . Each of them list a variety of tracking technologies and how they can be used. But was do these different types of location monitoring actually mean? And which one should you be using? Here’s a list of the different types of geolocation technologies.

Here’s an overview of the different geolocation technologies available for LoRaWAN asset trackers:

1. GPS

The same technology as your sat-nav in your car or your smart phone uses. It relies on receiving signals from multiple satellites in orbit around the planet.

Location accuracy can be as good as a couple of metres. But this depends on getting signal from a lot of satellites. 10m accuracy is the generally accepted level for standard GPS.

GPS can be quite “power hungry”. Even though GPS is a “receive only” system, it uses more power because it takes a long time (minutes rather than seconds or even milliseconds) to lock on to multiple satellites.

It’s free to use and there is global coverage.

GPS works best outside. If you are inside a building it sometimes works near a window, but GPS is generally recommended for tracking over long distances; for example monitoring fleet vehicles or keeping track of a runaway pet.

2. LP-GPS (low power GPS)

This is a proprietary technology developed by Abeeway, specifically for their micro tracker. It requires the use of Abeeway’s own software platform.

Most of the location processing is done on a server instead of the device itself. This means that time, CPU usage and battery power is saved. I can’t comment on the operation of this at the moment as I am yet to give it a try.

3. Wifi Sniffing

Technically this isn’t LoRaWAN GPS. But it does provide pretty accurate device locations using surrounding wifi networks.

Because there are wifi networks literally all over the place these days, you are usually within range of several of them anywhere (except really remote or rural areas). Companies such as Google or Apple collect the IDs and locations of wifi networks and store them anonymously.

Your smart phone makes use of this data to determine it’s own location quicker than waiting for a GPS lock. Your smart phone also collects this data and sends it back to the databases of the likes of Apple and Google. I find this technology really interesting and yet a bit scary at the same time.

The Abeeway tracker makes use of this technology as a way of getting a pretty accurate location by simply “sniffing” for wifi networks in range. The tracker sends the IDs of nearby wifi networks to the LoRaWAN Network Server. It is then up to you to convert this into a normal location (latitude & longitude) on your own application. The raw data looks like this:

wifi sniffer data vs lorawan gps

That’s a list of wifi bssids and rssis my tracker has sniffed. It doesn’t connect to any wifi network, it simply scans for their IDs. Any wifi network broadcasts these ID numbers (along with the SSID you more commonly see in a list of networks to connect to on your computer). The RSSI numbers are the signal strengths for each network which can optionally be used to get a more accurate location .

To do something useful with this information you need to convert that raw data into a location. Google provide an API to their mapping system called GeoLocate, it does many things but one of them is converting these wifi networks into a real location just like you’d get from GPS – a latitude and longitude.

‘True’ LoRaWAN GPS

The Abeeway Micro Tracker is a pocket sized geolocation device that supports multiple location technologies. It’s a small battery powered unit that can either be put in your pocket, attached to a key-ring or put inside something else.

This LoRaWAN GPS tracker has an internal rechargeable battery which gives a couple of weeks of life depending on how you are using it. It is recharged by connecting a micro-USB cable. It has a single button on the front of it which is used to switch the device into different modes or trigger a geolocation event.

A simpler alternative

At Alliot Technologies, we also stock a simpler, more affordable asset tracker for indoor use. This one is manufactured by Netvox (Netvox 718MA) and relies on Received Signal Strength Ratio (RSSI) and Signal to Noise Ratio (SNR). It basically alerts your LoRaWAN network when the device leaves the network. Perfect for making sure your equipment stays on your business premises, but not really a ‘true’ asset tracker.

If you’d like information or advice on choosing the right LoRaWAN GPS trackers for your IoT project, get in touch with our technical team. We’re passionate about IoT products and how they can create help your business run more smoothly!

NB-IoT Introduction and Testing

What is NB-IoT?

It stands for Narrowband Internet-of-Things. It is a low powered wide area network (LPWAN) radio technology that is part of the LTE/4G family.

Essentially a cut down version of the LTE technology that your mobile phone probably uses but using a narrower bandwidth (hence the name).

It has similar design goals to other LPWAN technologies (such as LoRa and Sigfox). These are mostly ultra-low power usage, long range, low cost, small data usage.

The main difference between NB-IoT and LoRa/LoRaWAN is that an NB-IoT network is provided by a mobile network operator rather than individuals buying and operating their own gateway devices.

It’s a brand new technology, the standard was only finalised in mid-2016, as yet there are no commercially available NB-IoT services in the UK. There are some available in central Europe. At the moment, Vodafone UK are the only operator currently rolling out the service but as I understand it, O2 and EE will soon follow. The Vodafone service is currently in the trial stage and coverage is limited to certain areas of the country.

It’s my opinion that NB-IoT will become a popular LPWAN standard in years to come so I am excited to be able to give it a try. Alliot’s plan is to offer NB-IoT related services and sensors as soon as they are commercially available.

Trying out NB-IoT

As I said, Vodafone are currently trialling their NB-IoT service, this means that they are making SIMs available to certain partners for testing. I have obtained some SIMs for testing, I cannot get any for anyone else at the moment. Alliot plan to provide SIMs as soon as we can.

Because it’s so new, there’s not much hardware around at the moment that supports NB-IoT. So to test I have so far bought a Pycom Fipy development board:

https://docs.pycom.io/datasheets/development/fipy/

And an Arduino MKR-NB-1500 board:

https://store.arduino.cc/arduino-mkr-nb-1500-1413

These are far from plug&play devices, the Pycom board needs to be programmed using the MicroPython language and the Arduino board needs to be programmed using a C++ style language.

nbiot_microcontroller_code

Both devices need a suitable antenna, I used this one with both boards (they both have the same u.fl antenna connector):

https://pycom.io/product/lte-m-antenna-kit/

You’ll really need the Expansion board to go with the Pycom as well:

https://pycom.io/product/expansion-board-3-0/

Finally, you’ll need some NB-IoT SIMs!

The NB-IoT node will send and receive data via the network operator’s network, they will assign an IP address to the node and it can then communicate with the Internet. To test, you will need a server/computer that is publicly accessible on the Internet. In my case, the Vodafone trial limits usage to UDP only so I made a simple Python script on a test Amazon AWS server that accepts UDP packets and logs the contents to a file. All very simple stuff and not very useful but it’s pretty cool all the same! It all works as expected.

The Pycom board simply sends a “hello world” message every ten minutes, the Arduino board does this too but I also made it report it’s battery voltage since I’m powering that from a rechargable LiPo battery.

What next, what use is this?

I’ll expand on this to connect some real sensors to both devices so they are sending something more useful. I will then make the server part log to a database and produce some graphs in Grafana to visualise the data.

I have also sourced some commerically available sensor devices so will be testing them, another post on that will follow.

Verdict on NB-IoT testing

This experimentation has taught me a few things.

  • This is very new technology indeed, it’s much less mature than LoRaWAN for example. There’s scant information on the Internet so far, getting the Arduino board to work for example involved finding and reading the low level documentation for the uBlox chip on the board and the Arduino source code for their NB-IoT library.
  • You’re at the mercy of a network provider. If you have no coverage then it’s tough luck, no buying a gateway as with LoRaWAN or Sigfox. Although if there is coverage, then great, you don’t need to buy a gateway (also the case for Sigfox). You will always have to pay a network operator for use of the network.
  • It needs more power than LoRaWAN, considerably so in my opinion. For example, just connecting to the network takes multiple seconds and this will eat batteries. In comparison to LoRaWAN where a sensor can wake up, fire off a message and go back to sleep in a matter of milliseconds. Feel free to get in touch and correct me but I cannot see how NB-IoT can be anywhere near as frugal as LoRaWAN.
  • It’s more synchronous than LoRaWAN. It’s still designed for tiny amounts of data but connections involving multiple requests & their responses are possible. A protocol called Constrained Application Protocol (CoAP) can be used which is like a cut down version of HTTP.
  • The technology is a reality and the mobile networks are starting to roll it out. I think NB-IoT will be big and sit alongside other LPWAN technologies.
  • The UK seems to be behind central Europe again. There’s much more evidence online for people using NB-IoT in places like Germany.



Netvox Sensor Range Now in Stock

We have now taken delivery of our first large batch of Netvox LoRaWAN sensors.

You can see the full list with details here:

All Netvox Sensors

Please get in touch by email (contact@alliot.co.uk) or phone (01484 599544) if you want to ask any questions or want to order any sensors.  Next day delivery is available to most places in the UK and we have no minimum order quantities, if in doubt please ask.

Achieving long battery life with LoRa sensors

LoRaWAN technology is known for its long range and low power usage.  In fact, LoRa stands for “Long-Range”. There are certain ways to optimise the battery life of LoRa sensors. This blog post covers key technical factors that will help to improve LoRa battery life.

LoRa is a radio communication technology that LoRaWAN uses for transmission of messages.  It can be thought of as the physical layer in the OSI Network Stack.

The exact details of LoRa modulation are proprietary and the property of Semtech Corporation but it uses a technique called chirp spread spectrum to travel long (multiple kilometer) distances with relatively low transmission power.  By comparison, other modulation technologies such as frequency shift keying (FSK) would either cover much shorter distances or require much higher transmission power.

Despite all this, a device running off a small, cheap battery will only last months or years by spending the vast majority of it’s time powered down.

Some of this is down to the manufacturer of the devices you are using, they need to have done a good job of designing their device and writing the software for it so that it goes into as low a power state as possible  when it is not doing anything.

The rest is down to the data being sent and the radio signal strength between the device and the nearest gateway.  The data format might be fixed by the device manufacturer, or you might be able to design this yourself.

Optimising LoRa Battery Life

  • Send small amounts of data:

The smaller the data payload the device is sending, the less time the device needs to be powered up.  Even with the low power usage LoRa gives you, transmitting data uses power.

Most LoRa sensor devices will have a LoRa radio chip and a separate micro-controller which both use power.  The less data being sent, the less time it takes to send so the less power is used.

Data is sent in bytes and you want to send the minimum amount possible to maximise LoRa battery life.  You can achieve this by being a bit clever about how you encode your data.  As an example, lets say you have a sensor reading ambient temperature, here are some ways you could encode that data:

“Temperature: 21.26” as text encoded into ASCII ends up as 54656d70657261747572653a2032312e3236 which is 18 bytes long.

If you shorten this to “2126” and then convert to a readable format in your application, this data in ASCII hexadecimal is 32313236 which is 4 bytes long so less than a quarter.

If you actually convert the number 2126 to hexadecimal you get 084e.  So now only 2 bytes.

You should always avoid sending text.

  • Send messages less frequently:

If you send messages less frequently, the device is in it’s low power sleeping mode for a longer percentage of time so the battery will naturally last longer.  As tempting as it can be to make your sensor send data back every minute or so, it’s hardly ever necessary.

For example, a sensor taking readings of soil moisture to control an irrigation system.  Soil moisture isn’t going to change rapidly, taking a reading once every hour will most likely be suitable, taking a reading every five minutes is a waste of energy.  Potentially your battery will last 12 times as long which could be the difference between changing it every 2 months or every 2 years.  This is an over-simplification but useful enough for this example.

Even for things like temperature, humidity or CO2 metering inside buildings, these factors only significantly change over the course of hours rather than minutes so having per-minute accuracy isn’t necessary.  Something like every 15 minutes would be ample to increase LoRa battery life.

  • Keep LoRa Spreading Factor as low as possible:

The spreading factor in LoRa relates to the length of the “chirps” sent over the air when transmitting data.  Longer “chirps” (which equate to a higher spreading factor) take a longer amount of time to transmit but will be successfully received over a longer distance.  Spreading factor numbers go from 7 to 12, for each step up the transmit time doubles.

This screenshot is taken from The Things Network console showing several LoRa messages received by a gateway using various spreading factors:

Note the column headed data rate and the values given for “SF”.  Then note the corresponding values under the air time headed column.  You’ll see several messages at SF7 with an air time of around 40-60 milliseconds depending on the size of the data.  There is one message at SF9 with an air time of over 164mS and lastly one message at SF12 (the highest factor) which has an air time of 1482mS, or nearly one and a half seconds! That’s about 25 times the amount of time needed to send the same message at SF7.

It’s clear that higher spreading factors will have a huge effect on battery life, potentially 25 times less if using SF12 in comparison to SF7 in this example (which is showing some real data).

So you want to use the lowest spreading factor as possible.  LoRaWAN does this using an “adaptive data rate” mechanism.  Exactly how it works is dependant on implementation of the network server.  But for example (at the time of writing this), The Things Network’s server will wait until it has received 20 messages from a device, then if the signal strength is very good, it will instruct the device to reduce it’s SF.  There is an acknowledgement mechanism used after this to allow a device to ensure it’s data is still received.

For more information on how ADR works with TheThingsNetwork, see this page.

This screenshot from the ThingsNetwork console shows ADR in action:

lora battery life

Here you can see the network server adding commands to a downlink message to tell the device to change it’s data rate (where you see “link-adr” in the screenshot).

Using lower spreading factors relies on network coverage.  Using higher factors will allow messages to travel further and still be received when interfering factors are in play such as buildings between the device and the gateway.

Ultimately you might only be able to use lower spreading factors by adding more gateways to your network but at least this is possible with LoRa.   Unlike for example if you have a poor mobile phone signal then your only real option is to move somewhere else with better signal.

For more information about how the technical team at Alliot can help you to achieve your business goals using LoRaWAN devices, get in touch today.

LorixOne LoRaWAN Gateway – what does it do?

At it’s most basic level, any LoRaWAN gateway’s job is to receive messages from sensors over radio signals and forward these to a LoRaWAN network server.  The network server then decides what to do with these messages – more than likely store the data from them so someone or something can analyse them later on.

The gateway needs to be programmed to talk to your LoRaWAN network server, whether that’s something like The Things Network, Loriot or your own server (the LorixOne supports all of these systems), the gateway talks to a Network Server over an IP connection.

The LorixOne gateway has a single RJ45 connection to plug into a network.  It comes with a passive-PoE adaptor which is used to provide both an IP connection and power down a single Ethernet cable to the gateway.  It doesn’t support 802.3af/802.3at Power-over-Ethernet standards, so you need to use the passive-PoE injector supplied even if you already have a PoE capable network switch.

It doesn’t matter how the gateway reaches the Network Server as long as it can.  So you can simply connect it up to your IP network, or you can connect it to a converter such as a 3G/4G router or a Wifi bridge for back-haul to the LoRaWAN network server.   Just how much bandwidth is required will depend on how many sensors will talk via this gateway and how often they will talk.  However, LoRaWAN uses minuscule amounts of data, each message being a few bytes in size only.  Just looking at the console in my own ThingNetwork account at the last few messages my LorixOne gateway received, I can see that two of them were 14 bytes and one of them was 20 bytes.

So doing some pretty crude estimations as an example, lets say we have 100 sensors sending messages every ten minutes (which is actually quite a lot for most use cases) and the average message size is 16 bytes.  UDP & IP overhead adds about 30 bytes (more for IPv6, TTN seems to be IPv4 only at the moment).  So lets say that each message uses 46 bytes on the wire, it could be more depending on how your gateway is talking to the network but this probably isn’t a million miles off:

  • In one hour, one sensor will send 276 bytes (46×6)
  • In one hour, all 100 sensors will send 27.6 kilobytes (276×100/1000)
  • In one month (lets just say 30 days), we will require 19.87 megabytes (30 days is 720 hours, 720×27.6bytes / 1000 to get MB)

Even if you had 10,000 sensors doing this you’re using less than 2GB a month.

Radio Capabilities

The LoRa radio in the LorixOne gateway is based on the Semtech SX1301 chip.  This is an 8-channel radio which means the gateway can receive 8 messages from sensors at once.  How many sensors it can handle is hard to answer as it depends on many factors.  These include: how often the sensors are sending messages, how much data the messages contain and the signal strength between sensors and the gateway.  Sensors that have a weaker signal will increase their transmit time in order to send data, this means a receive channel on the gateway is tied up for longer.

When it comes to sending data from the gateway back to sensors, there is only a single channel for this.  In addition, the regulations for use of ISM band radio devices states that you can only send data for 5% of the time (depending on exactly which channel is being used though) in Europe.

LoRaWAN (in common with many other low power wide area networks) is asynchronous, it’s not quite one way only but it’s not far off.  If you are wanting to send data back to your sensors, you need to be careful how you manage this and ensure you don’t break the regulations.

The gateway should easily be able to handle several thousand sensors sending small pieces of data periodically.

Software and Configuration

The LorixOne gateway is an embedded computer running a Linux based operating system (based on Yocto).

Configuration is done by command line only, you need to ssh in to it.  Use the ‘ssh’ command on a Mac or Linux PC, download the Putty program on Windows.

We can help with configuration and can pre-configure gateways before shipping them.

Get in touch if you are interested in this (contact@alliot.uk)

Gateway Variants

There are two product codes you can order for the LorixOne gateway.

LORIXONEIP65O: this is the outdoor IP67 rated version of the gateway

LORIXONEIP43I: this is the indoor IP43 rated version of the gateway

In reality the only difference is the antenna which is supplied with the unit.

The outdoor version contains a fixed position 500mm 4.15dBi antenna.  This will give the longest range, the gateway needs to be installed vertically.

The indoor version contains a variable position (as in the angle of it can be adjusted so the gateway can be installed horizontally or vertically), 200mm 2dBi antenna.

Both are currently the same price.

Verdict

Things I like about this gateway are:

  • it’s really small!  The body of the unit is a cylinder of approximately 200mmx45mm diameter.  This helps make it easy to install without looking messy
  • Very easy to mount.  Just strap it to a pole
  • Outdoor rated.  IP67 dust/water ingress rating means it can be sited wherever you want
  • The price.  We have retail and trade pricing.  For an IP67 gateway, I haven’t found anything cheaper
  • Quality.  The gateway looks & feels very high quality, it’s made of tough ABS plastic, it feels like it will last a long time.  The software is running off NAND flash, not an SD card or similar

Limitations:

  • passive PoE instead of 802.3af/at.  I think it’s a shame it needs an injector and power supply, although both are included in the box
  • Ethernet only.  I would like to see versions that include an integrated 3G/4G modem and a SIM card slot, perhaps a wifi version too.  I wouldn’t want a single gateway with them all, it will become too expensive.  You can of course connect it to a 3G/4G router or Wifi bridge

Given the price and that those limitations are either not much of an issue or easily solvable, this gateway is just about the best thing I’ve seen so far for building a LoRaWAN network.

LoRaWAN DIY Sensor

If you’ve got a LoRaWAN gateway, or are in range of an open gateway such as  The Things Network, you’ll need some sensors to start collecting data. Find out how Paul (our head technical advisor) made his own DIY LoRaWAN sensor using a Lora32u4 board. 

We will be supplying commercial sensors but for experimentation (and because it’s fun) I made my own.

In keeping with the design goals of LoRaWAN, I wanted the following features:

  • low cost
  • able to run off a small battery for at least a month (ideally much longer)
  • easy to program without having to purchase device specific programming tools, ideally an Arduino compatible board
  • capable of monitoring temperature and humidity with a reasonable level of accuracy
  • data collected by The Things Network

I’ve done lots with Arduino boards over the years so using something compatible with that made a lot of sense to get something working quickly.

I wanted to make four different DIY LoRaWAN sensors.

After a small amount of research, I found the Adafruit Lora32u4 board and then the BSFrance clone of this.  The BSFrance version of this is the cheapest board I’ve come across that incorporates a Lora radio with an Arduino MCU.  It also includes a battery connector and a LiPo charging circuit so is easy to run from a small battery.

This board consists of an RFM95 LoRa chip connected to an ATmega32u4 microcontroller.  These two components talk to each other using a protocol called Serial-Peripheral-Interface.

Then I searched for a combined temperature and humidity sensor device.  I usually prefer using digital devices than analogue devices such as thermistors as I feel the manufacturer will have already done the hard work of converting the analogue readings into a usable value and will have done some calibration.  In my experience, these devices give a more accurate reading with less effort.

I decided on a Honeywell HIH6130 chip (which I found on Farnell).  It uses a protocol called i2c, this is a simple serial protocol which is widely supported by many embedded systems, including Arduino.

To power my DIY LoRaWAN sensor, I needed batteries. The Lora32u4 board includes a Lipo charging circuit so I decided on using small LiPo batteries, the sort designed for small quadcopters/drones.  I went for 600mAh batteries as they were very cheap!  One thing I found is that the polarity of the connector was incorrect for the BSFrance board, so I had to remove the pins from the plastic housing and connect them the other way round.  Be very careful, incorrect polarity and short circuits of Lipo batteries can cause fires and explosions.

So next, I got the HIH6130 datasheet, BSFrance Lora32u4 pinout diagram and a piece of paper to design the circuit for my LoRaWAN DIY sensor.  As this is an experiment only, I designed it with a view to mounting on stripboard/veroboard.  I ended up with this:

DIY lorawan sensor using Lora32u4 board

You may note that it shows a GPS module connected to the serial port of the Lora32u4 board.  This was just another experiment I did with logging co-ordinates to The Things Network.

The next step is to translate this to a breadboard (prototyping board).  Before that though, I had to figure out a way of mounting the HIH6130 as it is a surface-mount chip and so wont fit into either a breadboard or the stripboard I wanted to eventually use.  I found these adaptor boards on Farnell.  Expensive for what they are but solve a problem easily.  Soldering the HIH6130 chips to these was fiddly, my tip is to use a small piece of Blu-Tac to hold the chip in place while you get the first couple of pins soldered.

I prototyped two sensors side by side on breadboard, the left hand one also includes a connection to a GPS board (which I already had lying around in a drawer):

prototype DIY lorawan sensor using lora32u4 board

That’s the hardware largely sorted for my DIY LoRaWAN sensor. Next is to write some software to make it do something.  There’s lots of ways of writing, compiling & uploading code for Arduino compatible systems.  In this instance I used a text editor/IDE called Atom with a plugin called PlatformIO, I used these because I specifically wanted to try them out.

Using the PlatformIO Atom plugin, it’s really easy to search for and install Arduino libraries.  One of the advantages with Arduino is it’s popularity and amount of high quality libraries that exist for it.  For this project I used:

  • LMIC-Arduino: an implementation of the LoRaWAN protocol in C, ported to Arduino
  • Low-Power: a simple way of making Arduino boards go to sleep and then wake up after a specific amount of time or in reaction to an interrupt
  • SPI: needed for communication with the RFM95 LoRa radio chip
  • Wire: this is part of the standard Arduino system (so doesn’t need installing separately).  It allows you to talk to I2C devices.  I did find a library specifically for HIH61xx chips, I can’t remember why I didn’t use it, I think it was because I found it just as easy to directly use the Wire library.

My program operates as follows:

  • when the sensor starts up, it joins the LoRaWAN network using a device ID and application key.  Using Over-The-Air-Activation process.
  • then it enters a never ending loop:
    • re-join if necessary
    • read temperature & humidity from the I2C device
    • read the battery voltage level from an analogue pin on the Lora32u4 board (the BSFrance board allows you to get the battery voltage)
    • send data to the Lora chip
    • go into low power sleep mode for ten minutes

Aside from the obvious task of actually sending readings to the LoRaWAN network from the sensor, there’s a couple of really important things it does.

One is to go into sleep mode, the device will spend the vast majority of it’s time in low-power sleep mode.  This is what gives a sensor the ability to last a long time on a relatively small battery. Without this it will not last very long at all.  If you are making a battery-powered LoRaWAN DIY sensor then you want to make sure that is it spending most of it’s time asleep and that any unused peripherals on your microcontroller board are switched off.

The next is using OTAA and rejoining the network if needed.  In LoRaWAN, a pair of security keys are used.  Using OTAA these keys are generated during the join process and are not hard-coded into your sensor.  The less secure method is using Activation By Personalisation (i.e. hard coding the keys into your device).  This is not secure and should be avoided.  When using OTAA it’s important for a device to re-join (and get new keys generated) if needs be (and it’s recommended to do this periodically anyway).

programming lorawan diy sensor using otaa

I uploaded this code to each of my four DIY sensors (each one contains it’s own ID and application key) and they were happily sending data to The Things Network every ten minutes:

the things network screenshot diy lorawan sensor

The last step for now was to put my DIY LoRaWAN sensors onto stripboard instead of breadboard so they are permanent circuits.  I wanted to make the finished article as small as possible.  There’s various pieces of software you can use for such things, I personally prefer just using paper and a pencil.  You can download templates for printing off which have stripboard layout printed on them.

I usually end up drawing a few versions because once you have the first version you often see a way of making it smaller or simpler.  At the end of this process, my finished DIY LoRaWAN sensor looked like this:

The small white wire on the Lora32u4 board connects the DIO1 pin to digital pin 6.  This is needed when using the LMIC library (and possibly others, I don’t really know why the board comes without this as standard).  I think newer versions of the Lora32u4 board have a simpler way of doing this.

Conclusion

After making these DIY LoRaWAN sensors, I went on to program a simple dashboard that graphs the sensor readings, I will write another blog post on this later on.

I’ve had my sensors running for about six months now, I’ve had no issues.  I have found that the batteries last approximately two months before they need re-charging.  I was hoping for a longer life than that but I am using very small 600mAh batteries, they are also very cheap from eBay and I have my doubts as to whether they really have this capacity.

I haven’t done any range tests, they certainly work anywhere in our building though.

This was a fun experiment and I have learnt a lot about how sensors work and are made, this is obviously way off a finished product and I have no intention of making it into one.

My experience tells me that if you want a sensor, always try to purchase an off the shelf device if you can.  Making your own DIY LoRaWAN hardware gets more costly and time consuming than you can imagine.

Building a LoRaWAN gateway

Our in-house LoRaWAN technical expert, Paul, decided to build his own LoRaWAN DIY gateway. Find out how he did it in this blog post.

If you want to experiment with LoRaWAN and aren’t lucky enough to live somewhere already covered by an existing The Things Network gateway, you’ll need to buy or make your own LoRa gateway.

When I initially started my own testing of LoRaWAN technology I built a DIY LoRaWAN gateway.

The finished gateway

Hardware build

Having already read a few guides and blog posts on building a DIY LoRaWAN gateway using a Raspberry Pi as the controller, I figured this was the best way to go.  I’ve been using Raspberry Pis for experimentation for years, have loads of them at my disposal in the office and know how to use them.

My requirements were something that is a nice self-contained box that can sit in our office and look reasonably good as opposed to a pile of circuit boards on a test bench.  I wanted to connect it directly to Ethernet and power the whole thing using Power over Ethernet (PoE) instead of a separate power supply. 

My DIY LoRaWAN gateway is for indoor use only, just to keep things simple for the housing.

First, I collected the following parts:

  • Raspberry Pi version 3
  • 4GB MicroSD card for the above.  I recommend buying Noobs cards because they are known to work well and SD cards are a bit of a weakness of the R-Pi
  • IMST iC880A SPI LoRaWAN concentrator board
  • iC880A backplane.  Various ones are available, I used the Coredump one (some basic soldering required or order it fully assembled)
  • u.fl to SMA – Pigtail cable for iC880A-SPI from IMST
  • 868MHz antenna from IMST
  • (note: the above two items are available from various places but I ordered them along with the concentrator board from IMST)
  • TP-Link TL-POE10R PoE splitter.  From Amazon.
  • Plastic project box from Farnell.  Part code: 2478793
  • Panel mount Ethernet coupler from Farnell.  Part code: 2708703
  • 2mm thick ABS (plastic) sheet (for mounting all the components to and fitting inside the project box).  From Ebay.
  • 2.1mm barrel connector with twin wire (cut this off an old dead power supply)

I already had various Ethernet cables and tools.  Not many tools are needed, a small drill with a selection of drill bits, selection of screwdrivers, sharp knife (Stanley knife or art knife) for cutting the ABS sheet, some cable ties.

You will also need a method of writing to an SD card, either a USB card reader or a card reader built into your PC/laptop.

Putting it all together

I think a picture speaks a thousand words here so this is a picture showing the internal parts inside my DIY LoRa gateway:

concentrator board inside diy lorawan gateway

  • The Coredump backplane comes with plastic standoffs which sit on the Raspberry Pi mounting holes, these are screwed through the 2mm plastic backing sheet I cut down to size to fit the mounting holes in the project box.
  • The backplane plugs into the Raspberry Pi board and the IMST LoRaWAN concentrator plugs into the backplane.
  • The backplane provides power to both the IMST concentrator board and the R-Pi.  It has a voltage regulator accepting anything from 6.7v to 28v DC input.  So the output from the PoE splitter into connected to this with the splitter set to either 9v or 12v.  This is the only power input needed.
  • In the picture, the purple Ethernet cable is the network+PoE input, the black Ethernet cable is the network connection from the splitter into the R-Pi.

Software configuration

  • Download the latest Raspbian lite/minimal image.  At the time of writing, this was based on Debian Stretch.
  • Burn this on to your SD card.  Even if you bought a Noobs SD card I would still over-write the operating system that comes pre-installed because it includes a lot of software you don’t need, including a full desktop environment.  There are loads of how-to guides on how to do this already so I’m not going to repeat them here.
  • Put the SD card into the R-Pi and then power everything up.
  • SSH into the R-Pi (default login is username ‘pi’, password ‘raspberry’, please change this to something else immediately!).
  • The R-Pi talks to the IMST board over SPI (serial peripheral interface), this needs to be enabled:
    sudo raspi-config
    Select “Interfacing Options”
    Select “SPI”
  • Assuming you want to use The Things Network, there is an installer script available on Github. Install steps:
    sudo apt update
    sudo apt install git sudo
    sudo adduser ttn
    sudo adduser ttn sudo
    sudo visudo
  • add the line:
    ttn ALL=(ALL) NOPASSWD: ALL
  • save and close that file, then install the software:
    git clone -b spi https://github.com/ttn-zh/ic880a-gateway.git ~/ic880a-gateway
    cd ~/ic880a-gateway
    sudo ./install.sh spi
    and follow the instructions. I didn’t bother with the remote management things
  • During installation, it will tell you that gateway’s EUI, you will need this to add the gateway to The Things Network so make note of it.
DIY gateway

Connecting to The Things Network

The Things Network have excellent documentation already so I’ve leave this part largely for the reader to work out.  If you’ve managed the above steps then this will be straight forward.

One thing to note is that you need to select “Legacy Packet Forwarder” when adding the gateway in the TTN Console.  Once you’ve done this you should soon see the status to go “connected” with a green icon, this means you’re ready to go!

diy lora gateway in ttn console
DIY gateway in the TTN Console

Conclusion

This is a fairly quick, relatively cheap way of getting a fully capable LoRaWAN gateway up and running.  I would consider it suitable for experimentation & hobby purposes.

Whilst I’ve found in the past that Raspberry Pis will trash their SD cards from time to time, my gateway has been running mostly non-stop for about 8 months now without any issues.  I’ve only powered it down once or twice though to move it to a different location in our office.

The total cost will be about £250.  Commercial, off the shelf LoRaWAN gateways are now getting down to that price.  The LorixOne gateway we sell for example, isn’t too far off now:

LORIX One LoRaWAN Gateway

What is LoRaWAN?

LoRaWAN is a communication protocol used in Low-Power-Wide-Area-Networks (LPWAN).  It can be considered the equivalent to the 2nd and 3rd layers of the OSI network model (the data-link and network layers).

Typically, LoRaWAN operates on top of LoRa which is the equivalent of OSI layer 1 (the physical layer).

If comparing this to an Ethernet/IP network, LoRa is the physical cables and LoRaWAN is the MAC & IP layers.

One thing to note is that the terminology “LoRaWAN” is normally used to refer to LoRaWAN over LoRa. In actual fact, LoRaWAN can operate over FSK radio too (but this is not commonly used).

So What is LoRa?

I’ve already said that LoRa is the physical layer. This means that it defines the radio modulation used for the wireless communication. It’s how the 1s and 0s are converted to waveforms and sent over the air.

LoRa operates in the sub-Gigahertz ISM (Industrial, Scientific & Medical) frequency bands. The frequencies used vary from country to country but in Europe this means 433MHz & 868MHz. Sometimes these frequencies are referred to as “unlicensed” or “unregulated” bands but that is not true. They are regulated in Europe by ETSI, but they are free to use.

LoRa was developed in France and the patent is owned by a company called Semtech. They license the technology to various chip manufacturers around the world.

It uses something called chirp spread spectrum. A series of 0s and 1s are transmitted using sequences of fast rising and fast falling “chirps”. This is similar to how radar systems work, and echo location used by bats. This allows for very long range communication with a low power usage and very good resistance to interference.

LoRaWAN

LoRaWAN sits on top of LoRa and defines communication protocol and network architecture of the LPWAN.

A LoRaWAN network consists of numerous node devices  talking to one or more gateways/concentrators which are sending data to & from network servers which are themselves relaying the data to application servers.

LoRaWAN network architecture. Source: Semtech
LoRaWAN network architecture. Source: Semtech

The elements are:

  • node devices: typically these are small, wireless sensor devices, often battery powered, sending small amounts of data every so often
  • gateways/concentrators: these can be thought of as converters or access points.  They contain a LoRa radio module (usually multi-channel so they can receive multiple messages simultaneously) and some form of IP connection.  The IP connection may be an Ethernet cable, wifi connection, 3G/4G data connection or similar.  They receive the LoRa communication from the node devices and forward the message to a network server over their IP connection.  The idea is that a single gateway can handle thousands of nodes and provide LoRaWAN coverage over a large area (typically multiple kilometre areas)
  • network server: the gateways send the messages they receive to a network server.  The network server handles de-duplication of messages (as messages can be received by multiple gateways) and forwards the messages onto the correct application server
  • application server: The LoRaWAN messages terminate here, it handles the message encryption, data storage, network joining (node devices joining/registering to the network).

Device classes

In LoRaWAN, devices can operate in three different ways:

  • Class A: A device has it’s radio powered down for the majority of the time, it wakes up when it wants to send data.  After transmission, it briefly listens for a message coming back to it, then goes back to sleep.  This means that you can only send messages back to a device every so often.  It is designed for battery powered sensors such as a temperature monitoring device which sends the temperature every 15 minutes
  • Class B: This is similar to class A except the device will also power up it’s radio and listen for messages at scheduled times set by a scheduling beacon sent by gateways.  This is useful for devices which you need to be able to send a message to more reliably.
  • Class C: These devices have their radio powered on almost all of the time.  The only time they can’t receive is when they are transmitting a message.  It is designed for mains powered devices such as an actuator which you need to be able to control at any possible time.

Key Attributes

  • Long range: LoRa uses chirp spread spectrum modulation to provide usable communication over a long distance.  Typically 10km is quoted, much longer distances are possible, much shorter distances may be experienced in circumstances such as city centres with lots of buildings and therefore poor line of sight
  • Low power: LoRaWAN is asynchronous, devices communicate only when they have data ready to be sent.  This is known as the Aloha method.  There is no synchronisation needed when a device transmits, it simply wakes up, sends a message and goes back to sleep.  This simplicity gives LoRaWAN it’s low power characteristics.  The LoRa radio modulation helps too as large distances can be covered with low transmission power.  LoRaWAN also supports adaptive data rates meaning devices closer to gateways can reduce their transmission power even more.  The idea is that sensors running off single small batteries will last years
  • Low cost: because LoRa uses ISM frequency bands, you can operate your own LoRaWAN radio network without having to pay for air space.   You must adhere to the regulations in the area you operate.  You can purchase a gateway and a number of sensors and operate your own LPWAN for a low cost
  • Security: LoRaWAN incorporates two layers of security.  Network security layer ensures authenticity of the node in the network.  Application layer security handles encryption of data between the nodes and the application server so messages cannot be read or interfered with in transit.  AES encryption is used with a key exchange between the server and the node.  It is also possible (and some would argue desirable) to build an extra layer of application security on top of LoRaWAN in your own application, such as using TLS certification verification.
  • Low data rate: the actual data rates vary from region to region but in Europe, 250bps to 5.5kbps is typical.  Clearly this is no use for web browsing, phone calls, watching Netflix etc…  Is it designed for tiny amounts of data from simple devices such as sensors.

Further reading

https://www.lora-alliance.org/sites/default/files/2018-04/what-is-lorawan.pdf

https://en.wikipedia.org/wiki/LoRa

https://www.thethingsnetwork.org/docs/lorawan/