Hands-on with the PiSupply LoRa Gateway

The PiSupply IoT LoRa Gateway HAT for Raspberry Pi was announced last month, one of a range of different LoRa boards in the company’s Kickstarter campaign. The gateway has now shipped to beta testers, and I managed to get my hands on one of the fifty pre-release sets of hardware sent out for review.

With LoRa taking an arguable, abet perhaps shaky, lead in the standards battles amongst the three main competing standards for a low-power wireless for the Internet of Things, the arrival of the gateway comes at an interesting time in the ongoing war.

The gateway is built as a Raspberry Pi HAT, and like a couple of other builds we’ve seen in the past, uses the RAK Wireless RAK833 module. Coming in three versions — although Pi Supply is offering the gateway only in an 868MHz (EU) and 915MHz (US) version, depending on which frequency band you need for your local environment — the RAK833 SPI module comes with a mini-PCI Express connector rather than something more maker-friendly, which is where the Pi Supply HAT comes into the picture.

The gateway comes as a kit, but don’t worry, there isn’t any soldering required. Just insert the provided 40-pin male header block into the headers on the HAT and then—after screwing the brass spacers into your Raspberry Pi board—push the HAT firmly down on to your board.

The pulling off the black plastic clip, you then need to slide the RAK 833 module into the HAT, and push down firmly. Then peel the backing off the heatsink and attach it to the unlabelled section of the RAK module, and finally, snap the connector for the stubby aerial into place.

Be aware that the, on first glance, massively oversized passive heat sink that ships with the gateway really is needed. In continuous operation the RAK board gets very hot, even with the heatsink in place, it runs 55 to 60C and heats the Raspberry Pi board itself up to around 45C as a secondary effect.

Pi Supply offer three options to install the software needed onto the gateway. The first, and much easiest method, and the one I used myself, is simply to download the prebuilt SD Card image and then do some quick configuration.

The next method is to deploy using Balena, that’s Resin.io as was for those of us that haven’t been paying attention lately. That gets you some extra goodies, including remote cloud management, similar to Arduino’s new LoRa gateway, but does take some extra work over the easiest method.

Finally, if you’re a glutton for punishment, you can grab the source from the Pi Supply Github repo and build and install by hand. This is predictably the messiest way of going about things, but if you the sort of person that prefers to know what’s going on under the hood it might well be the most satisfying.

To configure our gateway hardware to talk to The Things Network we’ll first need to configure it in the The Things Network Console.

Clicking through to register your first gateway you need to generate a Gateway ID for your self-built gateway—generally I use the MAC address of the WiFi adaptor as that’s more-or-less guaranteed to be a unique string.

You’ll then need to copy and paste these, plus a Gateway Key that will be created by The Things Network, into a local configuration file on your Raspberry Pi SD Card, or Docker image, depending.

Since the config file lives in /boot you can get everything configured and working while you’re setting up the Raspberry Pi’s wireless network.

Once you have the card image configured, you can pop it into the Raspberry Pi and boot it up. After a little while a bright blue light should appear on the RAK833 card, and if you check The Things Network Console you should see a green dot and the word “Connected” next to the gateway’s status.

While we now have a gateway that is, at least in theory, connected to The Things Network and is offering LoRaWAN coverage. But there’s only one real way to test whether everything is working. That’s to deploy some LoRaWAN devices and transmit some data.

As it happened I had several Pycom FiPy boards — which supports WiFi, BLE, cellular LTE-CAT M1/NB1, Sigfox, as well as LoRa — on hand. I’d previously been running one of them as a single-channel “nano-Gateway” using its Wi-Fi for backhaul. So I broke out one of these to test the gateway along with a PySense base board to give me some sensor measurements to report.

Now obviously the FiPy is an expensive board, you’d be equally well served with Pycom’s LoPy board — which supports only WiFi and LoRa — or The Things Network’s own Things Uno. Or really any other LoRa capable board.

While any LoRa device in range of your new gateway will have its packets received, and sent up stream to The Things Network, the data packets will be dropped on the ground unless they have somewhere to go. In other words The Things Network needs to know where to route the packets your gateway is receiving.

To do this we need to first create an application inside The Things Network Console. To do that all you’ll need to do is type in a unique Application ID string—this can be anything—and the console will generate an Application EUI and a default Access Key which we’ll use to register our devices to our application.

Once we’ve registered an application, all we have to do then is register our individual test device—or later perhaps many devices—to that application so backend to knows where to route packets from that device.

This can be done from the Application’s page in the console.

We need the Device EUI, which I grabbed directly from my board using the Python REPL. The output was a hex string which I could just paste directly into the online console.

from network import LoRa
import ubinascii

lora = LoRa(mode=LoRa.LORAWAN)
print(ubinascii.hexlify(lora.mac()).upper().decode('utf-8'))

You’ll also need to make up a unique Device ID, and since my device is a FiPy and supports it, I could again use the WiFi MAC address of the board for that.

All we need now is to deploy some software onto our device and push the data from it up to our Gateway and The Things Network.

