You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Single channel LoRa UDP packet forwarder ideal for development or
testing purposes. Receives and transmits bidirectionally.
This project is ideal for DIY of one of the cheapest LoRa "gateways"
consisting of a single-board computer and a $4 LoRa module.
The goal of the project is to provide simple LoRa forwarder for:
Linux - Orange Pi, Raspberry Pi, etc.
Supports the Semtech UDP protocol v2 - uplink, downlink, and stats:
The Things Network - tested V2, V3
ChirpStack - tested V3, V4
Supported LoRaWAN device classes:
class A , LoRa modulation - tested
SPI communication based on wiringPi and modified RadioLib for Linux (Orange Pi or Raspberry PI) with LoRa chips:
SX126x series
LLCC68
SX127x series
RFM9x series
Basic JSON configuration file
How to Use
Hardware Setup
Along with network connection on your single-board computer (WiFi,
Ethernet...) the following pins on your device have to be allocated:
SPI module pins
MISO
MOSI
CLK
3 or 4 GPIO pins for connecting to the LoRa module:
CS (a.k.a NSS)
DIO 0
DIO 1
REST - optional
power pins - 2 pins for VCC (usually 3.3V) and 1 for GND
Please refer to command gpio readall (also check the next sections) to
obtain more information for your particular board. Look into the WiringPi
numbers as well, because the configuration file expects that numbering
scheme.
The following steps have been tested on Armbian v5.90. However it is recommended
to use its latest version.
Compile wiringPi for Orange PI //for the ZERO model use WiringOP-Zero library instead// with ./build command
Optionally specify the PLATFORM variable to change the board config (for e.g. for Orange Pi PC: PLATFORM=orangepipc ./build) or leave the build script to determine it automatically.
On Armbian and Orange PI you might need to add the spi-spidev overlay. Additionally in /boot/armbianEnv.txt you'll need to add parameter param_spidev_spi_bus=1 or param_spidev_spi_bus=0 depending on the board model. For e.g.:
Orange PI Zero - param_spidev_spi_bus=1 if we consider the the following active overlays: i2c0 i2c1 pps-gpio pwm spi-add-cs1 spi-spidev uart1 usbhost2 usbhost3
Warning : On some newer Linux Kernels (for e.g. > 5.10.43-sunxi) depending on the board model the SPI may not work at all. Indication of that may be the missing /dev/spidev* directory despite the loaded spidev driver. A temporary workaround for this case is switching to an older kernel.
Warning 2 : Variations in the loaded overlays even for the same board will produce different results for the available GPIO pins, SPI devices, etc! The gpio readall command will also show a slightly different table, having some rows hidden or shown.
Execute gpio readall to see the board pinout scheme table
Compile this project with make
Raspberry PI and others: compile & install
WiringPi is pre-installed on Raspbian - no actions needed
Compile this project with make
Running LoRa UDP Packet Forwarder
Create config.json by copying config.json.template:
Edit the spi_port and spi_channel values accordingly.
Consult the MISO / MOSI and in particular ".number" postfixes of the gpio readall command
Additionally observe the output of sudo ls /dev/spi* where results like for e.g. "/dev/spidev1.0" correspond to /dev/spidev<spiChannelNumber>.<spiPortNumer>
Note that the ability to specify custom spi_port is a non-standard feature, which may not work on environments with the original wiringPi for RaspberryPi. An alternative solution is creating symlinks to /dev/spidev<x>.<x>.
Edit the ic_model field to specify the LoRa chip model. Use one of the following supported values below:
For SX126x series: SX1261, SX1262, or SX1268
For LLCC68: LLCC68
For SX127x series: SX1272, SX1273, SX1276, SX1277, SX1278, or SX1279
For RFM9x series: RFM95, RFM96, RFM97, or RFM98
Edit the pinout (execute gpio readall to check wiringPi pin numbers that need to be specified). Please
note that pin_rest is optional. If it isn't used you should set it to -1 and leave the transceiver's pin floating or connected to VCC;
Edit the remaining parameters accordingly.
To execute the application:
./LoRaPktFwrd
To execute the application and also specify network interface used for ID generation:
./LoRaPktFwrd
The default one is eth0
Example: ./LoRaPktFwrd wlan0
To get the supported CLI options:
./LoRaPktFwrd -h
Running LoRa UDP Packet Forwarder as a System Service
This project can be installed as a Systemd service (refer to file LoRaPktFwrd.service) which optionally may start automatically after the system boots.
As a prerequisite make sure the project is compiled (via the make command) and it is able to execute correctly with your own config.json file.
To install the LoRaPktFwrd service you can execute: sudo make install
To uninstall the service use: sudo make uninstall
To allow the service to run automatically after the system boots: sudo systemctl enable LoRaPktFwrd.service
To disallow the service to run automatically after the system boots: sudo systemctl disable LoRaPktFwrd.service
To manually start / restart/ stop / check the status of the service:
sudo service LoRaPktFwrd start sudo service LoRaPktFwrd restart sudo service LoRaPktFwrd stop sudo service LoRaPktFwrd status
To inspect the latest logs of the service: sudo journalctl -n 100 -f -u LoRaPktFwrd.service
Dependencies
LoRa UDP Packet Forwarder relies on the following programs and libraries:
g++ supporting C++14 standard
make
WiringPi
How To Test
Provided is a simple LoRa trasmitter example Arduino project called
"Transmit" in the current directory. Hook your ESP8266/Arduino/whatever
board via SPI to SX1278 module, compile it, and it will start
transmitting data. Using the default configuration inside
"config.json.template" in terms of RF specs, the forwarder app should
immediately pick data from the transmitter.
A tiny temperature monitor program that can run in the background and modify GPIO pins in response.
Limitations
Achieving a perfect downlink transmission timings appears to be difficult with the combination of
an ordinary single-board computer equipped with a plain LoRa transceiver. The reason for that comes
down to the imprecise hardware clock of the computer combined with the non-real time nature of Linux.
To compensate for it this project aims running with a very high (nearly real time) priority,
and increased CPU usage (roughly 20%) to partially make up for the irregular OS delays.
This project is influenced and contains code from: