You may be familiar with LoRa, not that girl, but the LOng RAnge communication solution that is used for long-distance, low-power point-to-point communications. It was invented by the Grenoble-based company Cycleo in 2009 and later sold to the semiconductor giant Semtech.

You might have heard more about it in its usage with an infrastructured network: LoRaWan, which allows public or private networks to connect thousands of sensors. In this blog post, I am going to talk about another implementation of LoRa, this time in a mesh architecture named Meshtastic. Multiple mesh, LoRa based solution are rising, this is one of them.

What is i a meshed network

The principle of a mesh architecture is to somewhat merge the roles of nodes and infrastructure in a network, giving it a mission of information propagation/routing. This approach helps reduce infrastructure costs and addresses issues related to dynamic terrain: the conditions of the terrain change, the network self-adapts, and there is no need to move infrastructure. Imagine, for example, soldiers on the front line, which shifts faster than the time needed to deploy infrastructure. Each soldier can be a communication node, and the network moves with the troops. The goal in the end is to transmit information back to more stable points in the rear, which can support a collection infrastructure.

LoRa, allowing ranges of several tens of kilometers with very low power consumption, can be imagined in military, agricultural, and ecological use cases, such as wildlife monitoring, for example.

Meshtastic is an implementation of a LoRa Mesh network, created to operate without any infrastructure. A large global amateur radio community supports this project, and 40 000 nodes have already been sold ; About 20 000 have been activated yet.

How does it works ?

The goal of Meshtastic is to enable the exchange of messages between nodes over very long distances, rather than data collection. The operating principle is quite simple:

Each node listens, and if it gets a message, it will propagate it. To avoid loops, a message will not be propagated more than once by a node. Each message includes a maximum number of hops.

While this type of algorithm significantly limits the network’s capacity, it is simple enough to be implemented on very low-cost boards.

Communications occur over encrypted channels. Therefore, the communications are visible to anyone who possesses the encryption key but remain secret to others.

There are certain shortcomings in this protocol: there is no signature to certify the sender, and no system allows for the secure exchange of keys to create a secure channel. As a result, centralized infrastructure is necessary to exchange keys.

To understand why these shortcomings exist, we need to go back to the origins of this solution: a communication system for emergency situations, designed for an amateur radio community that is not allowed (at least in the USA) to perform encrypted communications. However, this limitation becomes a challenge for applications beyond the hobbyist realm.

The strength of this solution lies in the use of standard and inexpensive hardware. In a future article, I will provide much more detail on the Meshtastic protocol and its limitations, but let’s start by looking at how to deploy it on a TTGO -TBEAM

Solution components

In general, the software solution around Meshtastic is quite impressive. There has been a lot of work done to integrate numerous devices, various configuration solutions, and a wide range of services through modules. This tends to create some complexity when getting started but offers a rather rich solution for many different uses.

A Meshtastic node is composed of a board providing LoRaWan and Bluetooth connectivity, along with a mobile application that communicates with the node using Bluetooth. We will later see also how to use WiFi for fixed nodes.

There are ready-to-use kits available from RAK Wireless, as well as a good number of very affordable compatible boards. LLIGO TTGO (T-Beam, LoRa, T-Echo), Heltec V3, RAK11200…)

To conduct a test on Meshtastic when you’re alone in your neighborhood, you need to have at least two devices. However, with only two nodes, the network will be a simple point-to-point connection without any relay. So, it quickly becomes more interesting to use three nodes. In my case, I will use one node as a router (this is one of the node modes) and deploy it with a rooftop antenna. For this, I will use a TTGO LoRa and two other TTGO devices (T-BEAM and LoRa) as mobile nodes that I will be able to use while on the move.

Let’s flash it !

Installing the Meshtastic software on an ESP32 target, such as the T-Beam, is particularly simple. You just need to follow the online instructions, where everything runs in the browser, so no installation is required.

Then Flash it:

Once the device has been flashed, you will see in the log the firmware trace. During my first attempt to flash the device, I had some issues conducting the device to reboot all the time. I can’t exactly tell you how I fix that as I’ve done different things, the list has been:

Change the USB Cable, Click on Full Erase and Install switch on the flash screen above.

I’m running version 2.4.2.5beta (stable) for this test.

Once the device is flashed, you need to pair and setup with the Meshtastic mobile application.

The application will automatically displays the node around. You need to select and Pair your node to setup it.

Once you selected the node displayed, a popup will be displayed to ask you a pairing password. The default one is 123456

When you update firmware after pairing, you will need to remove the device on you iPhone known device list before being able to pair again.

Once you paired, you need to setup your region. For Europe, use EU868.

You can let other setting as a default, the Long/Fast setup is a SF11 communication at 1Kbps. And sounds good to get started but if you are in a dense area, I think going Medium/Fast sounds better.

Once saved, the device reboot and is ready.

By default, the node is communicating on the primary channel with a standard encryption key reporting the position of the device and some other heartbeat information. This information is by default broadcasted on every 15 minutes on idle and every 30 seconds on movement.

If you want to see your node in the Meshtastic Map you need to setup the node for bridging to MQTT with the smartphone. In this mode the device will send and relay message on MQTT over the smartphone connection to fill the mapper database.

In the node settings / MQTT menu, you can use the following configuration:

• MQTT client proxy : ON
• Encryption Enabled: ON
• JSON Enabled : OFF
• MAP Report: ON
• Address: mqtt.meshmap.app
• User Name: uplink
• Password: uplink
• TLS Enable: OFF

Now we will have a mapping device visible on the map in the next hour.