If you take a look at your Device page after registration you’ll need the Application EUI and Application Key to let your board talk to the LoRa network. Or rather, to let the network correctly route packets from the board back to your Application.

Here’s some Python code to grab the temperature, pressure, and humidity from the Pysense base board attached to our FiPy and push it to the LoRa network.

from network import LoRa
import socket
import time
import ubinascii
import pycom
from pysense import Pysense
from LIS2HH12 import LIS2HH12
from SI7006A20 import SI7006A20
from LTR329ALS01 import LTR329ALS01
from MPL3115A2 import MPL3115A2,ALTITUDE,PRESSURE

off = 0x000000
red = 0x220000
green = 0x002200
blue = 0x000022

pycom.heartbeat(False)

py = Pysense()
mp = MPL3115A2(py,mode=ALTITUDE) # Returns height in meters.
mpp = MPL3115A2(py,mode=PRESSURE) # Returns pressure in pascals
si = SI7006A20(py)
lt = LTR329ALS01(py)
li = LIS2HH12(py)

lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)
app_eui = ubinascii.unhexlify()
app_key = ubinascii.unhexlify()
lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)
pycom.rgbled(red)

while not lora.has_joined():
    print('Not joined yet...')
    pycom.rgbled(off)
    time.sleep(0.1)
    pycom.rgbled(red)
    time.sleep(2)

print('Joined')
pycom.rgbled(blue)

s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5)
s.setblocking(True)

i = 0
while True:
    i = i + 1
    temperature = str(si.temperature())
    pressure = str(mpp.pressure())
    humidity = str(si.humidity())
    string = "{\"count\": %i,\"weather\":{\"t\": %s,\"p\": %s,\"h\": %s}}" % (i,temperature,pressure,humidity)
    print(string)
    s.send(string)
    pycom.rgbled(green)
    time.sleep(2.0)
    pycom.rgbled(blue)
    time.sleep(58.0)

Running this on the FiPy you should see a red light on the board blink to blue after a while as it joins the LoRa network provided by the Pi Supply gateway.

Then every minute or so you should see a green status LED, the board has just pushed a packet up to The Things Network.

Clicking on a packet will show you a raw byte stream, the payload data, along with some meta data around the packet itself.

Our device is dispatching a JSON object up to The Things Network via our gateway. However what you’ll see in the console is a series of hex values, the raw bytes, we’ve send up to the cloud. Don’t worry, it’s really rather trivial to add a decoder to our application to allow us to translate this back into our JSON object so we can see what is being sent back in the console.

Clicking on Payload Formats inside your Application will let you add a handler to decode that string of bytes.

We’re sending a JSON object so ours would look a lot like this,

function Decoder(bytes, port) {
    return JSON.parse(String.fromCharCode.apply(null, bytes));
}

or if you’re just testing things out, and you want to send plain text, then the decoder is only a little bit more complicated.

function Decoder(bytes, port) {
    return { MyPacket: String.fromCharCode.apply(null, bytes) };
}

Afterwards if you go to the Data tab of the console,

You’ll see the decoded packet in the “Fields” entry just above the packet meta data. However right now, while we can see the packets in real-time as they arrive at The Things Network, they’re still being dropped on the floor.

If we want to save our data we need to go ahead and add an integration.

Perhaps the simplest of these is the Storage Integration, this is a free integration offered by The Things Network themselves that stores your data and makes it available through an API. Your data is stored for seven days.

However there are a number of other integrations ranging from IFTTT, through to Amazon, and OpenSensors.io. Although perhaps the most flexible is the HTTP Integration.

The HTTP integration will allow you to uplink data your data to an arbitrary HTTP endpoint and will also allow you to receives downlink data over HTTP and forward it back to your device. From this point you’re moving out of hardware, and networking, and into the world of Big Data.

Final production hardware should be going out to Kickstarter backers in February or March next year, but if you didn’t back the gateway on Kickstarter pre-orders are now open on the Pi Supply site. The gateway cost £129.98 plus shipping, with both EU (868 MHz) and US (915 MHz) versions of the HAT available, and pre-orders made now should start shipping just as soon as the Kickstarter backers have their orders fulfilled.

For something that’s supposed to be somewhat rough around the edges, the LoRa Gateway HAT from Pi Supply worked remarkably well out of the box. While the instructions are still a bit sparse, especially if you want to deploy your gateway using Balena, or build everything yourself from source, they cover the basics. Pi Supply also have a couple of months to work on them before shipping hardware to their Kickstarter, and the documentation I’ve seen has improved just over the couple of days that I’ve been my hands on with the hardware.

I’ve only had the gateway up and running for a couple of days, so I can’t swear to long-term reliability or stability. However I am somewhat worried by the operating temperature, especially if you’re considering permanent deployment inside an enclosure. But having said that, if you’re looking to self-build a LoRaWAN gateway, and especially if you’re thinking of configuring it to connect to The Things Network which this gateway does more-or-less out of the box, then the new Pi Supply hardware seems like a good starting point. If you’re in the market for a cheap self-build LoRa gateway, this one definitely should be on your short list.