rns.recipes

I have seen many people asking questions about choosing RNode LoRa parameters, so I wrote up a concise practical summary:

Frequency - This needs to match between nodes. It is somewhat arbitrary, but can be chosen based on context-specific factors like local radio interference, existing use by other LoRa platforms, available antenna sizes, and local regulations.

Bandwidth and Spreading Factor - These both need to match between nodes. They both offer tradeoffs between speed of data exchange, and distance of effective communication.

Coding Rate - This does not need to match between nodes. It is the amount of error correction, so more of it slows down speed of data exchange (and slightly increases power consumption), but makes communication more reliable, especially important when there is a lot of radio interference at the frequency being used.

TX power - This does not need to match between nodes. Higher levels will transmit further, be easier for anyone to detect and locate, will consume more power, and can cause overload problems if two nodes are right next to each other and transmitting at high power. Higher power levels are also more likely to be regulated. The maximum level varies by LoRa device.

For more technical details, this page is very informative: https://unsigned.io/understanding-lora-parameters/

Also worth noting is that one should use a frequency and bandwith such as to not interfere with Meshtastic, Meshcore or other local LoRa protocols.

To avoid such interference, you must calcualte the start and end of the used spectrum for each and make sure they don't overlap.

So your chosen frequency is the center of the used spectrum. Let's say i chose 867.2 MHz as an example.
The badwidth is the width of the spectrum, let's say i use 250 KHz as an example.

As the frequency is the center, to get the low value you substract half the bandwidth, so in my example my spectrum starts at 867.2 - 0.125 = 867.05 MHz.
For the upper value we do the same but we add: 867.2 + 0.125 = 867.325 MHz.

Just make sure you don't overlap with other used spectrums in your area. This way the protocols will not interfere and will work independently.
If 2 devices will transmit in the same frequency, one can interrupt or corrupt the other, so it's best practice to avoid this.

There is also the LoRa calculator from Semtech: https://www.semtech.com/design-support/lora-calculator

Anonymous wrote:

There is also the LoRa calculator from Semtech: https://www.semtech.com/design-support/lora-calculator

You can't put adequate power levels in it, hehehe...

@Cleeyv @Nomad1n0 This is very helpful! Would you be OK with me adding this to the wiki?

Sure

joakim wrote:

@Cleeyv @Nomad1n0 This is very helpful! Would you be OK with me adding this to the wiki?

Yes, please do!

Nomad1n0 wrote:

Also worth noting is that one should use a frequency and bandwith such as to not interfere with Meshtastic, Meshcore or other local LoRa protocols.

To avoid such interference, you must calcualte the start and end of the used spectrum for each and make sure they don't overlap.

So your chosen frequency is the center of the used spectrum. Let's say i chose 867.2 MHz as an example.
The badwidth is the width of the spectrum, let's say i use 250 KHz as an example.

As the frequency is the center, to get the low value you substract half the bandwidth, so in my example my spectrum starts at 867.2 - 0.125 = 867.05 MHz.
For the upper value we do the same but we add: 867.2 + 0.125 = 867.325 MHz.

Just make sure you don't overlap with other used spectrums in your area. This way the protocols will not interfere and will work independently.
If 2 devices will transmit in the same frequency, one can interrupt or corrupt the other, so it's best practice to avoid this.

The issue is, that EU regulations are very strict and the only spectrum that allows even only 10% duty cycle and 27dbm is exactly where meshtastic and everyone else sits. The band is only 250mhz wide, so there is not much to choose if you want to stay in legal boundaries. You can try a narrow setting and split thr band in 2 or 4 parts. But you will always reveive all of the other traffic around you.

https://en.wikipedia.org/wiki/Short-range_device#SRD860

Anonymous wrote:

The issue is, that EU regulations are very strict and the only spectrum that allows even only 10% duty cycle and 27dbm is exactly where meshtastic and everyone else sits. The band is only 250mhz wide, so there is not much to choose if you want to stay in legal boundaries. You can try a narrow setting and split thr band in 2 or 4 parts. But you will always reveive all of the other traffic around you.