Let’s configure a second device as a router

Now I want to have one device on a fixed location with a roof top antenna working as a standalone and reporting the information to MQTT. For this one, I’m using a TTGO-LoRA (v1.6) it does not have a GPS but is a small unit with a screen.

The flash process is the same, selecting the right board. I lost a bit of time on the app as my first node was connected and in this case the application does not detect the nodes around. I had to switch it OFF and the new Node appeared on my smartphone. Configuration stays the same. On this version the Bluetooth pin code is displayed on the screen panel.

On this device a user button allows to switch between displayed page… but as the button does not exists, you need to shortcut IO12 and GND or solder a button between the two.

Once the first node send a heart beat message, the second node gets it and show this node details.

To configure the position of a node that does not have GPS and will be stationary, you will have to be a bit clever because it seems that the system is not very fond of manual configurations. The node will need to be configured via BLE with the following settings:

• Setting > Position: Device GPS Disable
• Setting > Position: Fixed Position ON

With this, the position of the smartphone will be sent to the node, which will store it.

I had previously tried to configure the position using the command line without success, but I’m still leaving my command line here for reference.

# meshtastic --port /dev/cu.usbserial-018C0C8D --setlat 4X.XX --setlon X.XXX --setalt 3XX

Now, I want to configure this node on my Local network as it’s going to be fixed and I want to be able to configure it from the LAN (with the web configuration page). For this, go in Settings >> Device Configuration >> Network. Then enable it and setup the WLAN configuration. The device will reboot, the panel will display the IP address on one of the pages (so you need a switch button to navigate).

Once done you can have a look at some setting:

This node will be autonomous with a high-performance antenna to serve as a relay in the area, so I was thinking of assigning it the role of Router. However, in practice, this mode seems more like a passive mode for a mobile node that prioritizes routing. Therefore, the Client mode seems the most suitable since Repeater is not visible in the topology.

In the absence of GPS, I will configure an NTP server to have a reliable time base and set the screen scrolling to 10 seconds to compensate for the lack of physical navigation buttons.

• Config > Device: Role Client
• Config > Network: NTP Server fr.pool.ntp.org
• Config > Display: Carousel Delay 10 seconds

Now, the goal is to bridge this node with other networks using MQTT connectivity. The public MQTT server allows node position information to be sent (be cautious with this), enabling them to be visualized on the general map. Care must be taken with the data coming from the MQTT channel, as it could saturate local network communications by broadcasting the large volume from the global network. Therefore, I will only activate the upstream flows.

• Channels > Primary: Allow Position Requests ON
• Channels > Primary: Precise Location OFF
• Channels > Primary: Approximate Location Within 1.5 km
• Config > LoRa: Ignore MQTT ON
• Module Config > MQTT: Enabled ON
• Module Config > MQTT: Map Reporting Enabled ON
• Module Config > MQTT: Map Report Publish Interval 3600 Seconds
• Module Config > MQTT: Approximate Location 1.5km

After the given interval, the position is reported and visible on Meshmap service.

Range / Coverage testing

Initially, I will activate the Range Test module, which sends messages at regular intervals that are acknowledged, allowing me to see the area covered by this node. Be careful, you should only activate this mode when starting a mapping session with another node, and make sure to turn it off afterward. This needs to be setup on both devices:

Sender configuration

• Module Config > Range Test: Module Enabled ON
• Module Confg > Range Test: Message Interval 30 Seconds
• Module Config > Range Test: Save CSV to Storage OFF

Receiver configuration

• Module Config > Range Test: Module Enabled ON
• Module Confg > Range Test: Sender Interval OFF
• Module Config > Range Test: Save CSV to Storage ON
• Radio Config > Position > Position Packet: Broadcast Interval 5 Minutes
• Radio Config > Position > Position Packet: Minimal Interval 15 Seconds
• Radio Config > Position > Position Packet: Minimum Distance 50 Meters
• Radio Config > Position > Device GPS: Update Interval 30 Seconds

On the receiver you should receive a message “seqN” every 30 seconds if you see them, you can start your range test trip. At the end of the trip, you can restore the configuration and download the result as a csv file you can upload on mapping system. The range test file is stored on the receiver. You need to connect receiver on a WiFi network to download it on http://meshtastic.local/rangetest.csv

Create a private communication channel

The purpose of Meshtastic is to create communication channel in a private way, not really to broadcast data on a public channel. The channel are encrypted but there is a limited number of channels so the same channel will be able to transport messages for different group of users and the user will recognize their own messages thanks to the validity of the payload after decryption. I’m not sure of the exact reason but I assume it’s related to the lack of message signature/crc validating the decryption, the channel name musty also match between the devices to validate the communication.

There is no way to exchange encryption key so the channel need to be manually setup with keys exchanged a different way.

Seven channels exists, one of them is identified as primary, it gets the periodic broadcast and telemetry. Other can be disabled of secondary, in this case it will be encrypted.

• Channels > Ch1: Role Secondary
• Channels > Ch1: pre-Shared Key b38b26fa07e9bbbf90b0fd41ee7e35a2 (example)
• Channels > Ch1: name myChannel
• Channels > Ch1: Allow Position Request ON
• Channels > Ch1: Precise Location ON (the channel is secured)

Now we have a secure channel in between the nodes (my channel name is disk)

Next steps

We have seen how Meshtastic is used. I am currently writing a more detailed article on how the protocol works to better understand how the mesh network operates and its level of adaptation to LoRa. What I can tell you is that I am very impressed by the software stack related to its usage, but much more skeptical about the protocol itself … to be continued.