The LoRa Alliance’s LoRaWAN (Long Range Wide Area Network) is a Low Power Wide Area Network (LPWAN) designed for the wireless Internet of Things (IoT). This low speed network uses a lightweight gateway with a range measured in kilometers. LoRA uses unlicensed spectrum like Wi-Fi.
LoRA gateways/concentrators are available from a number of sources such as MultiTech, Link Labs, and Kerlink. Companies like RisingHF sell modules. LoRA systems are country-specific because they operate at different frequencies.
Gumstix also has modular LoRA solutions, including its family of LoRA Gateways. I tried my hand at LoRA using the Overo Conduit LoRA Gateway (Fig.1) based on RisingHF’s RHF0M301 module.
There are actually quite a few components in this LoRA solution (Fig. 2) and LoRA in general. This is because LoRA hands off much of the gateway functionality to a server that can be separate from the gateway. In this case the solution uses The Things Network (TTN) as the server. Incoming messages from a node are forwarded to the server with minimal processing. Metadata, such as when a packet is received, is sent to the server. Likewise, the server determines how response packets are sent back to the node. This may be a different path, as a node could be serviced by overlapping gateway coverage.
The server also handles packet sequencing. This is important, since a series of packets from a node may arrive through different gateways. This approach has the advantage of reducing the computational requirements and complexity of the gateways.
TTN only manages the communication aspects of LoRA. It provides a more conventional interface for IoT services like myDevices’ Cayenne, where data would typically be used and stored.
TTN and Cayenne are free services with limits and both are available as commercial services. There are reasons for using each approach, and this will depend upon on the LoRA application. The free services do make it easier to evaluate the system.
The kit comes unassembled, but it is a trivial exercise to plug everything together (Fig. 3). There are tiny plastic parts, so it takes a little care, but the system is pretty rugged once it is assembled. An external power supply is included, as the micro USB connection is for debugging only.
The Gumstix Overo Conduit Gateway board is available separately, so you can plug in any Overo module available from Gumstix. The Gumstix LoRaWAN Gateway Kit I used came with Overo AirSTORM-Y COM. This has an 800 MHz Texas Instruments (TI) AM3703 Sitara and a TI WiLink 8 wireless module with 802.11b/g/n Wi-Fi and Bluetooth support. Fast Ethernet support is available through the COM connectors that link the module to the RJ-45 jack on the Gateway board.
I tested the gateway using two LoRA nodes, including the Gumstix Strata Weather Station Node and the Sodaq ExpLoRer with a built-in PC antenna (Fig. 4). The Weather Station has a barometric sensor and temperature sensor along with a GPS jack. Of course, the first step is to get the gateway operational.
The documentation from Gumstix was a work in progress since I was one of the first to try out the solution. The first step is to download and copy Linux to a microSD flash memory card that plugs into the Overo module. Gumstix has builds online, so it was a matter of formatting the flash card with a DOS and Linux partition and then copying the appropriate files over.
Linux will be running the LoRA packet forwarder that is available on Github. Building it using a cross compiler is an interesting exercise, and I had to load up the Go language on my Linux machine. Gumstix now has the binary available, so this exercise can be skipped, although it is one that developers will eventually want to do so they can have a handle on all the components involved in their solution.
This is also true for the Yocto support for Gumstix Linux. The binaries are available and make evaluation an afternoon project. Setting up a Yocto build is a bit more involved.
In any case, once the binaries are installed it was a matter of popping the microSD card in and then watching the system boot using a terminal program (I used PuTTY) connected via the microUSB link. There are some text file configuration steps needed, including configuring the TTN support (Fig. 5) as well as setting up the network interface. I tried both the Wi-Fi and Ethernet connections. This incarnation of Linux uses NetworkManager so command line configuration is trivial.
Signing up for an account on The Things Network is straightforward. You can then configure one or more gateways. Each has a configuration string that needs to be copied to the gateway. The gateway link to TTN can be tested at this point.
The next step was to get the test nodes up and running. This is actually a two-step process since the nodes need to be configured for connection to the gateway, and then to the IoT service in the cloud. I already had an account on the myDevices service so it was a matter of creating two virtual devices for the two nodes I had in hand.
Each LoRaWAN device has a 64-bit unique identifier (DevEUI). There is also an application unique identifier (AppEui) and a Gateway unique identifier (GatewayEui). The nodes need this information to be linked to the appropriate service on the internet, as well as encrypting data so it can be used by the appropriate party. This means that encrypted application data will pass through TTN on its way to Cayenne where it is then decrypted.
The configuration of the two nodes is different, but both use the Arduino IDE to create a LoRA application. The sample application for each has its own dependencies. The applications need the AppEui and key from TTN. They both emit the DevEui when the application starts up. They do not connect until the DevEui is registered with TTN.
The device can be connected to the Cayenne service once they have been connected through the gateway to TTN. The Cayenne service can display the data updates coming from the devices.
The process is typical for a development environment. The weather station has about 50% headroom for dealing with a custom application and is essentially limited by the AVR micro. Then again, LoRA nodes tend to be compact, low power, and battery-operated, only handling a few sensors. There isn’t a lot of number crunching. The Sodaq ExpLoRer has a heftier microprocessor with more memory.
The Gumstix carrier board was designed using Gumstix’s Geppetto, a web-based design tool. Designs can be turned into fully populated boards for a fixed fee of $1,999, plus a per-board charge based on the quantity and the board components. The header for the RisingHF’s RHF0M301 module is one LoRA option. The other is a LoRA transceiver. This is typically used for building a LoRA node like the Strata Weather Station Node I tested. It uses a Microchip ATmega32U4. Developers can use the weather station as a starting point or design something from scratch.
There is also a Gumstix carrier board for the Raspberry Pi Compute Module. This is essentially the same configuration except that the Overo board is replaced by the Compute Module. The Raspberry Pi runs the same forwarding software (recompiled, of course). The rest of the configuration is the same. There are a number of LoRA gateways built around the standard Raspberry Pi, as well including one from Seeed that also uses the RisingHF RHF0M301 module.
Overall, it is possible to get a LoRA gateway and node up and running within a day. Subsequent development at the client is straightforward and system configuration is relatively easy, as long as TTN and Cayenne are the targets on the internet. Changing either will be a more time-consuming exercise.
If you are looking for an open source LoRA server, check out loraserver.io sponsored by Cable Labs. The Overo or Raspberry Pi could easily handle this server. There are commercial LoRA servers and combined gateways and servers, as well. These allow private LoRA networks to be created and managed. These can coexist with other LoRA networks within the same area.
