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 NodePostscript
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 - 24In 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.
Hoping soon to be able to recommend a modified packet server binary for RPi that functions a bit more rationally.