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.



Alliot Named Official Kerlink Distributor

We’re delighted to share our latest news with you! We have today been announced as Kerlink’s official UK distributor. This appointment marks a big step for Alliot and our mission to make IoT accessible to all. Distributing a comprehensive range of their leading LoRaWAN® equipment, software and services, here’s an insight in to what Kerlink could offer to you and your IoT projects.

Kerlink Gateways

As a key component to any IoT project, Kerlink cover every eventuality with gateway options to suit every budget and use. From the Wirnet IFemtoCell, to the robust Wirnet IBTS outdoor gateway, Kerlink have you covered.


Kerlink Wanesy Management

Remotely manage and monitor your Kerlink gateways with Wanesy. Whether you have a single gateway on a small private network or multiple gateways on a commercial network, with Wanesy you can remotely deploy, operate and manage your LoRaWAN® IoT connections.

Offering a truly flexible approach, Alliot enables you to take as much or as little as you require to build your solution. Get in touch to find out more and discuss your requirements today.

CENSIS 6th Technology Summit and Conference, 7 November 2019

The team at Alliot are delighted to announce we are exhibiting at the 6th Technology Summit and Conference which takes place at the Royal Concert Hall in Glasgow on 7 November 2019.

CENSIS is Scotland’s leading sensing, imaging and IoT event – a day of top class speakers, exhibitors, debate and networking.

What to expect:

Over 500 delegates attended in 2018, creating a day that informed, inspired and challenged. You’ll get the most from the day if you are:

  • A company or organisation involved in sensing, imaging and/or IoT.
  • A company or organisation that needs to use, or you’re interested in using, sensing, imaging and/or IoT to improve or grow your business.
  • An academic researcher or doctoral/postdoc researcher.
  • Working in knowledge exchange or business development in the university or college sector. The Summit is not aimed at university undergraduates.
  •  
    Registration is open – click here to book your ticket
     
    CENSIS 6th Technology Summit

    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.