https://en.wikipedia.org/wiki/Short-range_device#SRD860

For reference here are the frequency 'slots' for Europe:

For 62,5 kHz

• 869.43125 MHz
• 869.49375 MHz
• 869.55625 MHz
• 869.61875 MHz

For 125 kHz:

• 869.4625 MHz
• 869.5875 MHz

For 250 kHz:

• 869.525

Meshcore in Europe mostly operates on 62,5/869.618. So if someone wanted to avoid them, you shoudn't use 62,5/869.618, 125/869.5875 and 250/869.525.

Yep, good point.
That's why it's better to coordinate with local LoRa groups.

62.5 band allows for more projects to work together(good for MC for having it as default). It also offers more range.
In the case above, Meshcore can use 869.618 and Reticulum can use 869.556 and no interference occurs because the spectrum is only .0625 MHz wide, or 0.0312 MHz above and below the center.

It's better to form a symbiosis and coexist peacefully than to use all the band and ruin the fun for everyone(including yourself).

Quick calculations for Europe regarding this:

Usable spectrum with ideal settings: 869.4 - 869.65
This allows 10% duty cycle with 500mW transmission power. Other bands has lower duty cycle or transmission power.

Meshtastic:
Default LongFast:
center - 869.525 MHz
bandwidth - 250 KHz (0.250 MHz)
used spectrum - 869.4 to 869.65 (basically all the band that is)

Meshcore:
Default EU/UK(Narrow):
center - 869.618
bandwidth - 62.5 KHz (0.0625 MHz)
used spectrum - 869.586 to 869.649

Unfortunately MT always use 250 KHz bandwidth in all presets(actually it uses 500KHz in ShortTurbo), so it'll always affect the whole spectrum when it transmits.

Being so that you can't really avoid this, it's best to at least avoid overlapping with Meshcore or other local LoRa projects.
Also i recommended to use 62.5 KHz band to let other people have their own slot if they need it(i.e. Emergency Comms which should be as reliable as possible).

It would be nice to have common settings for Reticulum, however this may not be easily achieveable as we don't have presets or defaults. Different communities may also have different needs.

However i say we should generally use the next slot below default Meshcore for Europe, just for convenience and ease of configuration.

So in this case 869.618 of Meshcore we substract 0.0625 which is a full slot of bandwidth 62.5 KHz we get 869.5555 MHz as center frequency.

Roughly this means for Reticulum:
center - 869.555
bandwidth - 62.5 KHz (0.0625 MHz)
used spectrum - 869.523 to 869.558

This means there are 2 free slots for 62.5 KHz bandwidth, which allows other similar projects to coexist with us and Meshcore.

Of course, coordinate local first, and only afterwards use global/default configuration if possible.

It would be nice if at some point we'll link our networks together.
I think i'll use this preset from now on for exactly this reason.

433.050–434.790 MHz is also worth considering, with 10% duty cycle and 10 mW ERP (in my country at least). While it can be very noisy some places, in other places it can be pretty quiet. It's a much wider band and the range is roughly the same (I've been told).

Anonymous wrote:

Anonymous wrote:

The issue is, that EU regulations are very strict and the only spectrum that allows even only 10% duty cycle and 27dbm is exactly where meshtastic and everyone else sits. The band is only 250mhz wide, so there is not much to choose if you want to stay in legal boundaries. You can try a narrow setting and split thr band in 2 or 4 parts. But you will always reveive all of the other traffic around you.

https://en.wikipedia.org/wiki/Short-range_device#SRD860

For reference here are the frequency 'slots' for Europe:

For 62,5 kHz

• 869.43125 MHz
• 869.49375 MHz
• 869.55625 MHz
• 869.61875 MHz

For 125 kHz:

• 869.4625 MHz
• 869.5875 MHz

For 250 kHz:

• 869.525

Meshcore in Europe mostly operates on 62,5/869.618. So if someone wanted to avoid them, you shoudn't use 62,5/869.618, 125/869.5875 and 250/869.525.

