Since Iâve done that again and itâs really really simple ⌠Iâll add a quick note about that here ..
What is LoRAWan?
The Long Range Wide Area Network is a low power wireless network protocol. It uses a chirp
spread spectrum modulation system called âLoRAâ that has been patented by Semtech Corporation.
It can be used freely without charge - and there are networks like âThe Things Networkâ that
provide wide area backbone for LoRA applications. It allows data rates between 292 bps and
50 kbps (depending on requirements and signal quality - i.e. spread factor) - higher datarates
offer smaller range and lead to higher power consumption. Because LoRA operated in license free
spectrum (SRD band - 863MHz - 870MHz in Europe) there are limits that one is allowed to not
exceed. These limits include a maximum of at max. 30 seconds uplink per day - one should keep
the message size (sent by a single device) below 12 bytes per message, downlink on TTN is
limited to 10 messages per day per device and uplink should be spaced at a minimum of 5 minutes.
This leads to the required 1% duty cycle. Of course lower message rates are always better (there
is - for example - no need for a temperature or moisture sensor to send packets more often then
every half an hour).
The system has been optimized for embedded applications - LoRA devices normally require idle
current of about 100 nA to 10 mA which allows battery operated devices to operate up to
15 years continuously. Ranges that are reachable go up to 700 km (see this example communicating
with an helium baloon for example)
under ideal conditions - the high link budget of up to 154 dB allow reception even under bad
conditions like in basements or rows of houses. Because of the high link budget antenna quality
is not of a high priority in most cases.
The âWANâ part of LoRA is realized by providing a network of gateways which receive data packets of
all nodes in their vicinity (up to 700 km distance) and transmitting them to a distributed message
broker thatâs provided by an service provider - like for example the community driven âThe Things Networkâ.
Alternative providers of course do exist but to my knowledge none of them provides compareable
coverage to the TTN. Applications register devices that are bound to them with the message broker
system and receive all copies of messages that match their device identifiers via a messaging
protocol like MQTT. Getting a copy of each received message from each gateway allows easier
implementation of message routing for the TTN as well as implementation of features like multilateration
(i.e. locating the device by timing - which is especially possible because of larger spacing of
the gateways). Multilateration is additionally enhanced by gateways performing time tagging via
GPS based time synchronization (not common view though).
Device classes
Embedded devices are categorized into three different classes:
- Class A devices are always in sleep mode except when they want to transmit data. Server side applications are only capable of sheduling downlink packets after uplink action occured. Downlink packets are queued on the backbone network until reception of messages on any gateway attached to the network. The downlink packet is transmitted in the first or second receive (1s and 2s) window after the device transmitted itâs uplink packet - the network may use either the first or the second but not both downlink windows. Downlink packets are sent on the same gateways that have received the device packets.
- Class B devices synchronize their internal clocks to a periodically transmitted beacon. This beacon is sent by all gateways simultanously (this is done by utilizing GPS as a time synchronization mechanism). The beacon is normally transmitted every 128 seconds. Receive windows are sheduled relative to the beacons which enables downlink to these devices even when theyâre not actively transmitting data - on the other hand it requires the network to know which gateways should transmit which frames without âseeingâ the devices transmitting. Because of this class B devices are currently not supported by the community operated âthe things networkâ (but can be used on private networks)
- Class C devices extend the receive window to infinity - which means they are always capable of receiving whenever they are not transmitting. This requires - compared to class A and class B - substantial amounts of power and is normally not suited for embedded applications. Again the network has to be capable of determining which gateways should transmit the downlink message - again class C devices are currently not supported by the community operated âthe things networkâ (but can be used on private networks)
Frequency bands
LoRA operates in unlicensed ISM (Industrial, scientific and medical) radio bands. Depending on
the geographic reagion various frequency bands are used. Because of regulations for license free ISM
bands most channels have a maximum duty cycle of 1% or even 0.1%.
- US: 902-928 MHz (dedicated uplink and downlink bands, 8 subbands)
- Australia: 915-928 MHz (dedicated uplink and downlink, 8 subbands)
- China: 779-787 MHz and 470-510 MHz (96 uplink channels, 48 downlink channels; In some areas some frequencies are dedicated to China Electric Power which means they are not allowed to be used)
- Europe: 863-870 MHz (8 Subbands, specific dutycycle for each!)
Why to build a gateway
There are many cases why one would want to build his own gateway:
- Operate an own network (not a good idea in most cases - even if one only wants to use LoRA devices locally only itâs nice to send at least all unknown messages upstream to the TTN)
- Extend the TTN to other areas that are currently not covered
- Enhance coverage of the TTN in on ownâs are (more gateway lead to higher available datarates for devices, reduce the probability that an area is only covered by rouge devices, increase resolution for multilateration, etc.)
- TTN is community driven. One wants to use the communities network so itâs nice to extend the communities network.
Whats required
Gateways could in theory be built with a single radio - but in practice thats not enough
because LoRA allows operation on a multitude of subchannels and a normal radio is tuned
to a single frequency band. One required a so called concentrator to listen for device messages.
These concentrators are also capable of transmitting downlink messages as well as transmitting
a periodic beacon. Note that not all of these modes are possible license free (beacon
transmission requires a licensed gateway for example).
The concentrator board used in most home-built DIY gateways is the iMST ic880a. There exist two
version - an USB and an SPI version. This article focuses on the SPI version. In Europe one
would use the 868 MHz board which is readily available. One should also purchase a matching pigtail
and antenna if one doesnât have any special antennas that will be used (for example for outdoor
gateways, sectional antennas, etc.).
Control of the gateway can be done with any small embedded computer - the Raspberry Pi (in this
example the B+ model) is a perfect fit for that application. If possible one shouldnât use
wireless or bluetooth on these devices though to reduce radio interference. If itâs not possible
the gateway should designed in a way to isolate the contentrator board as well as provide some
shiedling between the LoRA antenna and for example 3G/LTE Antennas if possible.
Of course the gateway requies an power supply (normally for example a 230V to 5V PSU - if one
doesnât use 3G/LTE or WLAN/Bluetooth services and an RaspberryPi a typical 2.5 to 3A supply is
more than sufficient).
Note that the gateway contains RF electronics so shiedling of the case is mandatory. In the best
case use an aluminium or steel enclosure (also easy to get weatherproof) and ground the case.
In case of outdoor usage follow typical rules for providing lightning protection. If you donât
know how to do that - please ask somebody who does (it wonât be covered here because itâs a
little bit more complicated than connecting just a few wires). As long as your device stays inside
the protection radius of other lightning protection infrastructure one can just operate the gateway.
Where to get the parts
Note: If you use the supplied Amazon links the author is profiting from qualified sales
- Concentrator board: This is available from IMST
- Raspberry Pi 3 B+: Can be purchased from Amazon
- 32 GB SD Card (smaller is also sufficient): Also available from Amazon. If you want an SD card large
enough for all future experiments you can of course also take a cheap 64 GB or a cheap 128 GB one
- GPS module (any module with serial NMEA output and PPS pin is sufficient): Available via Amazon
- u.FL SMA pigtail: Available via Amazon
- 88 MHz antenna with SMA connector: Available via Amazon
- 5V power supply: Available via Amazon
- Plastic cable bend protection / feed through: Available via Amazon
- External GPS antenna with magnetic foot: Available via Amazon
Data usage?
Because the gateways connection to the backbone uses your internet connection one gets often ask how
much bandwidth a gateway would cost. Even if the gateway receives a packet every 10 seconds one
would only require about 5 MByte / day or approximately 100 MByte per month.
Building the gateway
Building the gateway is pretty easy. Just connect the gateways 5V and GND connection on pins 21 and
22 on the ic880a with raspberry pi pins 2 and 6 as well as the SPI pins and the reset pin according
to the following table:
iC880a pin | Description | RPi physical pin |
21 | Supply 5V | 2 |
22 | GND | 6 |
13 | Reset | 22 |
14 | SPI CLK | 23 |
15 | MISO | 21 |
16 | MOSI | 19 |
17 | NSS | 24 |

