Platform
Cross-Platform
Description
Like many Meshtastic fans, I currently have a roof/attic node (CLIENT mode), plus one or more mobile nodes (CLIENT_MUTE or CLIENT) which are indoors and/or much less well positioned. The current modes and routing algorithm do not let me take advantage of my relatively strong roof/attic node.
Due to managed flooding SNR prioritization, my mobile node’s outgoing packets are usually picked up and rebroadcasted by a relatively weak (probably indoor) neighbor node elsewhere in my town, not by my much better-positioned base station.
Proposal: CLIENT_BASE mode (for attic/roof nodes)
I propose a new CLIENT_BASE mode, to be suggested for possible use on attic/roof nodes, with the following behavior:
- Acts as
ROUTER (early, guaranteed rebroadcast) for any packets where either p->from OR p->to are an is_favorite node.
- Acts as
CLIENT otherwise.
(Seriously, that's it.)
Super Easy Implementation
Adding this CLIENT_BASE mode requires:
- no extra firmware state
- no changes to packets
- very few lines of code
In fact, it might just be one extra else if condition in RadioInterface::getTxDelayMsecWeighted: 😄
|
if (config.device.role == meshtastic_Config_DeviceConfig_Role_ROUTER || |
Actually Uses Attic/Roof Nodes
With attic/roof nodes set to CLIENT_BASE, those stronger nodes will actually get used by the routing! This may encourage people to actually deploy more of these stronger nodes.
Improves Packet Delivery Reliability
Currently, packets from my relatively weak indoor node are most likely getting rebroadcast by some other relatively weak indoor node.
With CLIENT_BASE, messages sent from a weaker/indoor/mobile device will actually take advantage of their nearby attic/roof base station, which currently does not get utilized reliably or at all. This may significantly extend the range at which messages can be reliably exchanged in a single hop.
Falls Back Perfectly
When not near a CLIENT_BASE, the mobile CLIENT/CLIENT_MUTE just works as normal.
Congestion Neutral (maybe even negative!)
The change only applies to packets from/to a handful of personally favorited nodes. In fact, because the stronger CLIENT_BASE does an early rebroadcast, it can suppress (potentially multiple) later CLIENT rebroadcasts from weaker radios, since the strong CLIENT_BASE may be able to transmit much further.
In my current situation: there's currently one packet from my mobile node to some relatively weak/indoor neighbor node CLIENT which is not under my control, plus that node's rebroadcast (which doesn't go very far). Two packets total.
With CLIENT_BASE: there's one packet from my mobile node, which is then quickly rebroadcast (as ROUTER) by my stronger attic/roof node (set to CLIENT_BASE, with my mobile node as a favorite). This stronger rebroadcast will be received by my weak neighbor node and suppress its rebroadcast. So again: two packets total, but one is actually from a strong/well-placed station.
I’m open to writing a PR here. Looking for feedback as to whether this would be something the core team would consider, and whether other Meshtastic users might find it valuable. Thank you!
Platform
Cross-Platform
Description
Like many Meshtastic fans, I currently have a roof/attic node (
CLIENTmode), plus one or more mobile nodes (CLIENT_MUTEorCLIENT) which are indoors and/or much less well positioned. The current modes and routing algorithm do not let me take advantage of my relatively strong roof/attic node.Due to managed flooding SNR prioritization, my mobile node’s outgoing packets are usually picked up and rebroadcasted by a relatively weak (probably indoor) neighbor node elsewhere in my town, not by my much better-positioned base station.
Proposal:
CLIENT_BASEmode (for attic/roof nodes)I propose a new
CLIENT_BASEmode, to be suggested for possible use on attic/roof nodes, with the following behavior:ROUTER(early, guaranteed rebroadcast) for any packets where eitherp->fromORp->toare anis_favoritenode.CLIENTotherwise.(Seriously, that's it.)
Super Easy Implementation
Adding this
CLIENT_BASEmode requires:In fact, it might just be one extra
else ifcondition inRadioInterface::getTxDelayMsecWeighted: 😄firmware/src/mesh/RadioInterface.cpp
Line 325 in f31fd34
Actually Uses Attic/Roof Nodes
With attic/roof nodes set to
CLIENT_BASE, those stronger nodes will actually get used by the routing! This may encourage people to actually deploy more of these stronger nodes.Improves Packet Delivery Reliability
Currently, packets from my relatively weak indoor node are most likely getting rebroadcast by some other relatively weak indoor node.
With
CLIENT_BASE, messages sent from a weaker/indoor/mobile device will actually take advantage of their nearby attic/roof base station, which currently does not get utilized reliably or at all. This may significantly extend the range at which messages can be reliably exchanged in a single hop.Falls Back Perfectly
When not near a CLIENT_BASE, the mobile CLIENT/CLIENT_MUTE just works as normal.
Congestion Neutral (maybe even negative!)
The change only applies to packets from/to a handful of personally favorited nodes. In fact, because the stronger
CLIENT_BASEdoes an early rebroadcast, it can suppress (potentially multiple) laterCLIENTrebroadcasts from weaker radios, since the strongCLIENT_BASEmay be able to transmit much further.In my current situation: there's currently one packet from my mobile node to some relatively weak/indoor neighbor node
CLIENTwhich is not under my control, plus that node's rebroadcast (which doesn't go very far). Two packets total.With
CLIENT_BASE: there's one packet from my mobile node, which is then quickly rebroadcast (asROUTER) by my stronger attic/roof node (set toCLIENT_BASE, with my mobile node as a favorite). This stronger rebroadcast will be received by my weak neighbor node and suppress its rebroadcast. So again: two packets total, but one is actually from a strong/well-placed station.I’m open to writing a PR here. Looking for feedback as to whether this would be something the core team would consider, and whether other Meshtastic users might find it valuable. Thank you!