Hello YouTubers, here is the guy with the
Swiss accent. If you plan to start with LoRa and do not
want to spend lots of money you can start with an Arduino Uno and a Dragino shield for
around 20 dollars and connect it to the nearest gateway. In episode #117 I built such node. But, if no gateway is around your location? Then, you can build your own full blown public
gateway as I did in episode #115. This costs you around 300$. Which is too much for most of us. Today, we will build a gateway for much less
using an old raspberry and a LoRa hat. The hat is around 30$ and the whole gateway
is quite simple to build. And I will show you its limitations, and what
you have to do to avoid problems. In parallel, we will learn a little more about
the LoRa protocol. So, let’s get started with assembling the
hat and the Raspberry Pi. This is straight forward. I use a small Brass stand to make it more
stable. This hat also has a GPS module, but today,
we do not use it. After assembling the hat and the Pi, we have
to create an SD card with the needed software. We start with an SD card with an installed
Raspbian jessie release. You find a link in the description on how
to proceed. Now, we can start to setup the rest. You also find a link with the tutorial on
how to do that and I will follow this document for the next steps. The tutorial does not use a Pi hat, it just
uses the bare RFM95W module. This is also a possibility, if you want to
save another 20 dollars, which is the difference between the Pi hat and the bare module. According to the instructions, you first have
to clone the repository of the gateway software. Then, we have to enable SPI, if not already
done. Next, we have to install wiringpi. This software enables the possibility to control
the various GPIO pins of the Pi. In the next step, we have to adjust some constants
in the main.cpp file. Please check first the pin assignment. Then, you change the server address, the frequency
your gateway runs on, and the latitude and longitude of your gateway. I use here 868.1 MHz, but you can use also
.3 or .5, which are the three mandatory channels for TTN
Then, you make the executable file and start the gateway software. Be aware, that your gateway only works as
long as this program executes. If you press ctrl C, the program stops and
your Pi is no more a gateway. Right at the start of the gateway software,
you get the unique number of your device. This will be needed to connect to the TTN
network later. So, write it down and remove all colons. Now, you go to the page of TTN and create
an account (if not already done). Then, you enter the management console and
register a new gateway as “packet forwarder”. Key-in your gateway number from before and
enter the frequency plan. If you did not enter the position of your
gateway in the main.cpp file, you have now a chance to enter its position here. After registering the gateway, you should
see status “connected” and a small number of seconds in the field “last seen”. That’s all. Your gateway is now ready and can receive
and transfer messages! Now, apart from the price, what are the differences
of the expensive gateway on my roof compared to this one in my lab. There are three main differences:
1. My small gateway here, as its name says, has
only one channel 2. It can only deal with one spreading factor
at a time 3. Currently, it has no downlink possibility. However, this is not a hardware limitation
and maybe, once somebody will enhance the software to include this feature
So, let’s play around with it to discover, if these differences really matter. To do that, I have here my LoRa node from
episode #117. It sends every minute a message in the air. Let’s see now on TTN, what happens. The first message sent by the node arrives
and we see, that it was received by both gateways. Great! Our small gateway works! The signal on the roof was, of course, much
weaker. But still acceptable. Spreading factor was SF7. The next message, however, did only arrive
at the gateway on the roof. Why is that? I did not change anything and the signal should
still be very strong. So, This cheap gateway does not to be very
reliable. Let’s give it a second chance and wait for
the next message. And also here, it is not received by my new
gateway. So, I give it a last chance. Maybe it knew, that it was its last change. It transferred this message again. So, this small device is not very reliable. Should I throw it into the trash bin? Was this just a joke? If we have a close look at the transmission
frequencies, we see, that the node changed it with every message. This is a good behavior. If channel one would be disturbed, we would
get at least the next message on channel two. But we said before, our single channel gateway
was compiled for channel 0. So, it did not hear the signal on channel
1 or 2. So, we have at least an explanation of its
behavior. But how can we deal with that? Let’s assume, our node would always send
its messages on channel 0, then, our new gateway would receive all messages and we would have
resolved this issue. But what kind of other problems do we cause
by that? For a productive environment with hundreds
of nodes, the concept of frequency hopping is useful. But if you just want to test the technology
or use it around your house, then you only have a handful of sensors, and this frequency
hopping is not necessary. So, we just have to find a possibility to
switch it off in our node software. This is easily done by this command. We just disable all channels we do not want. For Europe, these are channels 1 to 8. Now, all messages are sent on channel 0, which
is 868.1 MHz. So, we have now a gateway for our own use. And even our neighbor can use it, if he constrains
his node to just our channel, too. No problem. Just to show you, that the node can only receive
one spreading factor at a time, I change my node to SF12. An, the message is not received, even on channel
0. So, we also have to make sure, that the nodes
and the gateway uses the same Spreading factor. So, summarized
• We built a simple a less expensive TTN gateway with a raspberry Pi and a LoRa hat
• The software is easy to be installed and adapted
• If we make sure, that our node only uses one channel, this setup is very usable for
our own purpose • The capacity of such a node is good for
at least 20 concurrent sensors or more, depending on the sending intervals. And the best: Because we are connected to
the ttn network, we can profit from other things. For example, we easily can connect our devices
to our node-red installation. A TTN node already exists and we can connect
our device straight to node-red. At the end, we see here as an example the
frequency of the transmission and the RSSI values of both gateways. With this, you can now attach your sensors
(or buttons) via LoRa and TTN to your home-automation system. I hope, this video was useful or at least
interesting for you. If true, then like. Bye
