rns.recipes

Sup, I'm currently trying to plant some Lora nodes for the beautiful island of Ireland, and I'm conflicted on what exactly is a reasonable spreading factor along with other Lora parameters. If I like or not whatever I choose as my own lora settings will become the de-facto standard which then everyone after me has to deal with so I thinking about my choice carefully.

Now my strategy is just getting some nerdy friends to plant who are interested in this kind of thing to plant Some Heltec v4's running as RTnodes in their houses (https://github.com/jrl290/RTNode-HeltecV4), this means that changing the settings for all the nodes would be very challenging so I must configure them with reasonable settings now and I'm planning to put at least 4 R(T)nodes in different places, with them being all connected to my own central backbone interface I then route to the rest of my network, thus these nodes do not have to be connected to each other as they will have a tcp backbone link to eachother anyways (and to the rest of the network so forth) but the lora nodes being connected to each other would be nice and have some benefits in a "shit hits the fan situation" (note that most of these Heltec's will be plugged in wall socket and be indoors and will not have batteries, but worst case you can just connect them to a phone), but I more care about giving connectivity in the good times and getting the ball rolling with the reticulum network than anything else.

The geography of Ireland means that there's small towns/settlements every 2-4km. With larger cities requiring a least two Lora nodes every 10-16 km. In between there's tons of open farm land that shouldn't block Lora frequencies too much, but the urban environment in the middle of towns does. But I do not know enough people from all the small towns to have a clear path of Lora nodes between each major city.

I have three main schools of thought on this problem

Option 1, High bitrate, medium/low range

Using a spreading factor of 8 paired with most of the default uk settings (bandwidth 125khz, frequency 868.525, coding rate 4/5). This gives around 2.5kb/s per second which is way more than enough for messaging and decent for nomadnet, but it only has a range 2-3km, which I struggle to even reach in an urban environment. So I would require multiple nodes per town, probably 2-3 for total converage. However, it has the advantage that if other people create new nodes then the bandwidth cap is high enough that multiple could use it without too much issue, even with an airtime limit of 10% (which arguably Rnodes do not have to have legally but that's a discussion for a different day, we're assuming they do in this case), . So the Lora node would be serve a lot of people, but maybe not reach as many people as I desire, specially rural.

Option 2, Medium bitrate, medium/high range

I also considered using a spreading factor of 10 (avoiding 9 because that's what meshcore uses and I don't want to deal with that), this pretty much means that in an entire medium sized city one node can reach everyone (plus a decent chunk of the farmland). The range of 4-5km is also enough to theoretically hop from small town to small town to anywhere and it there would be enough bandwidth for a most use of reticulum (nomadnet and messaging), However in a possible future where more nodes show up, this then becomes less practical because a bitrate of around 620 bits per second is not a lot spread across 10 users and changing from the default becomes difficult. Now because each lora node is also connected to a backbone this is less of an issue but still something I'm keeping in mind.

Option 3, Very low bitrate, stupid range

We are talking 100 bits per second and 8-12km range. The thought process being that almost nobody is using reticulum, so it's instead better to cast the biggest net possible, and that if people require more bandwidth they'll make their own nodes, plus that it's more important to have emergency communication than anything else, allowing communication to (eventually) travel from city to city. The cons being that loading a single nomad page would drown out every lora transmitter in a 5km range for 10 minutes and already surpass the 10% airtime limit, among others and if it actually got used by more than 10 people (which I'm honestly not sure if ever would), then it would be already to being fully saturated from a few messages every 10 minutes.

Now I can always do a hybrid approach, and for my own home will probably set up two Rnodes connected to a single host computer one high bitrate (option 1), one for range (option 2 or 3 haven't decided) and the rnodes can route traffic through my backbone connection they don't all have to have the same configuration, still i would like to have one standard configuration that I use for most of the RTnodes that I will be deploying (makes thing simpler), possibly with some other configurations also being hooked into the network for more extreme circumstances such as very dense city centers and empty mountainous regions. I'll probably go with Option 2 after thinking about this for a while but I want to hear other people's opinions on this topic before committing.

Thank you

Two additional notes:

Even assuming that all the traffic would have to go through my purely Lora, I'm under the assumption that reticulum can handle low bitrates (lower than meshtastic or meshcore which use about 2.5kb/s roughly, so that's option 1) because it doesn't floodfill the network, with the exception of announcements that access points don't send or receive anyways, though that effect may be offset by reticulum's packet overhead and the fact that people will use it for more than just messaging. Is this a fair call to make here?

