Kentix SmartXcan Fever Screener Review

We’ve been busy testing the new Kentix SmartXcan Fever Screening device, throughout this blog we’ll be sharing our findings and thoughts in our Kentix SmartXcan Review.

The Kentix SmartXcan (which we pronounce Smart Scan) is designed to quickly take a reading of human body temperature for the purpose of fever screening.

What is it?

The idea is that you have the device inside the entrance to your building and any visitors, staff etc. will scan themselves on entry before proceeding further. If their body temperature is above a certain threshold then a visual and audible alarm sounds and that person must then leave (and would probably be recommended to self-isolate).

I feel that this will play an important part in controlling the spread of COVID-19 as we learn to live with the virus in the longer term. I also feel that people’s attitudes towards the spread of illness will change forever and people will be more aware of bringing any illness into a workplace such as influenza.

The device is a compact unit in plastic casing, there are no buttons on it for normal usage so it is designed to be zero touch to avoid spreading germs. It contains a number of sensors used to take a reading. The main component is a thermal imaging sensor, there are also a distance sensor, ambient temperature and humidity sensors.

How it works…

How it works is, you hold your head roughly 30cm in front of the device, the distance sensor then activates the thermal imaging sensor and a thermal reading is taken. So there is no need for anyone to touch the device in operation at all. This is combined with the ambient temperature & humidity and ran through Kentix’s algorithms to work out a body temperature. It recognises the area around the eyes to do this so it is getting a body temperature rather than a skin surface temperature. In my testing, it is very accurate when compared with a digital mouth thermometer.

If the reading is below a certain pre-set temperature, then the LEDs on the front of the device light up green and a single loud beep sounds, you are OK to go. If the temperature is slightly above this level, some red LEDs will appear along with a prolonged and repeating beeping, if the temperature is above the highest set threshold then the alarm is more insistent. The device comes with sensible default settings for these levels but they are fully adjustable.

This is an image of my head from the Kentix SmartXcan web interface, looks like I don’t have a fever today

Installing the Kentix SmartXcan

To use the scanner stand-alone there’s nothing you need to do other than power it on. It is powered by standard 802.3af 15.4W PoE (Power-over-Ethernet) so can either be connected to a PoE enabled network, or an injector can be used (which we can also supply if needed). When powered on, the thermal sensor needs time to warm up which takes ten to fifteen minutes, the LEDs around the sensor will flash red until it is ready to use, so bear that in mind when testing, you do need to wait for it to warm up.

Going further, the device has a built-in API which you can use to remote control it and it can integrate with other systems using webhooks, either for logging activity (such as anonymous temperature readings, or non-anonymous if using the RFID version with tags for your staff), or integration with access control systems to actually stop people with fevers and high temperatures from going further into your building.

One thing to note is that the device must be used indoors, because it needs to be able to take an accurate temperature reading, direct sunlight and variable temperatures experienced outside will affect it’s performance.

The Verdict…

I have scanned myself with it many times and fortunately I appear to have never have had a fever. Amusingly though, my cat jumped on to my desk (since I’m currently working from home still) and looked at the scanner. It took a reading and decided my cat had a slight fever with a temperature of 38.5 degrees. This did worry me slightly but after a web search, I discovered that a cat’s normal body temperature is between 38 and 39 degrees. So it would seem it accurately read my cat’s temperature too!

A nuisance but fever free

I don’t think fever/temperature screening is the be-all and end-all of protecting work places and public places from COVID-19 but I do feel that it is an important part of it and this device when coupled with other measures can help us get back to some level of normality.

I know there are concerns with any device that is taking any kind of image of people, however this is fully GDPR compliant in that it is not obtaining any identifying information at all. That is unless you are using the RFID version and intentionally logging temperatures of staff, it is then up to you to handle that data correctly. It’s worth mentioning that the device doesn’t actually store the thermal images, it just displays them temporarily in the web interface. As you can see from above, it is not possible to identify a person from these.

We will have stock in very soon so please get in touch to find out more.

Netvox Payload Decoder for The Things Network

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

What is a payload decoder?

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

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

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

Netvox Payload Decoder in The Things Network

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

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

View and download it on Github.com

LoRaWAN Security

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

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

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

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

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

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

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

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

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

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

LoRaWAN GPS: Technology Options

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

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

1. GPS

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

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

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

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

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

2. LP-GPS (low power GPS)

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

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

3. Wifi Sniffing

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

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

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

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

wifi sniffer data vs lorawan gps

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

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

‘True’ LoRaWAN GPS

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

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

A simpler alternative

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

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

NB-IoT Introduction and Testing

What is NB-IoT?

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

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

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

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

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

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

Trying out NB-IoT

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

nb-iot vodafone sim card

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

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

And an Arduino MKR-NB-1500 board:

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

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

nbiot_microcontroller_code

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

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

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

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

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

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

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

What next, what use is this?

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

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

Verdict on NB-IoT testing

This experimentation has taught me a few things.

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



Netvox Sensor Range Now in Stock

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

You can see the full list with details here:

All Netvox Sensors

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

Achieving long battery life with LoRa sensors

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

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

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

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

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

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

Optimising LoRa Battery Life

  • Send small amounts of data:

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

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

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

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

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

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

You should always avoid sending text.

  • Send messages less frequently:

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

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

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

  • Keep LoRa Spreading Factor as low as possible:

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

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

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

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

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

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

This screenshot from the ThingsNetwork console shows ADR in action:

lora battery life

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

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

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

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

LorixOne LoRaWAN Gateway – What Does It Do?

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

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

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

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

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

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

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

Radio Capabilities

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

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

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

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

Software and Configuration

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

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

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

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

Gateway Variants

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

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

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

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

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

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

Both are currently the same price.

Verdict

Things I like about this gateway are:

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

Limitations:

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

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

LoRaWAN DIY Sensor

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

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

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

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

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

I wanted to make four different DIY LoRaWAN sensors.

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

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

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

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

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

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

DIY lorawan sensor using Lora32u4 board

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

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

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

prototype DIY lorawan sensor using lora32u4 board

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

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

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

My program operates as follows:

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

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

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

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

programming lorawan diy sensor using otaa

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

the things network screenshot diy lorawan sensor

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

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

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

Conclusion

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

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

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

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

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

Building a LoRaWAN gateway

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

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

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

The finished gateway

Hardware build

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

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

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

First, I collected the following parts:

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

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

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

Putting it all together

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

concentrator board inside diy lorawan gateway

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

Software configuration

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

Connecting to The Things Network

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

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

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

Conclusion

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

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

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

LORIX One LoRaWAN Gateway