GumStix's LoRA solutions

Build a LoRA Gateway with a Gumstix Module

Technology Editor Bill Wong builds a LoRA gateway using components from Gumstix, Microchip, and RisingHF.

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.

1. The Overo Conduit LoRA Gateway package includes RisingHF’s RHF0M301 LoRA module (left), a Gumstix Overo module (bottom right) and a carrier board (top right) that combines the two.

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.

2. There are quite a few hops in a typical LoRA IoT solution. The Gumstix gateway is in the middle. The Things Network distributes data to cloud-based systems like myDevices’ Cayenne.

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.

3. The assembled gateway has the RHF0M301 module on the bottom. The Gumstix Overo module has its own Wi-Fi/Bluetooth antenna. The Ethernet connector is linked to the Overo module.

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.

4. Two LoRA nodes were used, including the Gumstix Strata Weather Station Node (left) and the Sodaq ExpLoRer (right) with a built-in PC antenna.

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.

5. TheThingsNetwork provides the LoRA services. It supports public and private gateways.

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 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.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.