How to Build or Migrate Sensors and Gateways on TTN LoRaWAN V3
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
2021-10-10 20:35