Meshcore uses a spreading factor of 8 (I thought it used a spreading factor of 9 and mentioned that fact above but I must have misremembered) would having the same spreading frequency as Meshcore (where there is a decent amount of traffic in my area) matter or does all Lora traffic interfere with itself with other transmitters of similar frequencies?

Urban works for me best with BW: 125kHz, SF: 9, CR: 7, although mind I run at 438.15MHz and these waves spread differently. This gives me around 1.3kBps, plenty for good stable messaging and no big images being sent.

I'm currently using BW 65.2 for more range, SF 8 because it works for MC very well and CR 7 to bump up a little bit of bitrate. I get 1.5kBps and i got close to 7-9 km in line of sight from city to out of city. Inside the city i managed 1-2 km but it depends on buildings and such, i also didn't try the whole city i think it may work even further in some places.

Still not sure it's the best approach tho, i'm planning to test out different settings but i don't really have time and energy right now. I also think it highly depends on the usecase.

Want emergency comms? Range and realiability first. You want to communicate with anyone and ask if they're ok, if they need help and maybe the location. This is ok with low bitrate. In such situations Nomad sites are secondary as priority, you first need to make sure people are safe and be able to help them, and only afterwards maybe surf some survival guides or so. Prepping means you also keep these guides offline, and if you can travel to people physically you can transfer the guides via bluetooth, you don't need to keep them available on Nomad site.

Indeed it's ideal to be able to serve such documents or information. However, regardless of LoRa settings, likely you won't be able to serve a 2MB PDF without blocking LoRa for a while.

This is fixed by design: Serve essential and short info per page.
This way if someone wants some specific information in an emergency, you only serve that page, prioritize the essential information and stripe out the useless details. Basically break huge information in smaller requests, this way LoRa isn't blocked by just one request of thousands of bytes at once.

You need to have this in mind when you create your nomadnet sites. Short and meaningful information, this way you can still serve pages on low bandwidth interfaces. I think this is an aspect that people ignore when creating reticulum sites because they're used to internet speeds. Mark is talking about such things in Zen of Reticulum and he's right.

Nomad1n0 wrote:

I'm currently using BW 65.2 for more range, SF 8 because it works for MC very well and CR 7 to bump up a little bit of bitrate. I get 1.5kBps and i got close to 7-9 km in line of sight from city to out of city. Inside the city i managed 1-2 km but it depends on buildings and such, i also didn't try the whole city i think it may work even further in some places.

Still not sure it's the best approach tho, i'm planning to test out different settings but i don't really have time and energy right now. I also think it highly depends on the usecase.

Want emergency comms? Range and realiability first. You want to communicate with anyone and ask if they're ok, if they need help and maybe the location. This is ok with low bitrate. In such situations Nomad sites are secondary as priority, you first need to make sure people are safe and be able to help them, and only afterwards maybe surf some survival guides or so. Prepping means you also keep these guides offline, and if you can travel to people physically you can transfer the guides via bluetooth, you don't need to keep them available on Nomad site.

Indeed it's ideal to be able to serve such documents or information. However, regardless of LoRa settings, likely you won't be able to serve a 2MB PDF without blocking LoRa for a while.

This is fixed by design: Serve essential and short info per page.
This way if someone wants some specific information in an emergency, you only serve that page, prioritize the essential information and stripe out the useless details. Basically break huge information in smaller requests, this way LoRa isn't blocked by just one request of thousands of bytes at once.

You need to have this in mind when you create your nomadnet sites. Short and meaningful information, this way you can still serve pages on low bandwidth interfaces. I think this is an aspect that people ignore when creating reticulum sites because they're used to internet speeds. Mark is talking about such things in Zen of Reticulum and he's right.

After thinking about it for a while, I think it would be more practical to have high dbi directional antenna between the towns instead of trying to reach them with unusefully low bitrate signals, so I could get the standard 1.5kbp/s between the towns and well as in them (spf 8, bw 62.5k), so that then that setting can be used for most basic usecases while also being able to connect all the areas together, allowing it to be the de-facto standard.

