LoRa wireless modulation is a very popular wireless communication technology for IoT development. Its long range and low power consumption features make it suitable for many IoT applications. After we tested out the LoRaWan network on a single channel gateway in our previous blog posts, this post will focus on setting up a private LoRaWAN network of MultiTech LoRa devices and collecting data on FRED ( our cloud-based Node-RED platform) via our STS-MQTT broker. We are also using our STS-InfluxDB database and the worldmap node to show the data we collect from our network. We decided to use the MultiTech Stater kit to create this demo as it is the most inexpensive LoRaWAN gateway kit that provides the full channel LoRaWAN connection for the US frequency plan. This kit also comes with a handheld survey tool that allows us to easily survey the LoRaWAN signal strength and performance which makes troubleshooting easier.
LoRaWAN™ is a Low Power Wide Area Network (LPWAN) specification intended for wireless battery operated Things in a regional, national or global network. LoRaWAN targets key requirements of the Internet of Things such as secure bi-directional communication, mobility and localization services. The LoRaWAN specification provides seamless interoperability among smart Things without the need for complex local installations and gives freedom to the user, developer, businesses enabling the rollout of Internet of Things.
LoRaWAN network architecture is typically laid out in a star-of-stars topology in which gateways are a transparent bridge relaying messages between end-devices and a central network server in the backend. Gateways are connected to the network server via standard IP connections while end-devices use single-hop wireless communication to one or many gateways. All end-point communication is generally bi-directional, but also supports multicast operations, enabling software upgrades over the air or other mass distribution messages to reduce the on-air communication time.
In this blog post, we will cover a few different sections:
- Background of the different LoRaWAN frequency plans
- Overall structure of our LoRaWAN network
- Setup on the Gateway
- Setup on FRED and STS-MQTT
- Connect the MultiTech gateway to FRED
- Go for a walk
About Sense Tecnic: Sense Tecnic Systems has been building IoT applications and services since 2010. We provide FRED, cloud-hosted Node-RED as a service to the community. We also offer a commercial version to our customers, as well as professional services. Learn more.
Background of the different LoRaWAN frequency plans
LoRaWAN protocol is specified by the LoRa Alliance. The latest LoRa specification(1.0.2), is available here. You can see the difference between the US plan and the EU plan in the following diagrams:
As you can see, the US frequency plan is very different from the EU frequency plan. There are 64+8+8 channels for the NA frequency plan, but a full-channel gateway only listens to 8 channels. There is a discussion about which subband to use for the NA gateway on the Thingsnetwork forum.
As mentioned, we chose the MultiTech LoRaWAN starter kit because it is the most inexpensive full channel LoRaWAN gateway kit that we can get for the US frequency plan. There are a lot of LoRaWAN full-channels gateway modules available in the market, but many of them are either only available for the European frequency plan or difficult to obtain.
The MultiTech LoRaWAN starter kit comes with these components:
- MultiTech LoRaWAn conduit with LoRaWAN mCard, this is a full channel gateway
- mDot-EVB, this is the handheld survey tool
- mDot development kit
- mDot micro development kit
- two LoRaWAN RF modules for the mDot development kits
- some other accessories like power cables, antenna, etc.
To be able to connect to the MultiTech conduit gateway, and to allow the MultiTech Conduit gateway to communicate with FRED, you will also need a router with an Ethernet port.
The MultiTech conduit gateway and the mDot kits come with out-of-box ready to use firmware. Here is the brief introduction to some software applications on the MultiTech conduit gateway:
AEP is a web management console that can be used to setup a local-LoRaWAN network easily. It also allows users to run a built-in Node-RED instance from the AEP service.
mLinux is a Linux distro that runs on the Multi-Tech conduit. It allows the user to setup more advanced configurations and gets it working on the Things Network.
The Multi-Tech Conduit gateway allows two LoRaWAN operation modes:
The local LoRa server is a local LoRaWAN network that users have full control over. Users can setup their own passphrase restricting devices joining the network. Users can then setup back-end process via Node-RED and any other programs in mLinux.
All nodes are required to connect to the gateway with pre-configured passphrases. This setup can filter out unwanted LoRa message packets.
The packet forwarder will simply forward all the received LoRaWAN packets to a specific back-end. It can be setup in AEP mode or running the thingsnetwork (TTN) poly packet forwarder program in mLinux (as recommended in the TTN document).
And of course, one of the most important pieces of software in this blog is FRED (the cloud-based Node-RED) and STS-MQTT(Sensetecnic MQTT broker). We also used STS-InfluxDB to store records in a timeseries database, but you can use any database that fits your needs.
If you don’t already have an account on FRED, set one up now. You will need to be a paid user (FRED Tall or Grande plan) in order to create MQTT the clients required in this blog post. You can visit https://fred.sensetecnic.com or https://mqtt.sensetecnic.com to create your STS account and check out the subscription options.
After registering, make sure to activate your account by email. You will not be able to log in until you validate your account.
Overall structure of our LoRaWAN network
There are many ways to design and implement an application using the LoRaWAN network to address different use cases and requirements. In this blog post, we focus on using the default factory configuration of the MultiTech local-LoRaWAN server setup and forward the messages to FRED via STS-MQTT.
We are using this setup because:
- The MultiTech LoRaWAN starter kit comes with nodes that are already tested and out-of-box ready for working with the MultiTech gateway. When switching to use other public LoRaWAN gateway platforms like the Thingsnetwork, there are some steps required to change the configuration on the nodes, gateway, and possibly third party nodes devices. At this point, we are focusing on the performance and behaviour of the LoRaWAN network. For the proof of concept of using FRED with the MultiTech LoRaWAN gateway, using the default LoraWAN network can save a lot of hassle for us at this stage.
- Using the default local LoRaWAN network allows us to have full control on all stacks. We can choose how to connect all the devices and how to decode and store our data packets.
As you can see from the diagram above, we use the local-LoRaWAN server configuration on the MultiTech conduit gateway to receive LoRa data packets from the MultiTech end nodes, such as the handheld survey tool (mDot EVB) and mDot develop kits. We use the built-in Node-RED running on the MultiTech conduit gateway to forward to the data packets to our STS-MQTT broker, and then collect the messages on our FRED server. In this demo, we will demonstrate using the handheld mDot-EVB sending GPS survey messages to the MultiTech conduit gateway, and show you how to decode the messages in FRED.
Setup on the Gateway
Connect to the gateway:
To connect to the MultiTech conduit gateway, MultiTech has provides detail instruction here.
Once you have connected to the gateway and logged into AEP, you can modify your conduit configuration as you need, such as using DHCP, time zones, login password etc.
Your AEP home page should look something like this:
Start local LoRaWAN server:
Then, you will need to confirm if the LoRa network is initiated and is configured correctly. You can click Setup -> LoRa in the side bar to access the LoRa settings. The config page of the LoRa server should look like this:
You might need to save the changes and reboot the gateway.
The MultiTech Conduit gateway has built-in Node-RED. To start the built-in Node-RED, simply enable Node-RED in the app management page, by clicking Apps in the side-bar:
And click the launch button to access Node-RED. You should be able to access your Node-RED instance by entering <your-gateway-ip>:1880 in your browser.
Setup on FRED and STS-MQTT
Now let’s jump to FRED and STS-MQTT. Since we are using STS-MQTT to relay the messages from the MultiTech conduit gateway to FRED, we need to create two MQTT clients on STS-MQTT. One of the clients is for the connections between the MultiTech conduit Node-RED and STS-MQTT, and the other client is for the connection between FRED and STS-MQTT. You can find more information about creating clients and connecting the MQTT clients with STS-MQTT from this tutorial.
Connect the MultiTech gateway to FRED
On the gateway:
Thanks to the built-in Node-RED, it is very simple to connect MultiTech Node-RED to FRED. First, let’s log into the Node-RED on the MultiTech conduit gateway.
To forward LoRa messages sent from end-nodes to FRED, the minimum requirement is to have to lora node connected to a MQTT out node.
and you will need to set the data type to bytes in the lora node.
Of course, you will need to setup the MQTT node. More details of connecting a remote Node-RED instance to STS-MQTT can be found from our previous tutorial.
This flow simply sends the raw LoRa packets in
msg.payload from the lora node to STS-MQTT. However, the messages sent from the lora node also contain other useful data . The complete msg object sent from the lora node contains:
- ack status
- adr information
- app EUI
- Data rate
- Device EUI
- LoRa SNR in dB
- RSSI in dBm
- packet size
Remember that LoRaWAN is a low data rate transmission method. Care should be taken as to what information you want to send over the LoRa RF.
By default, the MQTT node only sends
msg.payload, so the Node-RED flow above only sends the raw packet from the lora node. In our demo, we are also interested in receiving the other information from the packet, so, we need a function node to include the complete msg object inside
The code inside the function node contains the following:
By using STS-MQTT, it is now very easy to receive the message from STS-MQTT. Again, you can follow this tutorial to find out how to connect to STS-MQTT. You will need a flow like this to parse the data packet from STS-MQTT
You see there is one function node right after the MQTT node. Note that our STS-MQTT node parses the
msg.payload data from string format to a JSON object. If you are using the Node-RED MQTT node, you will need another json node to parse the data into a JSON object.
In the above flow, we have a function node named “parse survey GPS msg”. In the following demo, we will only use the Survey GPS mode on mDot-EVB. The data format of the msg object is indicated from the MultiTech document. You should beware of the correct data format as it depends on the data sources and operation mode in each end node.
Here is how we decoded the msg from our mDot-EVB in “Survey GPS” mode:
msg.pData should look something like:
Prepare to test the coverage and signal:
FRED is a powerful tool that we can integrate different devices and services to implement ideas quickly. We are not satisfied with only decoding the “hello world!” data packets from mDot-EVB, we also want to build up something tangible to see the performance of our private LoRaWAN network on MultiTech gateway.
We can use worldmap node to show the current location of the mDot-EVB survey tool with its signal strength, data rate etc. We can also use influxDB node with STS-InfluxDB to record history data. In my test run, I also used the Telegram node to forward the incoming messages to my smartphone, so I can see the incoming messages on my smartphone instantly without carrying a laptop around. You can find this advanced work flow from our sample code.
Go for a walk:
Now we are ready to map out the signal strength. To use “survey GPS” mode on mDot-EVB, survey tool needs to be outdoors where the GPS module can receive GPS signals.
Once we turn on mDot-EVB, we can scroll to “survey GPS” in the main menu, and click SW1 to select this mode.
mDot-EVB will ask you to join the pre-configured network, which should be the default network configuration on the MultiTech conduit. Make sure the network ID, passphrase and frequency sub-band (FSB) match the gateway.
As soon as you power on the device, mDot-EVB starts looking for a GPS signal. If a GPS fix is obtained, you should see your GPS data on screen after you had joined the LoRaWAN network, LED2 should also be always blue. If mDot-EVB is not able to obtain a GPS fix, LED2 will keep blinking, and LED2 will be blinking.
Once the mDot-EVB has successfully joined the local LoRaWAN network, it should start automatically sending data at the default time intervals. The default send interval is 5 seconds.
In good condition, the mDot-EVB will show “send success!” on the screen.
You can change the send interval by toggling the parameters to Interval by clicking SW2, and then toggle to the desired value by clicking SW1.
You should see messages arrive from the MQTT in node on FRED if the messages are sent successfully from the mDot-EVB. It should look something similar to this:
In our demo, we wanted to study the performance of LoRaWAN network within the urban area of Vancouver, Canada. We used STS-InfluxDB to gather all incoming data in a timeseries database, and then use the worldmap node to mark all locations where messages were delivered successfully. Each record in the database includes latitude, longitude, signal strength and data rate. We walked for around 1km distance to verify our setup, and it seems the signal is still going strong!
In this demo, we had set up out private LoRaWAN network using the MultiTech gateway, and forward the messages sent from a handheld survey device, mDot-EVB, to FRED via STS-MQTT. We were able to use the STS-InfluxDB and the worldmap node to illustrate the geolocations of each messages sent, and study the signal strength and data rate at each different location. With this setup, we have a better idea to analyze to performance of LoRaWAN in a crowded urban area and study the reliability of LoRaWAN. This setup can also be easily developed for production use cases where quick integration of large sets of data and devices are critical.