Designing a 1-ch gateway

This document describes in more detail the design considerations for a 1-channel gateway.

Introduction

Some time aho Thomas Veldkamp published his first version of a single channel gateway. His project started as a proof-of-concept to prove that it was possible with a small computer and a LoRa radio to build a gateway that would listen to one channel only and on one band. The first version was based on a Raspberri-PI and a sx1276 LoRa radio.

I have taken his code and ideas as a starting point and ported the gateway to an ESP8266 platform with a RFM95 radio. DNS support, NTP support and a webserver were added to the gateway making it usable in a lot of situations. The cost of the 1-channel gateway descreased from 50+ Euro to 15 Euro making it possible for a lot of DIY people in the TTN community to build their own LoRaWAN gateway.

Over the last months several things have happened, I liked to add downstream functions to the gateway something that had to be possible based on the LMIC-1.5 source code and several Semtech documents. At the same time Jaap Braam seemed to have exacty the same ideas when he made his version available in LUA. Jaap beat me by several days with his version, and even has a new version available that is capable of scanning multiple bands (not channels) for JOIN messages before responding over one well-known frequency channel and band.

This article aims to provide additional background on the do's and don'ts of designing a LoRa single channel gateway. It is written mainly for myself, I will probably forget a lot of technical details if I'm not writing them down, and maybe it is of use for others as well.

Hardware and Design choices

In order to make the project not overly complicated, we have taken some decisions in hardware support etc. Please find the most importants choices below:

• The MCU used is a ESP8266 based microprocessor, I standardized on the Wemos D1 mini (about $ 3.00 on Aliexpress)
• The LoRaWAN radio used is the sx1276. Parts of the code still deal with sx1272 as well, but since I do not have one of these devices available I have decided not to support them for the moment.
• We implement the Semtech gateway description: Gateway to Server Interface, ANNWS.01.2.1.W.SYS, Revision 1.0
• We use the LoRaWAN specification 1.0 and later 1.1
• The Gateway was tested on TeensyLC based motes and on 3.3V Arduino Pro-Mini clones. For the Arduino, the original 8MHz version with the big chrystal works fine, and the 16MHz version does as well (running on 16MHz!).

These Arduino clones work (click on the picture to enlarge):

Arduino Pro-Mini clone 3.3V, 8MHz	Arduino Pro-Mini clone 3.3V, 16MHz

Base architecture

This section described the basic protocol as supported by the gateway. A gateway should support only a few message formats:

• PUSH Message and their PUSH_ACKs. Lora devices send their sensors valeus to the gateway using the PUSH messages. These PUSH messages consist of a standard 12-byte header followed by the actual message in JSON format.
  The JSON message is an array of elements. Each element contains several meta fields and the actual data field containing the the sensor payload (encrypted with the AppSKEY and then Base 64 encoded). So optionally, a PUSH message may consist of several messages that are concatenated as elements in the JSON message structure.
  The STAT message is a special variant of the PUSH message but it contains no sensor data. Instead it contains Gateway statistics that the gateway will send to the server. Since these are PUSH messages, the gateway may use another PUSH message for sending it's stat message or it may at any time send it's own message.
  
  
• PUSH_ACK messages are only 4 bytes in length.The PUSH_ACK message is sent by the gateway as an acknowledgement of recept.
  
  
• PULL_DATA messages are 8 bytes in length and are sent by the LoRa device to inform the Server behind the gateway that it can send downstream messages to the node if it wants to. As the nodes may not be ready for continuous reception, the gateway will forward these messages in two timeslots after the node itself sent its PUSH message.
  
  
• PULL_ACK; The server will send a PULL_ACK message confirming receipt of the PULL_DATA message.
  
  
• PULL_RESP (response) is a downstream data message sent by the server to the LoRa device. It has 4 header bytes and
  
  
• TX_ACK (version 2 of protocol). This message is send in reponse to the PULL_RESP message starting version 2 of the gateway messaging standard. It contains a 4-byte header optionally followed by data bytes. The databytes can be used to give the gateway/server more information for example why the message was not(!) accepted.

V1: Simple Read-only Gateway

The simple version of the LoRa 1ch gateway is using PUSH messages only, and PUSH_ACK messages are not read.

• The building description for the ESP Gateway hardware is found here

The first version was a very basic version which would only forward messages from LoRa node up to the server.

V2: Bi-directional data

The original simple 1ch gateway, is only forwarding PUSH messages to the server is much simpler than the version 2 gateway.
Version 2 gateway will also handle JOIN_ACCEPT messages coming from the server message that the gateway has to forward exactly at the right moment, and it will also forward data messages in the RX1 and RX2 timeframe. The hardware is 100% equal between the two versions.

One of the most important additional features of the new gateway is it's ability to send periodical PULL_DATA requests to the server. That means that the backend server will receive these messages every minute or so. Unlike the STAT message, which is also sent every 30 seconds by the single channel gateway, the PULL_DATA message is (accroding to spec) interpreted by the server as the gateway being alive. And as said before, the PULL_DATA message informs the server that the gateway may send PULL_REQUEST messages.

in Class A, the node devices will only receive messages in one of the defined receive windows RX1 or RX2. These receive windows are region defined and for the European region (868MHz) in the LoRa standard