LoRa and LoRaWAN are remarkable technologies,
they have a long range and low power consumption and therefore are ideal for our sensor projects. Today I will show you how to build a LoRaWAN
sensor and connect it to the open The Things Network in the new version 3. I will also show how you can migrate your
infrastructure if you are already a user of the V2 network, where the deadline is this
December. In the end, you even will get a surprise. A lot of exciting stuff! Gr ezi YouTubers. Here is the guy with the Swiss accent. With a new episode and fresh ideas around
sensors and microcontrollers. Remember: If you subscribe, you will always
sit in the first row. As you can imagine: The video will be divided
into three sections: - A short recap on how LoRaWAN works
- Sensors, where we focus on home-made devices and have a look at the newest libraries and
better alternatives to the ESP32 - Gateways, where we have a look at the setup
as well as the migration of V2 gateways - And the surprise or, as Steve Jobs used
to say: The last thing Of course, you can skip part one if you are
familiar with the technology, as well as part 3 if you do not own a gateway. The video has chapters. LoRa is a low-power, long-range wireless protocol. It is very different from Wi-Fi which has
a short range and a high throughput but needs a lot of power. It is also different from Bluetooth, which
is also short-range, offers less capacity, and consumes very low power. It is also different from the 4- and 5G networks,
which offer similar ranges and data rates but are not as low power, and currently, these
modules are pretty expensive. The LoRa protocol, as said, offers low power
and long-range and has a very low data rate. This is why it is ideal for sensor networks. In addition, the modules are cheap and easy
to use, and their usage usually is free of charge if you use TTN, for example. LoraWAN is a network protocol based on LoRa
and is internationally standardized, making it possible to connect the same sensor to
different networks. But, of course, only one network at a time. The LoRaWAN network consists of two components:
- Gateways like this one are deployed either by nerds like me or by companies. Companies tend to build private networks or
charge for their usage - Applications in the cloud that ensure that
the readings of your sensor and only your sensor are routed to you. These networks are called TTN or Helium, for
example. Because all messages are encrypted, these
networks cannot read what you transmit. If you are interested in more details, you
find a whole LoRa playlist on this channel. If you watch the official TTN videos, you
will hear a lot about packet brokers and roaming. However, I will not cover these topics because
they are not essential for us and only complicate things. Let s start with the assumption that we bought
or built a sensor and want to connect it to the network. This is how it is done:
We have to register our new node in the TTN backend. If you do not have an account, you have to
create one. It is free of charge. Then you go to the console, chose your region,
and applications. Then you add an application and give it a
unique name. You can have many applications and can add
many nodes to each application if you want. My sensor is a mailbox notifier, as shown
in video #391. I add my username to get a unique ID. Next, we have to add our notifier as an end
device. If you purchased a sensor, you should find
its make here and enter its registration data. Because we built our own sensor, we choose
manually and select the correct LoRaWAN version. For the MCCI library I used, it is 1.0.3,
for example. Then you choose the frequency plan according
to your region. We do not need to go into the advanced settings
and continue pressing all three generate buttons because we must enter these numbers in our
sketch. The APPEUI can be filled with zeros because
it does not matter. This button can change the format of the key,
and with this button, it can be copied to the clipboard. Please note that some libraries request the
keys in the LSB format and others in MSB. If your node does not work, this is the most
common error. If you want, you can name your end device. Done. Your sensor should already work, and you should
see its first life data. Because the new version 3 of TTN focuses on
the OTAA join method, I will only cover this one. It still supports ABP. However, the old V2 ABP nodes do no more work
in V3, and you have to change their sketch. An additional advantage of the OTAA nodes
is that they also works with other networks like Helium which does not support ABP. OTAA adds more communication between the gateway
and the node. The gateway, for example, communicates which
channels it listens to and if the node should reduce its Spreading Factor or lower its power
to reduce power consumption. Cool feature! But unfortunately not implemented everywhere
yet. These commands are called MAC commands, BTW. The first communication of a node with the
network is called joining, and you should see it in your life data. After the joining effort, your node knows
when it could not reach a gateway and can warn you with a red LED, for example. If you want to migrate an old OTAA node, you
can store its current keys to a notepad and delete it in the old V2 console. Next, you add it as a new node in V3, as shown
before. Done. It should join as soon as it is power cycled. If not, maybe you have to RTFM on how to delete
the old join data. If you want to avoid frustrations, there are
a few things you have to know before you start building a new sensor or writing a new sketch
for your old one. They are my learnings of building my mailbox
notifier. First, I started with an ESP32 LoRa board
and lost a lot of time to get it working. Only to learn that my sketch will not work
outside Europe. Why is that? Because I have a few lying around, I wanted
to use one of my trusted TTGO LoRa boards and the new MCCI library, the natural successor
of LMIC. We all know that the ESP32 has a nasty behavior:
It reboots after deep sleep. Which is ok for most scenarios. But not for the MCCI library and OTAA. These are not made for such behavior. Fortunately, I found better solutions: Other
MCU architectures like the old Atmel 328P used in our Arduinos have a different, more
natural behavior for deep-sleep: Their behavior is much like a delay() statement and, after
deep-sleep, they start exactly where they were before the nap. With such behavior, we can use the MCCI library
without problems. It does not care if we sleep as long as we
do not lose data or program steps. Unfortunately, the old 328 chip does not have
enough memory for projects using the MCCI library. So, if your old node uses a 328P chip, you
still have to use the LMIC library. Which should also work in V3 if you do not
use special cases. You can imagine how happy I was when I got,
out of the blue, two of those boards in my mail. Matias, another guy with a Swiss accent, saw
my mailbox notifier video and had mercy with me. His boards use the newer 1284P Atmel chip,
which has enough resources to run the MCCI library. And he added one of those TPL5010 external
clock chips to wake the MCU regularly without consuming a lot of energy. Excellent. He sells these boards on Tindy, BTW. With this board and his example files, we
were able to create a modern LoRaWAN V3 node with the following features:
- It has two input lines that trigger different messages. One message if the mail arrived and, as proposed
by many viewers, a second one when the mailbox is emptied. - And it creates a regular I am alive message
transmitting the battery voltage, which enables the building of a node-red watchdog as shown
in video #385. It warns me if no I am alive message arrives
for sometimes that something went wrong with the sensor, the gateway, or even the network
Let s have a look at the sketch. The first we see are the keys we created in
the TTN console. We can copy-paste the saved values and delete
this line, or you can create a file called TTN_Credentials.h with the very same definitions. Next, you see a small trick you can also use
for other sketches. These lines make that your Serial.print statements
are only executed if you define DEBUG. Otherwise, your sketch does not print anything
and saves valuable time and energy during its whole life. Let s now jump to setup(). Here we attach the three pins to interrupt
routines. Like that the MCU wakes up if one of the switches
is closed or if the TPL5010 generates a signal. Then LoRaWAN is initialized, and a first message
is sent. Because this place is only reached if our
node was reset and lost all data, it will join the network here. In loop() we have to execute os_runloop_once()
to make sure LoRaWAN works. As we saw before, a LoRaWAN gateway can also
transmit data to the node. To do so, the receiver of our node has to
listen to the gateway. But not all the time because this would consume
way too much energy. The LoRaWAN standard says that the gateway
transmits exactly 5 seconds after it receives the message. Matias wanted to save energy and let the MPU
take a nap during these 5 seconds. Of course, only if nothing else has to be
done. If everything is done, we end up in this part
of the sketch where the MCU starts to sleep forever like Snow White. Only to be waked up by a price in the form
of an interrupt. Then the duty cycle calculations are adjusted,
and a new message is sent. The duty cycle, BTW, prevents you from transmitting
too many messages in a short time. This is because the laws in Europe, for example,
only allow a node to transmit 1% of the time. Anyway, it is in your interest to transmit
as few messages as possible to extend battery life. The message only contains three bytes: the
first byte contains a 1 for the watchdog message, a 2 for the lid switch, and a 3 for the door
switch. The following two bytes contain the voltage
as an integer value. You see, we do not need a lot of data if we
pay attention. Let s check our Mailbox Notifier. Because of many discussions about Lithium
batteries in winter, I decided to use two AA batteries for this node. Also, because the deep-sleep current of this
board is only a few microamperes. As soon as I insert the second battery, it
transmits a join request which is accepted. If I press one button, we get the message
with a 02 in the first place and two other numbers. If I press the button again, the third number
usually changes a little because the voltage reading is always slightly different. I want these numbers in a friendlier format. So I use the payload formatter provided in
the sketch and go to uplink and payload formatter of my application. Here I chose Javascript and replace this template
with the text from the sketch. If I press the button again, we see the decoded
payload: An event and the voltage in a human-readable format. Cool. We also see the Spreading Factor and the signal
strength called RSSI. SF7 creates a very short signal which has
a lower range. SF12, for example, creates a much longer signal
which has the biggest range. But it takes much longer to transmit. SF8-SF11 are in-between. An RSSI above -80 is very strong. A connection is still possible at around -115
at SF7. What is missing? Of course, we want to have the sensor readings
in our application. I use MQTT to connect to TTN and want to read
the values from my Raspberry Pi. This is enabled in the integrations tab. If we choose MQTT, we see the address of the
TTN MQTT broker with its standard ports. We also see a user name. The only thing left is to create a new API
key. You can copy it with this button. Please copy the username and the password
to a safe place because you will never see the password again on TTN. With these three things, we can go to Node-red,
for example, and create an MQTT IN node with the address and credentials from before. The topic contains the application ID with
an @ttn added. Now we have all messages delivered to node-red,
and we can do whatever we want. I leave you a link to this flow if you want
to look at how I solved the problems. My flow rings a bell when the postperson arrives
and stores the time in a database. We have now created a LoRaWAN node, connected
it to the new TTN network, and transferred data to node-red. A typical end-to-end process. And you saw: No rocket science was needed! But what about the gateways? If a public gateway does not cover your sensors,
you have to have your own. There are two possibilities for that: You
buy a ready-made device, or you build your own, usually by combining a Raspberry Pi with
a gateway hat. The gateway is very different from a node. It is connected to the internet and runs all
the time. Therefore, it has to be powered by mains or
by decent solar power. A typical gateway can receive on eight channels
or frequencies in parallel and adapts to all Spreading Factors. This enables your node to transmit on any
channel and with any spreading factor, and the gateway can simultaneously serve up to
8 nodes transferring messages. Because each node must not transmit more than
1% of the time, one gateway theoretically can support a few hundred nodes. You can buy a lot of gateways. Indoor gateways like this one from TTN are
cheaper than waterproof outdoor gateways like this one from Mikrotik. Just pay attention that you grab one with
the frequencies for your region! I no more recommend to use single or dual
channel gateways. The price difference to an indoor gateway
is no more big and you have to restrict the used frequencies on all your nodes to the
only one your gateway can receive. Let s again start with a ready-made gateway
and use a RAK 7248 as an example. If you follow the description, you have to
add some network configurations like ethernet addresses, select TTN as your preferred network,
and select your region to enable your gateway to use the proper frequency plan and the internet
address of the TTN backbone. Please copy the gateway EUI to notepad if
presented. You will need it later. That is all for the gateway, which immediately
starts to listen and tries to connect to TTN. Next, we have, as with the node, to register
our gateway in the console. This is also easy if you remember the gateway
EUI. Most V2 gatewaysare still supported. Just change the address of the backend. If you have an ic880a gateway and used the
ttn zurich method to build it, you only have to change the gateway address to this one,
create a pull request and wait for Gonzalo to accept your change. Then you can reboot your gateway and it works
with TTN V3. Now you should see the gateway connecting
to TTN and receiving messages from your or other people's nodes. The good thing: The migration of your nodes
and the migration of your gateway are independent. The sequence seems not important because V2
gateways also route data of V3 nodes. Just make sure you finish both before December
1st. If you want to build a DIY gateway, you can
use this hat from RAK. The procedure is pretty much the same as with
a ready-made router. You only have to provide your SD card and
a decent case like mine. I strongly suggest not using a Raspberry Pi4
because it heats too much and is unnecessary for performance or memory size. I monitored the temperature of my Pi3 MCU
over the last two years, and it hardly hit 70 degrees Celsius, which is acceptable because
it is only for a short period of the day and only during summer. You see: Creating or migrating a LoRaWAN device
in the TTN network is not complicated. Just remember the few things:
- Always register your node in the TTN V3 console and reset it afterward. If it does not join, you might have screwed
up with the MSB/LSB format of the keys or, if you migrated your node, it is probably
one of the elephant variety which never forget. Then you have to read the manual and reset
the join information - Do not try to migrate ABP nodes. They will not work anymore in the new network
- Do not use ESP chips for sensor nodes if you need to sleep them. Instead, use Arduinos, STM32, or Cubecells. All can be programmed with the Arduino IDE. You also find an example file for the Cube
Cell on my Github - If you want to use a 328P chip, you cannot
use the new MCCI library. You have to stick with the old LMIC lib. Simple things should also work in the V3 network. - V3 nodes also work with old gateways. Very good. Only if your neighbor with the gateway does
not watch this video and forgets to migrate his gateway, your nodes will stop working
in December. The same is true if you are the gateway owner,
of course. But then you know who to blame, at least
- Gateways are easy to connect to the network by configuring the backend address as well
as the region on the gateway itself and registering the gateway in the V3 console
- Migrating a gateway only needs an update of the backend address and a new registration
on TTN. No need to delete the V2 entry
- The sequence of the migration is not essential. Keep it with the Nike slogan: Just do it! One last thing: Over the last few months,
the Helium LoRaWAN network was extended and, particularly in the US, has a much broader
coverage than TTN. This is why I will do a similar video for
Helium. Because I already covered the cryptocurrency
part in another video, I will not repeat myself. But I will show you how you can connect a
non-mining gateway also to the helium network. Without paying for the data transfer. Cool! As always, you find all the relevant links
in the description. I hope this video was useful or at least interesting
for you. If true, please consider supporting the channel
to secure its future existence. Thank you! Bye