Based on some of the discussion here https://rns.recipes/forum/build-guides/how-to-choose-rnode-lora-parameters there's roughly three open Lora bands with 62.5k, so we could have above settings as one of the bands, and then use one of them as a long range high spreading factor for emergency comms and serving larges swaths of rural areas with a spreading factor in the 10-12 range with 500-100bit rates. And the finally use that remaining slot we could use for high bitrate (7.8kb/s) spreading factor 5 in very urban environment, which might be necessary to prevent the usage of the nodes in a city like environment from interfering with the communication between towns.

I'm sure someone's thought of some standard like this already, but I can't it anywhere. If not I might just picked some numbers based on what I've read

Directional antena is the way for linking cities. Here someone used a directional antena to link our country to another country on Meshcore. It's likely 100km of range i think.

All considered, I'm gonna use these presets and if anyone wants to copy for the ireland/uk/europe that's cool.

• High range, Slow bitrate for rural and emergency coms: 869.431 MHz, 62.5khz bandwidth, spreading factor 11, error correction 4/7. ~190bp/s 5-9km max range with 0dbi.
• Medium range, medium bitrate used as the standard overall but best for urban/suburb environments: 869.494 Mhz, 62.5khz bandwidth, spreading factor 8, error correction 4/6. ~1.3kb/s. 2-5km max range with 0dbi
• Low range, highest bitrate for very urban environments: 869.556 Hhz, spreading factor 5, error correction 4/5, 62.5khz bandwidth, 7.8kb/s, 1-3km range with 0dbi. This frequency band is the mostly likely to have interference with meshcore.

edit 2026-06-12: changed from 869.43125mhz to 869.431 mhz, 869.49375mhz to 869.494mhz and 869.55625mhz to 869.556mhz, see https://rns.recipes/forum/help/are-rtnode-frequencies-rounded-by-default

I'll mostly be deploying medium range, medium bitrate with occasional high range ones. High bitrate is really only useful if in a dense urban environment where you don't want the signal to travel too far and there's a lot of people wanting to use the connection. I don't see think that enough people will be connecting to the reticulum network through lora for that to actually be an issue for quite a while.

If there's any issue with anything I've said above inform me as quickly as possible.

Somewhat related:
I'm considering using both 433 MHz and 868 MHz bands when building out my local infrastructure. Essentially dual-band base stations with 868 MHz and 433 MHz, and directional antennas for long-range (near) LOS links. It would have a higher cost, but not that much I would think, an extra LoRa module and antenna doesn't double the cost. I do like the redundancy and flexibility of dual-band, and Reticulum will seamlessly bridge the two with RNodeMultiInterface. One could even add 2.4 GHz for tri-band.

In areas outside the range of base stations, people can agree on which band to use when extending the network. That means they can pick the one that's best for their conditions, in terms of physical obstacles and radio congestion/interference, or which LoRa modules they have available.

For a Reticulum network, I'm wondering if it's best to settle on one set of parameters per band. The more configurations you allow, the more bridges you need to create one network. I'd rather have larger regions with different configurations and have the base stations do the bridging. Still, you'd have to change parameters when moving between regions, so the larger the region the better.

joakim wrote:

I'm considering using both 433 MHz and 868 MHz bands when building out my local infrastructure. Essentially dual-band base stations with 868 MHz and 433 MHz, and directional antennas for long-range LOS links. It's more expensive, but an extra LoRa module and antenna isn't double the cost. I do like the redundancy and flexibility of combining bands, and Reticulum will seamlessly bridge them with RNodeMultiInterface. One could even add 2.4 GHz for tri-band.

In areas outside the range of base stations, people can agree on which band to use when extending the network. That means they can pick the one that's best for their conditions, in terms of physical obstacles and radio congestion/interference, or which LoRa modules they have available.

433 MHz has much lower max power regulations here, it's like 0.01 wats, or 10dbm compared to the 0.5wat max or 27dbm of 868 MHz for europe so I didn't even consider it (maybe you do more with a radio licence, not sure). If you are willing to ignore regulations or/and have a directional antenna where it won't really be detectable to anyone else anyways, it might have better penetration characteristics for very long distances.

2.4ghz varies from a max of 100mw to 4 full wats depending on the country, haven't personally looked into it but it could be a real option.

