Lora SDR data

lora radio mesh communication

lora radio quick introduction | Flashing the rnode firmware onto a radio | MeshChat on Ubuntu | Settings | Reticulum details | LXMF addresses | rnode builds | Testing the lora mesh | Wishlist - Safety | Remarks | Links | Reticulum mesh places | Radio first aid | About the site

Lora radio and mesh networks

Lora* radio is in a part of the radio spectrum (868-870 MHz in the EU/Europe) that can be used by everyone and anyone, provided basic power and transmission duration (duty-cycle) and frequency and bandwidth rules are obeyed.

*see remarks for typography of lora

This site is about lora radio mesh projects, similar to Meshtastic or MeshCore, that let you communicate using a local radio network. About four years ago there was a lora mesh project called Ripple with working devices.

The lora radio network is set up by the users placing radios in a local area to provide coverage over as large an area as possible. The resulting network is called a mesh and the radios are called nodes.

The radio nodes are small and low cost. No licenses, permissions, etc. are required to use them. The radio nodes can be fixed in good locations to cover an area reliably, and of course can be portable and battery-powered so you can communicate over the mesh wherever you are in the area covered.

The mesh (radio network) made this way is completely independent of any cellular phone network, and completely independent of the internet. This makes the network resilient to failure of other communication infrastructure. Many radio node owners strive to set them up so that they run via solar power, and achieve that they operate permanently to make the network resilient also to failures in the power grid.

 

Reticulum Network Stack - lora radio quick introduction

Although meshtastic has taken off because it is rather easy to set up and use, with a large user base, there are alternatives with their own advantages. As an example, one can use Heltec V3 lora radio boards with computers to create a radio mesh which you can use to send messages, sound and images via software e.g. Reticulum MeshChat, as explained here by Liam Cottle's Reticulum MeshChat.

A nice demo video by Simon Phillips presents Reticulum MeshChat on Ubuntu with audio messaging.

The above video shows an example of a basic setup and functionality of a lora radio mesh employing Reticulum (i.e. the Reticulum Network Stack or "RNS"). RNS, or Reticulum, is the particular protocol enabling routing of encrypted messages (packets) between nodes, in particular lora radio nodes. The radio nodes are called 'rnodes' in the context of Reticulum.

What can be done is shown very well in this demonstration of a lora Reticulum mesh by Simon Phillips.

Using the Ubuntu video, and the other related videos by Simon Phillips, I was able to get started very easily. I used two laptops, on which Ubuntu 22.04.5 LTS is installed. I was able to put a Lilygo T-beam Supreme in my loft, under the roof, and use a Muzi Works R1 RAK node on my computer to set up an in-house mesh. The rnode in the loft was connected only by lora radio, with no internet interface. There is more information in the links below Rnode builds 'A loft node and a computer node'. The aim of doing this was to see if any lora radio connections would arrive in my loft over Reticulum, and then be seen on my laptop rnode.

The above introduction is just an example. There are many linux aspects described here because linux gives you more lego blocks and design options. You can comfortably employ Android and iOS devices to use lora radio rnodes for accessing the reticlum mesh, see below, without having to delve into Linux things at all. One of the pleasures of 'meshing about' with radio-related technology and Reticulum is that it gives you a strong motivation to take the plunge and actually use Linux for real. Up to now I had read up on Linux but never had a tangible project, with hardware involved, to apply its techniques to and thereby learn: till now. So I recommend considering all options to see what is the the best fit for you.

Flashing Reticulum rnode firmware onto your radio hardware

The first step is to set up your radio. Detailed instructions on flashing Reticulum rnode firmware onto your radio hardware.

Getting going using MeshChat on Ubuntu

Here is a link explaining step-by-step how to freshly install Ubuntu and MeshChat as one way to enable messaging using rnodes.

Sideband for Reticulum lora mesh on Android

Sideband by Mark Qvist is an app that lets you send messages, using Reticulum, over a lora radio. To install sideband on an Android device do the following. First, if it is not already, temporarily make Chrome your default browser. This step is needed to make the download occur in Chrome in a later step. Then go to: Settings - Apps - Special app access - Install unknown apps - Chrome - and toggle the radion button 'Allow from this source' to 'on'. Then, in chrome on the Android device, download the .apk file from Mark Qvist on github, by selecting on that site 'releases', then 'latest release', then scroll down to the list of versions and click on the three-dot menu next to the .pkg version, and finally select 'download'. The location of the download is then chosen in a pop-up. When downloaded, the download pop-up remains visible, and all you do is select the .apk file (which is shown listed at your selected location). This selection of the .pkg file initiates the installation, provided you answer the next pop-up accordingly to authorise the installation. I then made Brave my default browser again. Return the 'Install unknown apps' radio button setting 'Allow from this source' to 'off' for Chrome.

If you can connect your Android phone to the rnode without a usb cable, i.e. by Bluetooth, then you could use the following to use the Android interface of Sideband on your Linux/Windows/macOS machine (from this video):

  1. Connect the Android device via USB cable to the Linux machine
  2. install scrcpy
  3. then icons show on the desktop
  4. but clicking scrcpy icon on desktop does not open any app
  5. enable developer mode on phone as shown in this video about scrcpy
  6. enable USB debugging on the Android device
  7. click the icon 'scrpy (console)' on your Linux/Windows/macOS device
  8. now you can use the Android device's interface on your Linux/Windows/macOS device

For the iPhone series with a USB C connection, it appears (according to this video) that at least this UGREEN USB C hub could provide muliple USB ports on the later iPhones. It might be that using an OTG hub device you can get multiple USB connections to some Android devices.

iOS and Reticulum

Reticulum is making it to iOS (iPhone, iPad) in a test version of the Sideband app. Open this link to TestFlight when in your iOS device and one can take part in the testing, so I am told.

NomadNet and the Nomad Network

Details about the toolNomadNet to create pages and message using Reticulum.

Settings

Always set any rnode, that is part of a mesh, to be a transport node e.g. in the settings menu of MeshChat or in the configuration file directly (see e.g. Rnode builds "Command line rnode setup").

Especially for a fixed node e.g. on your roof, set your rnode to be a gateway interface. The advantage for the mesh routing is described in section 4.16 of the rns manual. Setting a well-place fixed rnode to be a propagation node is useful as then you can retrieve your messages when you make contact with that node again via a receipt by the propagation node of your so-called "announce" message when you are back in range of the propagation node. I am told that in version 20 of MeshChat you need both propagation and gateway mode to be set for it to work as intended.

Lora settings (Europe) that work:

Frequency: 869525000 Hz = 869.525 MHz

Bandwidth: 250 kHz

Transmit Power: 22 dBm (typical maximum power allowed and available from hardware)

Spreading factor: 10

coding rate: 5

Not all combinations of parameters work. One has to make sure the send signal is shorter in time than the lora protocol allocates for handshaking so as not to cause overlaps of packets that prevent delivery confirmation.

In Meshchat's 'Interface' menu, select your RNodeInterface, go to the three-dot menu and select 'Edit interface', and under 'Optional RNodeIntrface Settings' put:

Set the duty cycle under 'Airtime Limit (Long)` as 10 (see this explanatory video about regulations)

Reticulum Network Stack (RNS) - details galore

The idea behind Reticulum is well summarised in the video talk Reticulum - unstoppable networks for the people by Mark Qvist

Guides to most things by Mark Qvist.

Getting started by Mark Qvist.

See also the links below for more information about internet issues (e.g. other decentralised internet projects).

 

You are reachable via your LXMF address - however you interface to the mesh

A lora mesh using Reticulum is different from the current (February 2025) Meshtastic lora mesh in one key way concerning your personal address in the mesh. In Meshtastic, the radio node short name (or other name of the radio itself) is the end-point address to reach someone: you send a message to that lora radio. Using Reticulum, you have an LXMF address (and an identity) that is not associated with any particular lora radio rnode device, but instead is an address and identity that resides in the device/GUI used to communicate over the mesh, such as your laptop (e.g. using MeshChat) or smartphone (e.g. using Sideband). This means that you can be reached irrespective of what radio hardware you happen to be using as an interface to your laptop or smartphone. Your address in Reticulum is more like a unique mail address or phone number, so it is an address at which you can be reached, irrespective of what hardware is used to contact you. This addressing functionality is, in Reticulum, achieved without any central servers such as used for email, but instead by a distributed mesh. This makes a lora communication system under Reticulum a more permanent and more long-term stable communication tool for normal everyday use. People can reach you whatever technical means they, or you, use to access the mesh. In a public emergency with no grid power, it may be that they can only reach you if they are in your lora radio mesh area; but at other times when infrastructure works normally, they can reach you via the internet also. The lora radio is just an "interface" but not itself the point of interest nor the address for messages to land. Being able to have the same address independent of the infrastructure is an accommodating, seamless and resilient manner of continuing communication in any emergency situation. The existence of a portable address allows you to change and upgrade your hardware without losing contact with others in the mesh, because you take your LXMF address and identity with you at enter it into the settings of your new radio device's computer.

Rnode builds

Stand-alone rnodes

Work is going into making a stand-alone transport node that does not require any separate computer but instead only the radio itself. A stand-alone system relies then on the processing power of the radio board. This is how Meshtastic and MeshCore work. Such stand-alone efforts for Reticulum rnodes are on-going, for example by Smurphy. One aim of these efforts is to reduce the power consumption and price and thereby make small, autonomous solar rnodes easier to implement and so extend a resilient Reticulum lora mesh.

Testing a lora-only mesh of rnodes for availability of radio contact

If you want to test access to the mesh, or find other nodes in your area, the most important thing is to make sure you have a node well located and on 24/7. Only if a node is on all the time are the chances maximised that someone joining the mesh and seeking other nodes will find you. When nodes are switched on and off randomly it can be doubly hard to be in contact because one needs not only a good radio contact, but also by chance the right time.

When setting up a mesh one has to choose the parameters of the radio signals to use. Important is the frequency. It can be extremely helpful if at least one person involved in the project has the ability to examine the local radio spectrum to see if a frequency in the band you are allowed to use is also free of major disturbances. When testing it is also useful to be able to see the radio emissions from some radios to make sure that their properties are as expected, e.g. the duration of the signals.

Testing a direct contact from one Reticulum rnode A to another Reticulum rnode Z is easy so long as you disable all the other interfaces, like internet, on the computers/smartphones that run the nodes A and Z. There are superb on-line tools for checking where your lora radio should be able to receive from and transmit to by direct line of sight: heywhatsthat, scadacore line of sight, adreilien, Radio Mobile by ve2dbe.

The following is my analysis of the Reticulum situation for setting up a lora mesh, and it might be wrong or based on a misconception:

Say you want to test multiple lora radio rnode connections in a Reticulum lora mesh, to see if your static lora radio interface A reaches static lora radio rnode interface Z indirectly by "hopping" via other lora radio rnode interfaces B, C, D etc.. You may want to do this to see whether there is a line of sight between sufficient number of pairs of nodes in the mesh for the message to pass hop over a far larger distance than is available by any direct line of sight from your node A.

In my opinion one is well advised to test this physical radio line of sight hopping aspect of your mesh using Meshtastic nodes initially, because in Meshtastic you can obtain very easily and quickly the so-called 'traceroute' of the hops available to reach Z from A, and other radio connection quality information besides (received signal strength indicator RSSI, signal to noise ratio SNR). One can with meshtastic check out a node, in your list of available nodes, to see what path ('traceroute') can be hopped to send a radio message to it. That way you can map out an area and see which points will have lora radio coverage due to one or two well-positioned (high-up) nodes that appear in the traceroute.

A mesh 'radio testing' using Meshtastic is suggested because the Reticulum Network Stack, and the software GUIs that use the radio rnode interfaces, such as MeshChat/Sideband/Nomadnet, inherently do not provide any means to show you the paths (hops) actually taken by a packet in the mesh for a message/ping from one node to another. There is no traceroute function exposing the intermediate hop names; as this provides extra secrecy from the encryption protocol. However, using Reticulum MeshChat, you can see the network and node types in the live network visualiser and rnodes are indicated: so you can surmise/guess that a radio-only path may in principle exists between a certain set of rnodes if enough of them are in range of each other in a suitable topology. One could identify the nodes in question, and message them and perform tests with the computers running the nodes in flight-mode. Certainly hours of fun and very social.

The Reticulum protocol will pass messages without regard to means used: you cannot, in Reticulum, select or decide on the physical means taken by a packet as that is not under the control of the sender. For example you cannot force a message to go by lora mesh only. This means that if you want to test whether, if there were no internet available for any of the nodes in the mesh, a packet/message sent from A, and addressed to Z, would reach Z by a lora-only mesh at the current time, you need to take special measures. Those special measures might be something like sending a message to every known (announced) rnode, and co-ordinate with the users of those rnodes to run an 'internet free' test. It may be that rnodes can be set to be able to be administered to automate this, but I am not sure. Also, to get any sort of 'traceroute' database for the mesh to see what lora-only routes work at the time of testing, you would need the users or the rnodes to report back (or post online) voluntarily which test messages were received. This is because no user knows the path taken by a packet that arrived at their interface: it just shows up.

So I think it is most pragmatic to use Meshtastic for a physical check to see what is coverable in a region; and then to add Reticulum radio rnodes in exactly the same locations as the meshtastic nodes were that were used to test. Those rnodes would then be expected to perform similarly if every other node in the Reticulum lora mesh had no interface active but for lora i.e. the internet interface were off/down. So for example, if you know from a Meshtastic mesh, that two or three nodes in very good high static locations cover an entire region of a town or area, then that would be superb information to use the same physical locations and hardware and radio power settings etc., to run a Reticulum lora mesh.

I think the difficulty of this process suggests that the Reticulum lora mesh it not well-suited to making an ad hoc backup lora-only mesh that users could tell covers a given zone in an emergency, like Meshtastic. Note that an rnode will not automatically forward all messages unless positively set to do so (Transport Mode = Enabled), whereas in Meshtastic this is the default and so leads to rapid immediate mesh expansion with every new user that uses the default settings. A Reticulum lora-only mesh that is to have wide coverage for general use, requires more advanced co-operation to set up and test than Meshtastic does. But once set up, Reticulum lora mesh has profound advantages like provision of images and web-site access when internet is down, which ultimately would be a solution for preserving modern communication and information sharing independently (resiliently) of other infrastructure that has undergone prolonged failure or prolonged shut-down.

Mesh wish list

There are some things that I would like to have realised in a lora mesh system:

(1) If I know I can reach an rnode A and I know that rnode A can reach rnode B, then I want to be sure that I can reach node B. This is a minimum requirement for any mesh message passing design. I noticed, some time ago, that in Meshtastic this was not the case then, and some people were not able to be contacted by me even though I knew that we each could message a certain intermediate node. This meant that the mesh was not providing as much coverage as it theoretically could. We did not, in testing, find out what the cause was (though it seemed to be a new effect when the flood routing was tweaked based on sending preferentially to nodes with stronger signal data and not flooding to the others, or something like that. However testing was made hard by the exitence of nodes in 'router' mode to which the Meshtastic algorithm preferentially sent messages for onward travel, meaning that optimising the mesh based on topology data was practically impossible.). It was frustrating because often the people who were most on the edge of the geographical region covered by the mesh were reliant on a single node, or few nodes, to link into town from the periphery: even though on paper the lora mesh did extend that far. I hope that Reticulum can produce a predictable and reliable mesh coverage for a given physical infrastructure.

(2) If an rnode runs on battery and the battery runs empty, then the rnode should wake up and be fully functional as soon as the battery is able to provide power again. In particular, a solar rnode should recover if it switches off due to lack of sun: every time, and without fail. I was not able, using the RAK node, to obtain a simple setup that worked in this respect (except when using the Waveshare D solar power manager board). RAK said it was a Meshtastic firmware issue, and many makers had issues here and gravitated to making the battery and panel setup so that brownout never happened so re-start failing to recover radio functionality would never be an issue because the solar node never ran out of power in the first place. I find that to be a pragmatic solution but tends to stand in the way of miniaturising and reducing costs (not to mention battery size and attendant increased safety issues the larger the battery). I am hoping that the rnode design will move any such issues away from firmware and onto the computer that uses the rnode interface, because the hope is that one can then set up a control system more easily using computer programming, rather than having to adapt firmware, which is quite a specialised skill that I lack even more than I lack programming knowledge.

(3) An mesh radio node should be able to have its firmware adjusted, or re-flashed over lora, without requiring physical, or other radio access, to the node. This is known as OTA update, and I mean lora OTA update. Ideally a firmware update is not required often. If an rnode is in a fixed location together with a computer, then ideally the computer should be able to be controlled and have data uploaded to it at a distance via the mesh, or failing that via a wireless link with better performance, in terms of range, than bluetooth. My experience with bluetooth connections is that they are too weak and low range to be a good basis for interfacing with a node setup. My hope is that using an rnode as an interface to a computer, or computer board, will provide more reliable ways of managing, updating and repairing nodes in the field in locations that are not very physically reachable and/or fail via bluetooth.

(4) An mesh radio system should be able to have its radio frequency of operation changed remotely.

(5) An mesh node system should be able to be deactivated remotely, at least for a given amount of time. This can help in all sorts of situations, not least testing the mesh for resilience to rnodes going off-line.

Battery safety of mobile and fixed devices

When playing with Meshtastic, I was very surprised to notice that, though the electronics and computing side of lora mesh projects are a natural hurdle, a similarly large hurdle when making things oneself to use for real, is making decent cases and housings for portable and outdoor nodes. I am not sure that this aspect is soluble, but would be most relieved if there were an affordable standard casing available which at least securely houses all known boards and robustly fixes the antenna connections, even if then not as compact as possible, but suffices to be getting on with their use in the field. In particular, a case (or battery case) that allows for most sensible battery designs to be incorporated while also providing a safe, fire-proof housing in the event of battery issues, would boost the uptake of lora mesh projects. Safety issues are probably the single largest impediment to establishing a mesh in a given area, as makers worry about risks associated with leaving LiPo and Li-ion batteries in the field. We do not want DIY radio projects to lead to the exploding electro-scooter phenomenon, leading to a bad press or worse, e.g. provoking law-makers to think of reasons to ban something. I would like to see more battery-powered solutions based on LTO (Lithium Titanate Oxide) batteries, to enable nodes to be placed anywhere and everywhere due to the essentially guaranteed safety of LTO batteries. Though LTO batteries tend to be large, this is not a problem for fixed installations. Alternatively LiFePo4 batteries could be considered as they are very safe also, but less suited than LTO for use in freezing conditions.

Remarks

Shouldn't it be capital L and capital R in lora? It seemed to me that there are trademarks involved so I stick to lora for LoRa®.

You may wonder why this site is so clunky with no decorative elements. A Reticulum-based lora radio mesh can be used to host, and make available for distribution over that mesh (and further afield), simple pages, and bulletin boards (BBS), akin to websites. This is only currently feasible for simple sites in a format like this one, so I thought it best to get used to this format ... and it is easy to set up.

Why are such projects so rampantly popular? One reason setting up lora mesh networks for communication is so popular is because it involves neat, cheap technology and yields social network made by the users. Another reason for the popularity is that our communication tools have become critically important to daily life, and the thought that communications can go down, or be blocked, makes setting up home-made alternatives very attractive. The fact that these lora mesh alternatives are not very hard to establish, makes the aim of being self-sufficient within reach, and opens up many possibilities to stop being dependent upon any big tech or infrastructure that disrespects privacy rights.

The law

There are lots of rules, for good reasons, about radio. The law is normally at your national level. This is German amateur radio site that might help. More information about the German radio rules can be found Bundesnetzagentur document.

UK information is in this Ofcom document.

General information may be found at The Things Nework, disk91 and the European Telecommunications Standards Institute.

The European Conference of Postal and Telecommunications Administrations (CEPT) provides a European Communications Office (ECO) database providing an overview of the use made of various bands of the radio spectrum.

Patent issues are taken not to be an issue for a non-commercial use.

A good starter video about lora in general.

Helpful explainer by @Linux_in_a_Bit@infosec.exchange (find them here)

A scary video about how the internet works which might go some way to showing why Reticulum is a groovy alternative.

A detailed analysis of Reticulum rnode use by Michael Faragher.

Reticulum site in Italy.

This Let's decentralize site lists many other decentralised web projects.

Some interesting use of Reticulum status reporting by Ed Braaten, N7EKB.

Places to go and things to visit via Reticulum e.g. NomadNet

  1. Public message board (like Meshtastic's public 'longfast' channel in some way) for general use:

    848d5251cb85ccdaef732cdd9f76c300:/page/index.mu

    hosted by Kilo40-PiNode on the Nomad Network. Just paste the URL into your nomadnet interface.

     

  2. This is the URL to use in Reticulum:

    428118bf70e715a89331ea928b250c05:/page/index.mu

    e.g. via MeshChat to join a forum based on this code kindly pointed out by "Linux in a Bit" @arcushing:matrix.org on matrix (I access matrix chat using the app called element ).

Radio first aid

If your rnode is not working, you may need to have a look at some radio techniques.

Who, how, when

This is me on Mastodon, the main social network I use. I tried others, but I recommend Mastodon.

This site is hosted by Hetzner. If I can do it, anyone can do it.

Last edit 03-07-2025 MMDDYYY 12:00:00 EST

Lora SDR announce data