LoRa Gateway project

A high reliability DIY RPi-based TTN LoRa Gateway

This gateway integration was designed for low cost and high reliability on a Powered-Over-Ethernet Rapspberry Pi 3B+ with uninterruptable power supply and hardware watchdog. Furthermore it can be remotely located and managed whilst being robust against power failures and SD card corruption issues.

This is a very Do_It_Yourself, hands-on project but the end result will be as good, if not better, than any of the expensive commercial LoRa gateway products out there.

 View documentation
 Image gallery
 RAK Wireless: Store | Downloads | Forum
 Beyond Logic's RAK Concentrator Pi HAT
 PoEUPSPi uninterruptable PoE Raspberry-Pi power-supply
 TTN The Things Network
 Gerber file-set for PiCarrier PCB download
 Gerber file-set for PiCarrierEnd PCB download
 We recommend JLCPCB PCB manufacturer.
 Mechanical parts for above: PCB-2-M4 x4 and PCB-9-M4 x2 from Toby Electronics
 Also check out our SAMR34-based LoRa Node
 An improved packet-forwarder for RPi that fixes the bug outlined below.

I recently discovered a rather fundamental issue with the widely used legacy packet forwarder code which can cause downlink messages (from gateway to node) to go astray. When TTN instructs the gateway to transmit a downlink message it specifies a power level for the transmission. See the "powe": entries in downlink json packets in your gateway log.

Transmit power from a gateway is set up by instructing the concentrator and radio hardware to use different gain options at various stages of the tx pipeline. The packet forwarder's global_conf file contains a tx_lut section, this lists up to 16 different combinations of these gain set-ups to achieve various output power levels. To complicate matters further the antenna gain (also specified in global_conf) is subtracted from TTN's "powe": power level request to obtain the required rf power at the antenna. This resulting radiated power level must now be searched for in the tx_lut look-up-table in order to find the right gain-stage options to use.

But here's the snag: if an exact match is not found in the tx_lut the dumb packet forwader code simply errors out and the packet is not transmitted! It DOES NOT seek the nearest match or the next lowest - it just gives up. Since the lut can only hold 16 different tx power levels and TTN can apparently choose any power level it likes from -6dB to +27dB AND you can specify any antenna gain you like from 0dB to 6dB it's basically a matter of luck whether or not your downlink packet gets transmitted. Look for this type of error message in your gateway syslog:

 ttn-gateway[xx]: ERROR: Packet REJECTED, unsupported RF power for TX - 24
In the extreme this can cause complete failure of a node (using OTAA) to join the network. Once joined, a node running in CONFIRMED mode, may expend large amounts of energy and time re-transmitting packets that never get confirmed. Even in plain vanilla unconfirmed mode vital down-link data may never get through.

Many thanks to JoTo Systems who have kindly made their improved lagacy UDP packet-forwarder for Raspberry Pi available on github. It comprehensively addresses this issue, see resources above.