As for your final point, yea, as long as there's one transport node that translate between the frequencies (assuming no backbone interfaces), though that translation might means sending the same message/bits through two different bands doubling the total amount of data needing to be sent through lora which isn't fantastic but it's for the most part fine.

joakim wrote:

For a Reticulum network, I'm wondering if it's best to settle on one set of parameters per band. The more configurations you allow, the more bridges you need to create one network. I'd rather have larger regions with different configurations and have the base stations do the bridging. Still, that means you'd have to change parameters when moving between regions, so the larger the region the better.

I think most of the access points will be directly connected to a backbone interface or be able to communicate with one that is, and people will just use whatever lora they can use which is the fastest. Either they'll be communicating with someone close by where the lora configs are likely the same or they are just connecting to the general reticulum network to a place that isn't local in which case it doesn't really matter. In the border between the different configurations you might want one or two transport nodes that run at both configurations but for the most part it's not a big deal.

Yea the biggest reason to have kinda standard settings is convenience, having to change configurations every 2km would be annoying.

Also I'm getting a lot less interference (which was probably from meshcore traffic) after changing my settings so I think that was the right move

Nifty little set up. Got a medium bitrate medium range and a low bitrate high range rnode connected to one raspberry pi 2b

433 MHz has much lower max power regulations here, it's like 0.01 wats, or 10dbm compared to the 0.5wat max or 27dbm of 868 MHz for europe so I didn't even consider it (maybe you do more with a radio licence, not sure). If you are willing to ignore regulations or/and have a directional antenna where it won't really be detectable to anyone else anyways, it might have better penetration characteristics for very long distances.

True, but it can be good enough for meshing in densely populated areas, and near LOS (especially with a directional antenna). The much lower power consumption is good for mobile devices, as well as battery/solar setups and sensors. I think the 433 band has its uses even with the ERP limitation.

As far as I can tell, at least theoretically, the 869 sub-band has roughly 2-3× the range with roughly 5× the power consumption of the 433 band at max allowed ERP. In urban areas, the range of 433 can be roughly half that of 869 with a fifth of the power consumption. This is theoretical of course, there's a million factors that affect the signal.

With a license, the ERP limitation goes away, although there is that encryption issue on amateur bands…

Edit: I'm an (unlicensed) amateur when it comes to radio. I'd love to be corrected if I'm wrong about any of this :)

That said, 868 MHz is a perfectly fine choice, especially for stationary nodes on grid power, I'm just throwing out related ideas.

Nice little windowsill node :) If your deployed nodes are rPis connected to the internet, you could run rnsh so that you can remotely administrate them and change LoRa parameters. I'm thinking along the same lines as you, and that's my plan so far. I think it will take some experimentation to find out what works best.

joakim wrote:

Nice little windowsill node :) If your deployed nodes are rPis connected to the internet, you could run rnsh so that you can remotely administrate them and change LoRa parameters.

I have actually done this through lora only as a test, and it's one of the more painful I've done in reticulum, 25 seconds for an ls command. Granted rnsh has a 1 to 2 second delay even when directly connected through one hop, not sure if that's reticulum's fault, my raspierry pi being slow (or my local server) or rnsh being unstable and slow (never had an rnsh connection longer than 30 minutes because it always disconnects)

That does sound painful, I hope that's not typical for rnsh over LoRa. I've only used rnsh over Ethernet so far, and that has worked great.

Sounds like we'd need mosh over Reticulum instead of regular SSH. Mosh is pretty good at handling slow connections. In any case the "ssh over UDP" idea would probably map better to how Reticulum works.

welo wrote:

[image]

Nifty little set up. Got a medium bitrate medium range and a low bitrate high range rnode connected to one raspberry pi 2b

Oh nice, look good! the simple tape against the window makes me think "why didn't i think of that sooner??" That probably would've saved me buying one case for one of my indoor nodes haha. nice lil trick, thanks for sharing

Just keep in mind, that if the window has low-emission glass (metal laced glass), you not only will greatly attenuate the signal outside, but also detune the antenna resonance and make it an improper load for the LoRa radio, which will result in even worse performance. Clear simple glass is RF transparent and will not detune the antenna. I would not put antennas in touch of anything, if possible.