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 one using The Things Network, you need some sensors to start collecting data.

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

After a small amount of research, I found the Adafruit Lora 32u4 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, such 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.

For 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 my sensor circuit.  As this is an experiment only, I designed it with a view to mounting on stripboard/veroboard.  I ended up with this:

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):

That’s the hardware largely sorted, 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 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).

I uploaded this code to my four 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 last step for now was to put my 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 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 board have a simpler way of doing this.

Conclusion

After making these 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 them 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 hardware gets more costly and time consuming than you can imagine.

 

Building a LoRaWAN gateway

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.

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

The finished gateway

Hardware build

Having already read a few guides and blog posts on building a 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 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 oppose to a pile of circuit boards on a test bench.  I wanted to connect it directly to Ethernet and power the whole thing using PoE instead of a separate power supply.  It is for indoor use only.

Firstly 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 project box:

  • 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 concentrator plugs into the backplane
  • The backplane provides power to both the IMST 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

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 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 when 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 but what this really means is 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 is designed to operate 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, it is just that 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 where 0s and 1s are transmitted used sequences of fast rising and fast falling “chirps” in a similar fashion to radar systems 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/