rns.recipes

EDIT: I just realized that this question might overlap slightly with the other unidirectional topic, but the problem is still there.

I have a practical topology question.

Currently I have three solar transport nodes with microReticulum firmware, with slight modifications so they run on xiao nrf52840. All three working in transport mode over LoRa only e.g. whatever they get on the lora interface, they re-emit it, following the reticulum logic and rules.

The frontier two nodes are on about 5km apart, however the connection is not stable, packets get lost etc. so I decided to put a middle transport node to make the connection more resilient. In Meshtastic world, this would help, however the Reticulum logic is different - all packets travel only according to the recorded routes (the least hop count route) and they don't just go on the most reliable radio route. Trouble is that one time the two frontier nodes see each other directly (thus saving the respective shorter route), and other times they don't, so the direct route is dropped and the extra hop transport route is recorded.

Ultimately I'd like to keep the longer - more reliable- route, but I have no control over this as occasionally the direct route with less hops is re-discovered and the routing tables are overridden with the less reliable route.

Is there something I'm missing, which would make such topology more stable?

Only thing I can think of is to lower the txpower so the 5km far nodes can't talk to each other at all but that's obviously not ideal

Only thing I can think of is to lower the txpower so the 5km far nodes can't talk to each other at all but that's obviously not ideal

Only thing I can think of is to lower the txpower so the 5km far nodes can't talk to each other at all but that's obviously not ideal

circfruit wrote:

EDIT: I just realized that this question might overlap slightly with the other unidirectional topic, but the problem is still there.

I have a practical topology question.

Currently I have three solar transport nodes with microReticulum firmware, with slight modifications so they run on xiao nrf52840. All three working in transport mode over LoRa only e.g. whatever they get on the lora interface, they re-emit it, following the reticulum logic and rules.

The frontier two nodes are on about 5km apart, however the connection is not stable, packets get lost etc. so I decided to put a middle transport node to make the connection more resilient. In Meshtastic world, this would help, however the Reticulum logic is different - all packets travel only according to the recorded routes (the least hop count route) and they don't just go on the most reliable radio route. Trouble is that one time the two frontier nodes see each other directly (thus saving the respective shorter route), and other times they don't, so the direct route is dropped and the extra hop transport route is recorded.

Ultimately I'd like to keep the longer - more reliable- route, but I have no control over this as occasionally the direct route with less hops is re-discovered and the routing tables are overridden with the less reliable route.

Is there something I'm missing, which would make such topology more stable?

Super fair concern, and yeah I think this falls right in with that other thread's conversation. Those changes proposed in that thread would apply to this case too. "Take the direct route" is right when the link is there, so that's still correct. But the issue is that sometimes it gets lossy; and it needs to quickly adapt in those moments to then use the 2-hop path. Thankfully the changes needed are quite minor and in the spirit of what Reticulum's already doing.

In other words, this is a solvable problem that's high on the radar right now and the solutions looks clear!

How much overhead would this create cause it sounds like we are doubling the amount of packets sent over the busy lora channel (granted the return packet is probabaly smaller)

welo wrote:

How much overhead would this create cause it sounds like we are doubling the amount of packets sent over the busy lora channel (granted the return packet is probabaly smaller)

Very little to none, actually. The work itself is already happening if you're using OPPORTUNISTIC or DIRECT lxmf messages (and you very likely are). This would purely improve the recovery and necessary re-adjustment of the network when things get lossy

Thanks for the feedback on this. I'm watching the other topic with interest. I've come up with temporary solution. I'll build a transparent lora repeater with basic packet dedupe buffer which would blindly re-transmit reticulum packets, thus extending the range. Not ideal, but would work until a protocol solution is adopted.