LoRa Gateway project

A DIY high-reliability RPi + RAK2247 TTN LoRaWAN Gateway

This DIY RAK2247 + RaspberryPi based LoRaWAN gateway is designed for low cost and high reliability using a Power-Over-Ethernet network connection, integrated super-cap uninterruptable power supply and hardware watchdog. 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 as, if not better than, any of the much more expensive commercial LoRa gateway products out there. It's packaged for indor use - ideally with an outdoor antenna.

 View documentation
 Image gallery
 RAK Wireless: Store | Downloads | Forum
 Beyond Logic's RAK Concentrator Pi HAT
 PoEUPSPi uninterruptable PoE Raspberry-Pi power-supply
 PoEUPSPi schematic Full RevB schematic 
 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.