rns.recipes

Heyo I wanted to share some concerns I have around the widespread adoption of LoRa as the technology for building community networks, which doesn't seem to be much of a conscious choice.

LoRa is a proprietary technology, patented by Semtech, US-based semiconductor company. I don't think I need to go in depth here why it's bad to rely on a patented technology.

It's totally possible to buy chips, even form Semtech, which are more generic and are not bound to a single radio technology. i.e. SX1232 which can do FSK, GFSK, MSK, GMSK and OOK modulations according to the manufacturer.

I haven't seen much adoption of HaLow in Europe either. It's an open standard which IIRC is somewhat popular in Moscow, HaLow chips and boards for the 868MHz band are slowly appearing troughout this year (i remember struggling to find anything in January, now there's a couple options) - I'm not sure if people know about it? Seems like quite a capable protocol - what's your experiences with it?

Having said that, the ISM bands that are commonly used for LoRa/HaLow (868/433) tend to be quite congested, especially in cities and so we shouldn't rely on them for any prepper related scenarios. Especially if you consider that there's also meshtastic and meshcore and all sorts of municipal and company sensors using those bands. But even in day-to-day we're trying to squish our comms into this super narrow band with ridiculously low duty cycles... I don't see this working reliably.

Cities are way better suited for wi-fi connectivity as we can build directional links. There's plenty of wi-fi based community networks from NYCMesh to freifunk that we can be taking inspiration from. Also free space optical anyone? https://en.wikipedia.org/wiki/RONJA

Anyway, this post is a bit chaotic but it's late and I'm sleepy. I guess I just wanna share these thoughts and I'm curious how yall relate to this?

i have actually been taking great interest in halow for transport backhaul for lora access points, but you def have a point. lora in my local area is an easier lift for people in the community just because of the abundance of meshtastic/meshcore users who already have lora radios that can easily be flashed into rnodes. i get the thing about the ism bands, they are pretty crowded but if we're talking about a somewhat forced abandonment of ac electricity, the noise floor will be much lower :) maybe if halow gets more traction that can run on the user side and just use good old 802.11 on 2.4g for backhaul. that's the beauty of this project, it's easy to meet the needs of your community

Just a perspective on the forced abandonment of AC power and its impact on RF noise.

What you usually get when the grid goes down is everyone and their grandmother running cheap generators and battery powered inverters all the time and the RF noise gets worse.

In the EU it would be possible to use 433 MHz for LoRa and reserve 866 MHz for HaLow. In fact, 433 MHz might be even better both for long range and penetration, and HaLow is supposedly good at dealing with a busy bandwidth.

https://openmanet.net/
Has anyone tried if OpenMANET & Reticulum could work as part of the same network in practice? Based on my admittedly limited understanding it should be possible, but theory often disagrees with practice.

flok wrote:

Heyo I wanted to share some concerns I have around the widespread adoption of LoRa as the technology for building community networks, which doesn't seem to be much of a conscious choice.

LoRa is a proprietary technology, patented by Semtech, US-based semiconductor company. I don't think I need to go in depth here why it's bad to rely on a patented technology.

It's totally possible to buy chips, even form Semtech, which are more generic and are not bound to a single radio technology. i.e. SX1232 which can do FSK, GFSK, MSK, GMSK and OOK modulations according to the manufacturer.

I haven't seen much adoption of HaLow in Europe either. It's an open standard which IIRC is somewhat popular in Moscow, HaLow chips and boards for the 868MHz band are slowly appearing troughout this year (i remember struggling to find anything in January, now there's a couple options) - I'm not sure if people know about it? Seems like quite a capable protocol - what's your experiences with it?

Having said that, the ISM bands that are commonly used for LoRa/HaLow (868/433) tend to be quite congested, especially in cities and so we shouldn't rely on them for any prepper related scenarios. Especially if you consider that there's also meshtastic and meshcore and all sorts of municipal and company sensors using those bands. But even in day-to-day we're trying to squish our comms into this super narrow band with ridiculously low duty cycles... I don't see this working reliably.

Cities are way better suited for wi-fi connectivity as we can build directional links. There's plenty of wi-fi based community networks from NYCMesh to freifunk that we can be taking inspiration from. Also free space optical anyone? https://en.wikipedia.org/wiki/RONJA

Anyway, this post is a bit chaotic but it's late and I'm sleepy. I guess I just wanna share these thoughts and I'm curious how yall relate to this?

Adding myself as a watcher. Today I was also thinking about RF noise.

In our local efforts to build Reticulum networks, we have talked a lot about how the technical choices of the networks we build depend on how those networks are intended to be used. Often there use cases implicit in different proposals for network deployments, and making these intended use cases more explicit allows for better informed discussion of tradeoffs between different options. For example, a network for public emergency comms when the power goes out could look very different than a deployment for use by a discrete group of people in a remote area.

flok wrote:

It's totally possible to buy chips, even form Semtech, which are more generic and are not bound to a single radio technology. i.e. SX1232 which can do FSK, GFSK, MSK, GMSK and OOK modulations according to the manufacturer.

In general, I agree with having more critical awareness of the IP and supply chain liabilities of LoRa. On the other hand, it is also worth taking into account the significantly advantageous technical properties of LoRa modulation, specifically for long distance links between low-powered nodes. For solar and battery powered repeater deployments (especially in regions with darker, colder winters), and also for more geographically dispersed networks (rural and mountainous areas, but also urban sprawl), these advantages of LoRa are very important. I'm not so familiar with the other modulations you list, but I have the impression that they will all have higher power usage and/or cover less distance compared to LoRa.

flok wrote:

I haven't seen much adoption of HaLow in Europe either. [..] I'm not sure if people know about it? Seems like quite a capable protocol - what's your experiences with it?

I don't have any personal experience with HaLow yet, but have been doing research and trying to follow what people are doing with it. As mutt0n mentioned, it seems very promising for backhaul links, which could help alleviate the inevitable congestion problems in LoRa-based networks. Since this kind of backhaul infra would often be based around a smaller number of point-to-point links, it seems important that the distance limits of HaLow (compared to LoRa) can be partially mitigated through use of directional antennas between these backhaul nodes. I agree with what you mention about city terrain often being well-suited for this.

I've been looking at some different options for experimenting with HaLow transport nodes. There is a two part project by I-Am-Engineer to provide RNode firmware for Taixin TXW8301 HaLow radio hardware, and then a separate firmware for the ESP32 LilyGo T-HaLow device which acts as a protocol bridge to a separate RNS node. The T-HaLow also contains a TXW8301 chip, so it is possible both firmwares can be flashed on to that single device, the documentation is not clear on this point. Even so, this still seems like too many separate devices for it to be practical for solar/battery transport nodes, but the T-HaLow firmware does mention "Microreticulum (embedded RNS stack on-device)" on the roadmap, which would would improve things considerably if it were implemented.

The other promising option in the short term is the OpenMANET project, which is a distro of OpenWRT specifically for hardware with HaLow radios. It has support for the Heltec HT-HD01 hardware. Like other OpenWRT-based systems, it could potentially run the rnspure wheel and python3-cryptography, bringing together all the pieces necessary for a transport node on one device. Though the "Known Limitations" section of the OpenMANET docs for this device say "CPU performance is bad to the point where is affects webui load times" so that may be a blocking issue for practical use. Also, I just saw that in recent weeks I-Am-Engineer has started working on the HT-HD01, so hopefully that means there will be other options available in the not too distant future.

I probably won't be doing testing very soon on the HT-HD01, but I would like to test out running rnspure on more generic OpenWRT wifi router hardware. This opens up the option of running transport nodes on the least constrained supply chain of all: widely available consumer hardware that can often be salvaged for free! Less useful for the longer links of LoRa or HaLow, but great for local connection hubs that anyone can use via wifi.

flok wrote:

But even in day-to-day we're trying to squish our comms into this super narrow band with ridiculously low duty cycles... I don't see this working reliably.

I really agree with this, and I think it is one of the most important (but not yet very discussed) differences between using Reticulum for LoRa-based comms versus the better known alternatives like Meshtastic and MeshCore: by allowing for organically multi-transport networks, Reticulum allows for getting the important benefits of LoRa radio while also integrating higher-bandwidth links into the network so that the LoRa mesh can continue to be useful instead of completely congested with too much traffic.

Off-grid HaLow transport nodes could be one example of this kind of higher-bandwidth link. Another example is that even in a serious disaster situation in which power and internet infrastructure are disrupted, there could still be some fragmented areas that still have access to the internet. This could be either because their infrastructure is less impacted, or because they happen to have an autonomous internet connection such as satellite internet running off-grid. The combination of links that are possible via local-wifi+LoRa+HaLow+fragmented-internet are obviously going to be able to provide a more resilient communications network that is useful to more people in an emergency than some subset of these links.

One basic problem we've been running into in early testing of Reticulum-based LoRa networks is that in order to test how well a network is working we need to use it for communications. However, as long as there are any TCP/internet connections active on the network then RNS will always prefer these to LoRa because they are so much faster. Therefore, it seems like it will be necessary for the purposes of ongoing testing to find ways to disallow internet connections within an "off-grid" network that is composed of only local radio links using LoRa (and perhaps eventually HaLow). However, if part of the the intention of the network is to provide resilient comms in an emergency, there would also have to be some kind of "break glass in case of emergency" process of connecting this off-grid network to a diversified set of internet-connected transport nodes that would hopefully remain online and allow for anyone with fragments of internet connectivity to connect with everyone else who is more heavily impacted and only able to connect via radio links.

To be honest, I'm still uncertain how feasible it is to use Reticulum to build an emergency comms network in the way I'm describing above. I'm curious if anyone else has been reflecting on similar questions, or running into similar problems when trying to practically test Reticulum over LoRa.

[Accidental double post. Mods, you can delete this one]

Cleeyv wrote:

To be honest, I'm still uncertain how feasible it is to use Reticulum to build an emergency comms network in the way I'm describing above. I'm curious if anyone else has been reflecting on similar questions, or running into similar problems when trying to practically test Reticulum over LoRa.

If anything I'm pondering questions on the other end of the scale, as I'm about to move to a big city, and currently have no idea how to convince others to join a freifunk-like Reticulum network. I mean, telling others to install rns on their desktop PC and either turn off the password on the router provided by the ISP or share it with random people in their neighbourhood might work from a technical perspective, but it has a certain human element that's hard to deal with. The alternative is to install rns on a wi-fi capable device (such as an old smartphone) and use it only for networking; but even if I had a bag old phones to handle to random people, just the hassle of running a dedicated device might be enough to discourage them, not to mention that electricity is not exactly free.

Maybe the best way of cutting through this Gordian knot would be to present Columba as this super secure app that you can use to communicate with others privately without having to rely on random companies, and showcase that it can be also used to connect two phones directly even if there's no internet connection, and then bring up Reticulum's networking capabilities that way. I feel like that would do a disservice to both projects, but it might work for even with the kind of people who think that installing Linux on a computer makes you some sort of an elite cracker.