If I use a lower bandwidth but also decrease the spreading factor so that the bitrate is roughly the same, does that give me equivalent range and penetration characteristics as higher bandwidth and spreading factor. I'm currently using a bandwidth and frequency that interferes a little with meshcore because I wasn't correctly informed on the bandwidth setting actually worked. Also is there any differences in the bands or are they roughly the same (not counting if they are already being used)

https://reticulum.miraheze.org/wiki/LoRa_parameters

It's a mashup of text by Cleeyv, Nomad1n0 and Mark. Feel free to improve on it :)

Nomad1n0 wrote:

It would be nice to have common settings for Reticulum, however this may not be easily achieveable as we don't have presets or defaults. Different communities may also have different needs.

However i say we should generally use the next slot below default Meshcore for Europe, just for convenience and ease of configuration.

So in this case 869.618 of Meshcore we substract 0.0625 which is a full slot of bandwidth 62.5 KHz we get 869.5555 MHz as center frequency.

Roughly this means for Reticulum:
center - 869.555
bandwidth - 62.5 KHz (0.0625 MHz)
used spectrum - 869.523 to 869.558

This means there are 2 free slots for 62.5 KHz bandwidth, which allows other similar projects to coexist with us and Meshcore.

Of course, coordinate local first, and only afterwards use global/default configuration if possible.

It would be nice if at some point we'll link our networks together.
I think i'll use this preset from now on for exactly this reason.

I thought maybe its even better to leave out one narrow band as a buffer to avoid as much as possible from meshcore. And I dont see any reason to prefer the one band over the next one otherwise.

It's not really advisable due to 125 KHz bandwidth. So two slots of 62.5 equals one slot of 125. In this case slots 1 and 2 of 62.5 becomes slot 1 of 125. If you use slots 2 and 4 of 62.5, then you actually block both slots of 125(slot 2 of 62.5 blocks slot 1 of 125, while slot 4 blocks slot 2). If we use adjacent slots then we only block slot 2 of 125KHz, while slot 1 is still free if needed.

Makes sense I guess. That way I could still use the other 125 band without interfering with myself or meshcore. Thanks!

Nomad1n0 wrote:

It would be nice to have common settings for Reticulum, however this may not be easily achieveable as we don't have presets or defaults. Different communities may also have different needs.

However i say we should generally use the next slot below default Meshcore for Europe, just for convenience and ease of configuration.

So in this case 869.618 of Meshcore we substract 0.0625 which is a full slot of bandwidth 62.5 KHz we get 869.5555 MHz as center frequency.

Roughly this means for Reticulum:
center - 869.555
bandwidth - 62.5 KHz (0.0625 MHz)
used spectrum - 869.523 to 869.558

This means there are 2 free slots for 62.5 KHz bandwidth, which allows other similar projects to coexist with us and Meshcore.

Of course, coordinate local first, and only afterwards use global/default configuration if possible.

It would be nice if at some point we'll link our networks together.
I think i'll use this preset from now on for exactly this reason.

I really should add that there is a rounding error here. 869.618-62.5 = 869.555 but the actual center frequency used by meshcore is 869.61875 and that leads to the next available center frequency of 869.556.

I have it summarized here by a chatbot:

Exact (MHz)

Band width total: 869.400000 — 869.650000

869.400000 — 869.462500 (center 869.431250)
869.462500 — 869.525000 (center 869.493750)
869.525000 — 869.587500 (center 869.556250)
869.587500 — 869.650000 (center 869.618750)

Truncated to 3 decimals (MHz)

869.400 — 869.462 (center 869.431)
869.462 — 869.525 (center 869.493)
869.525 — 869.587 (center 869.556)
869.587 — 869.650 (center 869.618)

If you use 869.555 you WILL be touching the next band.

Yep, very good hint. My math was done plainly on the frequency in MC app, which is set to 869.618 with no additional decimals.
I did not check the code to see if it's actually using 869.618750, i just substracted from .618.

Good reason not to trust random stranger math on the internet i guess :)

Being so that Reticulum allows us to set at Hz level, we should actually set in our RNode configurations: frequency = 869556250
This is the actual center of Slot 3 objectively speaking, let the SW handle the rounding etc.