RNS Logo

rns.recipes

◈ 9ce92808be498e9e05590ff27cbfdfe4
RNS 1.5.5 released https://pypi.org/project/rns/

How to Choose RNode LoRa Parameters

LoRa RNode

Started by Cleeyv 0b91c6bd3f4e6eda... ·

Anonymous
#21

I actually didnt mean to say that meshcore is using 869.618750, just that the logic behind why they use 869.618 is that the band is split in 4 parts and each center frequencies are then truncated to 3 digits. And if you use a different logic to split it it could result in bands touching.

I am not sure if its a good idea to use the exact center frequency though. Maybe its better to do the rounding beforehand so we are certain that we use the same frequency ^^ I think not all hardware is capable of using more then 3 decimals.

Anonymous
#22

Hm, on the other hand, using those truncated center frequencies with a 62,5khz bandwith also sounds problematic. They would overlap again if the chip actually uses 62.5 and not 62khz.

RandomPeer 5fb3b0b848f8b259...
#23

Well i see the parallel to driving here. If we have 4 lanes, then the user can use any lane, or in-between if the road is empty, no issues with that. But there is traffic so when this happens we each try to stay in our own lane. If a car is designed such that it can't use one lane and it's offcenter, making a mess on 2 lanes at once, then it's the car manufacturer design and responsibility to be decent.

RandomPeer 5fb3b0b848f8b259...
#24

In other words, if the Application doesn't support such granularity, then the devs should fix it. If the HW supports centering it right, then SW should be implemented as such. Else the mess cascades into ruining the fun for everyone.

RandomPeer 5fb3b0b848f8b259...
#25

If the HW does not support this, then yeah it's unfortunate and we do what we can. The user resonsibility should end at choosong the lane reaponsibly and use more bands only when he's sure there is no other traffic on the other lanes.

Anonymous
#26

Guess it makes sense. I will test if its still interoperable (truncated and exact frequency) if yes it would totally make sense to use the exact frequency.

Anonymous
#27

I think that the hardware most are using is also way more inaccurate than we think, and probably the frequencies are way more off in practice then the bits we are discussing here 😅

Anonymous
#28

Anonymous wrote:

Guess it makes sense. I will test if its still interoperable (truncated and exact frequency) if yes it would totally make sense to use the exact frequency.

Reporting back, this works. An RNode with 869556250 and another one with 869556000 had no issues sending data (tested in the same room). So I think its ok to use the exact frequency.

Anonymous
#29

That makes sense, but also lets me a bit confused about what is now the "best" setting for not interfering with meshcore? (I don't really care about meshtastic here, because it seems at least for my region, that everyone migrated towards meshcore...) According to https://reticulum.miraheze.org/wiki/Popular_RNode_settings - there still are many "popular" settings out there in EU. So... 869.49375, SF 8 and BW 62.5 should be fine then to avoid mehscore interference?

Nomad1n0 c0d738c95b4d0dba...
#30

As a complete overview:
It depends, mainly on what you want out of your LoRa network.
Reliability, speed, range etc. are all situational requirements.
Lower BW means more range, but less speed. So 62.5 BW will reach further than 125, however it'll have slower speeds. Also lower BW means more channels/bands, as they use less frequency range.

 

MC uses 62.5 which allow 4 bands on Europe legal frequency range(idk about other places).
MC uses band 4, the last one, centered on 869.618(roughly rounded, should be actually 869.61875 which is closer to 619 actually).

 

To avoid MC interference, one should use one of the other 3 bands, or use 125 by centering on the first band of 2(for BW 125 you have 2 bands in total).
I.e., i'm using 869.556250 which is the center for band 3, just below MeshCore band. In theory they should not overlap if both systems are centered correctly.

 

Best settings are volatile, so to wrap it up to avoid MC you need to not transmit in this frequency range: 869.58675–869.64925 MHz.
Keep in mind that MeshCore may use different slots as well, even tho Narrow is the most common and widely adopted.

Post a Reply

Supports Markdown: **bold**, *italic*, `code`, ```code blocks```, [links](url)

Log in to upload images

Quote
Copied to clipboard