One can use jumper cables for that though a PCB is a better solution - they are available for some
amount of money. Note that the UFL to SMA connector on the lower left in the photograph is used for
the GPS antenna - it wonât be mentioned here. Also note that network and power are missing correct
cable sleeves (theyâve just been attached for testing) and most important grounding. Grounding should
always be attached to the case!
Put both boards in an enclosure, connect them to the 5V PSU. Never attach power when no antenna or dummy
load is attached to the ic880a - that may damage your concentrator board!
Software
First - if you want to go the easy route - install raspbian stretch. Configure networking the way you
like (for example enable ssh on the device by creating a âsshâ file on the boot partition of the sd card
and assign a static IP adress via DHCP on your network). Perform some initial upgrading of the apt-get
database and packages:
sudo apt-get update
sudo apt-get upgrade
Then configure ntp and ntpd:
sudo apt-get install ntpdate
sudo apt-get install ntp
Enable SPI support (one can use raspi-config for that or edit config.txt and load required overlays manually).
Then add an ttn user and add this user to the sudoers group:
sudo adduser ttn
sudo adduser ttn sudo
Then change execution to ttn
As user ttn clone the github repository of the ZĂźrich TTN community - they have written a set of shellscripts
that does all the bootstrapping of the Semtech LoRA libraries and the TTNs packetforwarder for you:
git clone -b spi https://www.github.com/ttn-zh/ic880a-gateway.git ~/ic880a-gateway
They also provide a remote configuration mechanism that works by posting a pull request to your gateways
configuration to their repository. One can also do manual configuration locally.
cd ~/ic880a-gateway
sudo ./install.sh spi
The installer shows the EUI (one needs that later on the TTNs webpage) and asks if it should use a
remote config file. If it should not (youâd know in that case) it asks for some basic attributes:
- hostname of the device. The installer sets the hostname of your raspberry pi. If you use DNS in your network,
assign this the same name as youâd assign the device in your DNS zone. If you use mDNS beware that the device
will announce its presence as [hostname].local via mDNS.
- Descriptive name: Is a value that is shown to you and other members of the TTN.
- Contact mail: Required in case your gateway makes problems or whenever there are some legal questions to you.
- Latitude and longitude can be provided manual. This is especial interesting if you are not supporting GPS (or
are only using GPS for time tagging). This should be as accurate as possible to help with multilateration. The
same goes for height.
The system will reboot and the device will go online immediately. Remember to copy the gateway EUI (if not done
earlier) and head over to https://console.thethingsnetwork.org and register your new gateway. It should appear
as online immediately.
Troubleshooting
If the gateway doesnât appear as online itâs most likely a network problem. Check if your gateway is reachable
locally. If it is check if itâs capable of transmitting and receiving UDP packets with destination port 1700.
This is the port used for communication with TTN. As long as you are using a stateful firewal or NAT that keeps
track of the first contact downlink doesnât require any special attention.
Running own backend and supplying messages to TTN simultaneously?
This is entirely possible. Just add a second server to your /opt/ttn-gateway/bin/local_conf.json
servers list.
Adding GPS
One can add an GPS device as source for location information (latitude, longitude and height) but more important as a
timing source to the gateway. This can be done with any GPS device that provides serial output (NMEA sentences
as well as a PPS pin (should be 5V TTL logic).
One can simply connect the serial input to their RaspberryPi (if using the GPIO header beware that the RaspberryPiâs
SoC is a 3.3V device so your UART should also deliver a 3.3V signal - if it doesnât one can take the simple route
and attach the GPS via a USB serial adapter). The PPS pin (5V TTL logic) should be attached to Pin 19 on the ic880a
concentrator board.
Afterwards configuration in /opt/ttn-gateway/bin/local_conf.json
can be adapted. If the device is
attached to /dev/ttyUSB0
one simply sets:
"gps" : true,
"fake_gps" : false,
"gps_tty_path" : "/dev/ttyUSB0"
These lines should be added to the "gateway_conf"
section.
Note that enabling GPS also automatically (at least for current poly_pkt_forwarder) enables the gateways beacon
feature that transmits a globally synchronized beacon pulse every 128 seconds. It uses the GPS PPS pulse to
synchronize this beacon transmition with all other gateways on the network. This pulse is used by class B devices
to allocate timeslots for downlink messages (see device classes above).
The frequency bands used by the LoRA-WAN Gateway are:
- 868.1-868.8 MHz
- 867.1-867.9 MHz
They are covered by the following set of regulations:
Publication in accordance with Article 1(3) of Commission Decision 2000/299/EC (Version December 2014); (Ref. Ares(2014)4077502 - 05/12/2014):
- 868.000-868.600, 1%, 25 mW erp
- 868.700-869.200, 0.1%, 25 mW erp
- 869.400-869.650, 10%, 500 mW erp
CEPT Rec. 70-03:
- 868.000-870.000, 0.1%, < 25 mW erp
- 865.000-868.000, 1% Duty cycle, < 10 mW erp (for FHSS&DSSS, Bandwidth 200 kHz-3MHz)
Remote administration via TINC
Like every other system it may be desireable to join a VPN mesh with your LoRA gateway (it may be located
anywhere via any untrusted network). First install tinc as usual:
apt-get update
apt-get install tinc
Configuration on linux is done in the /etc/tinc
directory. First create one for your network (you can choose an arbitraty
name, ânetnameâ will be used here as a placeholder)
mkdir -p /etc/tinc/netname
First one should create a basic configuration file for the current host. This is located in /etc/tinc/netname/tinc.conf:
Name = loragw001
Mode = switch
DecrementTTL = no
Interface = tun0
Forwarding = internal
ConnectTo = host1
ConnectTo = host2
ConnectTo = host3
The ConnectTo statements should of course match other hosts on your VPN mesh network. Itâs a good idea to generate tinc-up
and tinc-down
scripts in /etc/tinc/netname/tinc-up
and /etc/tinc/netname/tinc-down
:
#!/bin/sh
ifconfig $INTERFACE XXX.XXX.XXX.XXX netmask YYY.YYY.YYYY.YYY
#!/bin/sh
ifconfig $INTERFACE down
Do not forget to replace XXX.XXX.XXX.XXX and YYY.YYY.YYY.YYY with the IP address of your VPN endpoint and the
associated netmask
Then tinc can generate (as usual) host keys and configuration:
Now you can finalize your host file. You can prepend some settings in front of the public key:
Compression = 9
Port = 656
Subnet = XXX.XXX.XXX.XXX/32
If your gateway is reachable via a public address you should add that too to allow other VPN mesh nodes to connect
to the gateway
Address = ZZZ.ZZZ.ZZZ.ZZZ
Now you can deploy the other hostfiles and enable the service after adding the netname to /etc/tinc/nets.boot
systemctl enable tinc
systemctl enable tinc@netname
The service will now automatically startup on boot. Now one can manually start the service:
In case of errors one can debug the tinc client in foreground via
tincd -D -n netname -d3 --logfile=/dev/stdout
Management via TOR stealth hidden service
Of course TOR is not capable of providing any anonymization when used for a LoRA-WAN gateway (you have to
disclose the location and one can estimate the location based on received signals) - but usage of TOR for
remote access might be desireable to be capable to login into the gateway even when itâs only reachable via
a NATed network, a VPN mesh is not suiteable and one wants to provide mutual authentication between the
service and the user in both directions already on the network layer - thatâs what stealth hidden services
can be used for. Of course they also provide transport security and protection of metadatacollection of the
administrating party itself. If one wants to do user authentication only the traditional way (via SSH) and
doesnât mind of his service to be discoverable one can of course also use a traditional hidden service.
First install TOR:
Then edit your /etc/tor/torrc
to create your stealth hidden service:
HiddenServiceDir /var/lib/tor/loraremoteadmin/
HiddenServicePort 22 127.0.0.1:22
In case of a stealth hidden service add a list of authorized clients (the client names are arbitrary)
HiddenServiceAuthorizeClient stealth loraremoteadmin1,loraremoteadmin2
Then startup TOR:
In case your installation script has already started TOR you should restart it after adding the
hidden service lines
After the TOR client has successfully bootstrapped itself it has also initialized the HiddenService
descriptor files at /var/lib/tor/loraremoteadmin/
. You can monitor startup progress
in /var/log/tor/log
- this may take some time (and requires a synchronized clock - hopefully
you have successfully setup NTP or added an RTC to your gateway). You could find a list of all
client keys of authorized clients in /var/lib/tor/loraremoteadmin/client_keys
- everything
you need for remote administration is contained in /var/lib/tor/loraremoteadmin/hostname
.
Take the line corresponding to the client you want to setup and add the line (this is an onion
URI and an authentication cookie key followed by the comment that identifies the client) to the
clientâs torrc as an HidServAuth
line:
HidServAuth <onionurl> <cookiekey> # client: loraremoteadmin1
From now on the client can communicate with the stealth hidden service via the specified onion name.
No client that doesnât know the authentication cookie can use this onion URI (therefore they are
called stealth hidden services).
This article is tagged: