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) rules are obeyed.
This site is about lora radio mesh projects, similar to Meshtastic or MeshCore, that let you communicate using a local radio network. The 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 licences, 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 24/7 to make the network resilient also to failures in the power grid.
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. For example, one can use Heltec V3 lora radio boards with computers to create a radio mesh which you can use to send messages via software called Reticulum MeshChat, as explained here:
Reticulum MeshChat by Liam Cottle
and a nice setup video for starting off is shown here:
Reticulum Meshchat on Ubuntu Linux Setup with Audio Messaging by Simon Phillips
The above video shows an example (case study) of a basic setup and functionality of a lora radio mesh employing 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 (deliberately not upgraded to higher). 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 at all. There is more parts info 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 key stumbling block in flashing the RAK and T-beam radios was setting Chromium to allow direct USB connections, as the radio button for that was off-screen (the menu being too large for the screen size). Simon Phillips found the way to do it, as follows. Go the the Ubuntu Software icon (orange suitcase) and find and click on Chromium under the tab "Installed", and then select the "Permissions" button. Then the radio button you want to set to "on" is "Access USB hardware directly". Make this radio button visible, so you can click it, as follows. To get to the bottom of the permissions list, right-click in the top bar and click on the Move option that appears. WITHOUT pressing mouse buttons, flick upwards on trackpad until the USB setting "Access USB hardware directly" at the bottom is visible, or only just visible. Toggle the switich to on. Press ESCAPE key on keyboard to unselect Move. Then you can toggle USB setting. Now you have done that, the flashing of the lora radio to make it into an rnode will hopefully work via Chromium.
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").
The idea behind reticulum is well summarised in this video talk:
Reticulum - unstoppable networks for the people by Mark Qvist
Guides to most things by Mark Qvist
Gettings started by Mark Qvist
See also the links below.
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, which is an address at which folks can reach you irrespective of what server or hardware you are using to "check your mail" (smartphone, laptop) or they used to send you the mail. However, this addressing 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. Folks 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.
Mobile node by Mark Qvist
Make your own rnode by Mark Qvist
A loft node and a computer node: link to post.
Command line rnode setup video by Simon Phillips, useful for preparing a stand-alone headless rnode, over ssh, as a transport node to relay messages received. The video includes rns software installation and rnode firmware flashing from the command line.
Headless raspberry pi 4 single board computer runing reticulum meshchat: this video takes you step by step through Liam Cottle's instructions for setting up reticulum meschat on a raspberry pi 4 via ssh on the command line, wherein the raspberry pi is "headless" i.e. does not need any keyboard nor screen. Reticulum meshchat allows you to control the raspberry pi via a web browser page over your local network. This is ideal for setting up and maintaining raspberry-pi-based transport rnodes in the field which may not be very accessible. This is the first step to making a solar setup.
Testing a direct contact from one reticulum rnode A to another reticum 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 sitution for setting up a lora mesh, and might be wrong or based on a misconception:
Say you want to test multiple lora radio rnode connections in a 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 a great deal of other radio connection quality information besides (recived signal strength indicator RSSI, singal 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-positoined (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. Certianly 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, woudld 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 similiarly 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 based 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 message unless positively set to do so (Transport Mode = Enabled), whereas in meshtastic this is the default and so leads to rapid immediate mesh expanstion 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 advance 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.
There are three 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 firware 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 rnode should be able to have its firmwear 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.
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 LiIon 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) batteries, to enble 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. Alternativele LiFePo batteries could be considered as they are very safe also, but less suited than LTO for use in freezing conditions.
Is it not capital L and capital R in lora? It seemed to me that there are trademarks involved so I stick to 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 currenlty 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 communicatoin 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 possibilites to stop being dependent upon any big tech or infrastructure that disrepsects privacy rights.
Nice 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.
Places to go and things to visit
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.
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 ).
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 09-02-2025 MMDDYYY 13:53:00 EST