The Things Conference on Tour UK, 14-15 October 2019

The Alliot team are proud to confirm we are participating at the next edition of The Things Conference on Tour UK, which is being held on 14-15 October 2019 at Reading Town Hall.

Meet and Network with members of The Things Network Community and the Local Authorities, Housing Associations, Public Sector Organisations, Research & Higher Education Institutes and Businesses leveraging this emerging technology.

  • Explore the applications of LoRa enabled devices
  • Learn about different market ready options
  • Discover what is coming out of the R&D community before anyone else
  • Get hands on with workshops exploring ethical data collection, ultra low power and Node RED
  • Explore LoRaWAN by making your own LoRa device
  • Learn how to make reliable, secure and scalable LoRaWAN applications

 
Come and visit us at The Things Conference On Tour UK to see the products & services we have to offer.
 
Registration is open – click here to book your ticket
 
The Things Conference on Tour UK

LoRaWAN Applications

A few examples of the vast range of use cases:

Smart Metering / Energy Monitoring

  • Reduces the need for traditional manual processes allowing instant, remote updates of electricity, gas, water & heat consumption.
  • Retrofit sensor systems to existing client infrastructure.
  • Improve efficiency by highlighting and targeting areas of unusually high energy consumption.
  • Environmental Monitoring

  • LPWAN technology is perfectly suited for environmental monitoring due to the wide range of solutions available. Gather data on temperature, humidity, light, air quality (carbon dioxide, PM2.5 etc), smoke detection & water quality to name but a few.
  • Carbon monoxide sensors for homes managed by others such as Housing Associations or landlords to ensure the occupants are living in safe conditions.
  • Transport & Asset Tracking

  • In the realm of transport infrastructure, railways are big users of sensor networks. These can be used, for example, to monitor potentially damaging vibrations in bridges, through deformation of the tracks, to movements in embankments that could indicate potential collapse.
  • Keeping track of anything from logistics equipment (trolleys, fork lift trucks etc) right through to entire fleets of vehicles by installing a discreet, long lasting sensor not only tells you the location of the equipment in real time, it can also ensure they are being used more efficiently which could in turn assist with fleet management & inventory decisions.
  • Agriculture

  • Even agriculture gets in on the act, with smart farms monitoring soil moisture levels and crop health, providing machinery diagnostics, keeping an eye on crop storage conditions and tracking & monitoring livestock.
  • Temperature sensors could be used to ensure the optimal conditions for Chicken Farmers to maximise their yield.
  • A smart sensor system can help maximise a farmers yield therefore reducing water consumption, optimising the use of fertilizers and pesticides which increases production & lowers costs.
  • Water Monitoring

  • BT have announced they are launching a Smart Water project with Northumbrian Water which will be deployed across Sunderland, with around 150 sensors installed to capture water flow, pressure and quality enabling Northumbrian Water to gain visibility into operational insights.
  • Just last month water meters were deployed across the south east to gather real time information on water capacity levels, consumption and pass through; this is fed back to Icosa Water via a smart metering platform.
  • Beer Keg Supply Chain Optimisation

  • A novel application developed at the University of Wollongong in New South Wales, Australia, involved fitting sensors to beer kegs. Called the Binary Beer project, it uses LoRaWAN to transmit the fill levels and environmental conditions of kegs back to the brewer in real time.
  • IoT LoRaWAN continues to grow

    The IoT landscape continues to develop. More and more infrastructure is being added, most recently (24/7/2019) Norfolk County Council’s Digital Innovation and Efficiency Committee has approved a proposal to launch a LoRaWAN network to enable early adopters to test IoT (Internet of Things) applications.

    The proposal includes a number of Gateways around Norwich connected to The Things Network that will receive information from Sensors placed around the city.

    It does not take long to set up a LoRaWAN network either, everything should be in place by September 2019.

    To the uninitiated IoT can be seen as a dark art when the reality paints a very different picture, especially when you have the right partner.

    The kit list can be broken down into the following categories;

    Nodes / Sensors –

    These are the devices that will collect & transmit the data

    Concentrator / Gateway –

    These will collect the data signals and send it to…

    Network Server –

    This collects all of the data via the Concentrators / Gateways and links that data to an…

    Application Server –

    Which interprets the data that can then be reviewed against a set of tolerances and can be used to automate actions based on the data that has been received, for example triggering an alarm.

    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

    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.

    LoRa is known for it’s long range and low power usage.  In fact, LoRa stands for “Long-Range”.  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.

    Making the battery last a long time

    • 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.  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 CO² 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.

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

    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.

    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/