No More Hop Limits: What if Every Hop Cost Just 1 TX Instead of n? #9936
Replies: 36 comments 12 replies
-
not anymore ... I do not agree with it, but in any case, it seems that in firmware 2.7.20, scaling does not apply anymore for ROUTER_LATE and other device roles #9818 I don't know why that is ... my only explanation is: comfortable US frequency slot / number of slots situation and disregard for situation in other areas of the world in terms of LoRa. It'd be nice if there were feature gates for stuff like 0-cost routing (was suggested once by @GUVWAF) and exemptions to scaling .. gating those features to short presets only or to any region except EU_868 ... but it is as it is. |
Beta Was this translation helpful? Give feedback.
-
|
ROUTER_LATE should be taking on the course-grained interval miniums ROUTER had previously. I will double check that though, because if not, this is a missed spot. |
Beta Was this translation helpful? Give feedback.
-
|
cool, thank you very much, @thebentern do you mean those defaults for IF_ROUTER https://github.com/meshtastic/firmware/blob/master/src/mesh/Default.h#L17 and those applying, or not yet applying, to ROUTER_LATE? I think @h3lix1 fixed this in https://github.com/meshtastic/firmware/pull/9815/changes It is good to see that, despite not scaling up the intervals even more, at least those two roles have very course default intervals of a day / half a day. It's be good if, for certain regions like EU_868 with mostly one frequency slot https://meshtastic.org/docs/overview/radio-settings/#frequency-slot-calculator only and for non-short presets, there were feature gates for the exemptions, even for ROUTER and ROUTER_LATE, but especially so for certain sensor / tracker roles. Lastly, thank you for your great work in the project, we appreciate it very much. As mentioned ... we've just got different regulatory and frequency slot situation contexts 'round here. Most of our EU_868 presets work on frequency 869.525 Mhz and to add to it, _TURBO presets with 500 kHz bandwidth are not allowed, either. Still .. we like Meshtastic and the spirit of your project and do our best here to work within our constraints. Cheerio / have a good day. |
Beta Was this translation helpful? Give feedback.
-
|
Suggested labels: Keywords for discoverability: range extension, performance, scalability, bandwidth efficiency, hop limit |
Beta Was this translation helpful? Give feedback.
-
Update: Realistic Hop Limits Reveal Delivery CollapseThe original simulation used TTL=30, which masked a critical problem. With Meshtastic's actual hop limits (3, 5, 7), managed flooding's delivery rate collapses at scale:
Key InsightThe hop limit is not just a range cap — it is a delivery ceiling. At 1000+ nodes, managed flooding delivers fewer than 1 in 10 messages regardless of hop limit setting. System 5 delivers 7.5x more messages with fewer total transmissions. This means the current routing doesn't just waste bandwidth — it fails to deliver in the exact scenarios where mesh networking matters most (large, spread-out, disaster relief). Updated demo and results: https://clemenssimon.github.io/MeshRoute/ |
Beta Was this translation helpful? Give feedback.
-
that'd be awesome and a real differentiator from MeshCore
Would not call it a GPS requirement. More a position info requirement. At least for major mountain role CLIENT, ROUTER_LATE nodes, we already use coordinates / position info. A little fuzzied out in terms of precision, and at times also just manually input as fixed coordinates when no GPS module is present or when activating it would take too much energy consumption. Personally, I'be be fine with taking into account position information of nodes. |
Beta Was this translation helpful? Give feedback.
-
|
My question with System 5 is how does it work with asyncronous paths? It looks clean in a simulated setup like this, but as paths change there is an increase of out of order messaging. (i.e. messages sent A B C can be received C B A if sent via 3 different paths), and meshtastic doesn't really do a good job of keeping sequence in the app like TCP does. The second part is async routing - the path back can vary greatly from the path sent. The path to get to a mountain top router might take 3 hops, but the path back is a single hop. Trying to route the traffic back through the same 3 hops to get to the destination really isn't efficient. For bay mesh, the best way to describe it is that the flood routing mesh all happens above 2000 feet. The challenge we see today with chutil is that for 5% actual utilization, the router mountain nodes hear about 10 different roof nodes sending packets at the same time, 4 more other long distance router nodes, etc. The result is a mess of collisions that result in 5% utilization turning into 50% utilization. Let's take for example, SUNL - my node in the bay area. 
The challenge is all the clients repeating packets cause a mess at high altitudes. We try our best to remove this by having enough routers to make sure most clients hear each message at least twice (supressing responses), but that itself also causes higher utilization. It would be interesting to see more simulations where a single node can send to 100 nodes, but only hears 10. Where the circles for mountain top nodes can send far and wide (30+ miles) to other mountain top nodes and be heard by those mountain top nodes, but can also hear hliltop nodes.. and then those hilltop/roof nodes hear both valley nodes and in-building nodes. The fun part is the mountain nodes also have a good chance of sending traffic directly to the valley and in-building nodes without needing the hilltop or roof nodes at all. Keep in mind, while the hilltop and roof nodes are sending, the mountain nodes are blocked from sending. Somehow this also needs to be added to the simulation to get past the real crux of the issue, which is half-duplex communication means the inability to send due to listening to a bunch of other nodes sending. It also doesn't really solve the problem of how a client knows it missed a message. For example, in your example "How the Network Builds Itself", when it gets to the "load balancing" part, there is only one path that works, A-C-F-L-M-K-O. It's not very load balanced, but it also means there are 3 nodes that all make a path of failure. If any of those 3 nodes fails due to intermittent issues, the message will not be received. Lastly, routing tables require memory. Some vendors are moving to using nrf52 devices for 1 watt nodes, and many love using solar nodes (also, nrf52) as routers. Many of these nodes can only hold 80-100 nodes in the nodedb. What is the memory expectation for something like this with 1000-10000 nodes? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @h3lix1, Thank you for the detailed feedback! Your questions about half-duplex blocking at SUNL, out-of-order messaging, and What Your Feedback Built Half-Duplex Model — You said: "mountaintop nodes are blocked from sending." Node Silencing — You said: "clients repeating packets at high elevations cause a mess." Sequence Numbers — You said: "messages A B C can be received C B A." Emergency Re-Route — You said: "only one path works, 3 single points of failure." Bay Area 3-Tier Topology — You said: "mountaintop routers hear 10 rooftop nodes simultaneously." For the technical deep-dive, see https://clemenssimon.github.io/MeshRoute/how-it-works.html — sections on Bay Area Results (235 nodes, half-duplex) Delivery Rate 6.0% 77.5% 74.5% Key finding: Half-duplex collapses managed flooding from 87.5% to 6% delivery — your SUNL problem exactly. Mountaintop Your Questions — Quick Answers
Try It
Your feedback genuinely made this better. The half-duplex insight alone was worth the entire conversation — it |
Beta Was this translation helpful? Give feedback.
-
|
This seems good for unicast, and potentially could be accomplished with bloom filters, but meshtastic is currently 98% broadcast traffic for us - all nodes should receive the same message. (For example, position packets, nodeinfo packets, telemetry packets) for the simulators I can only see examples for unicast messaging. Is there an example of messaging that is broadcast to all nodes? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thank you @h3lix1 for also having documented this, bloom filter concept, back then on Github. @ClemensSimon FYI #8592 Also, have a look at this comment back then on how to improve things by @fifieldt #6199 (reply in thread) He said in answer to someone from Seattle WA Puget sound area (similar in terms of lateral valleys, high elevation mountains) regarding regional aspects / regions clustering and a mix of Autobahn style directed routing from key location to key location, e.g. mountain to mountain vs. normal flood routing for regional distribution:
Big thanks from me, too, to @ClemensSimon for the new ideas and trains of thought. |
Beta Was this translation helpful? Give feedback.
-
|
▎ Hey @h3lix1, ▎ Good question — but I want to make sure I understand the requirement correctly. ▎ You say 98% of traffic is broadcast. But broadcast to whom exactly? If there's no hop limit anymore, does that mean ▎ Could you help me understand the intent behind these broadcasts? ▎ - Position/Telemetry: Does every node really need to know the position of every other node? Or is it more like ▎ Right now the simulator handles unicast (point-to-point) and managed flood (full broadcast). If the real need is |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ClemensSimon - Most of the state in Meshtastic (nodedb entries, etc) are push-based braodcast messages. This includes position packets, nodeinfo packets, telemetry packets, and channel messages. The only things unicast today are DMs and traceroute packets. There are also a few on-demand information gathering that a node can do, but the majority of the time things are flood routed. There could be a push in future to instead do pull-based information gathering instead of push-based as it is today, but it almost all messages are network-wide. The channels aren't split into locality today (i..e. "Bay Area") but just the default channel "MediumFast" for example. I could see a world where channels are more localized, but it's not configured that way today. I can't seem to find how system 5 will handle the flood option (if there is an option to do flood routing with a system 5 configuration) I do appreciate the effort here though - if we can crack how to make flood routing with as little airtime as possible, we might be on to something. |
Beta Was this translation helpful? Give feedback.
-
|
Draft Response to @h3lix1 and @shalberd — Broadcast Routing in System 5
Thank you for the clarity on the 98% broadcast reality — that's the critical piece I needed. You're right that System 5 as demonstrated primarily optimizes unicast. Let me lay out how the architecture can handle broadcast traffic, and where @h3lix1's Bloom Filter idea fits in. The Broadcast Problem, PreciselyIn a 235-node Bay Area mesh with managed flooding:
The question isn't "should every node hear every position?" — it's "can we deliver the same broadcast reach with fewer TX?" Three Approaches That Could Work Together1. Cluster-Scoped Broadcast (System 5 native)System 5 already has geo-clusters. Use them for broadcast scope:
For Bay Area (7 mountain + 35 hill + 193 valley):
2. Bloom Filter Hybrid (@h3lix1's RBF from #8592)Your Bloom Filter approach and System 5 are complementary:
Combined: Border nodes carry a Bloom filter in the broadcast packet. When relaying to the next cluster, nodes already in the filter don't rebroadcast. This handles the overlap zones where clusters share radio range. The 11-35 byte filter cost is negligible vs. saving dozens of redundant TX at cluster boundaries. 3. @fifieldt's Interior/Exterior Split — Already Built@shalberd, great catch. System 5's geo-clustering is the interior/exterior split that @fifieldt described:
The only missing piece is applying this to broadcast traffic, not just unicast. The cluster infrastructure is already there. What I'll Build Next
Honest Limitations
Would this address your use case? Specifically: if position/telemetry packets reached all nodes within ~5-10 seconds instead of ~1-3 seconds, but used 90% less airtime — would that tradeoff work for Bay Mesh? — Clemens |
Beta Was this translation helpful? Give feedback.
-
|
Your feedback on broadcast traffic being 98% of Meshtastic's workload was the key insight I was missing. I've now implemented and benchmarked a broadcast-specific routing mode that directly addresses this. The Problem You IdentifiedSystem 5 optimized unicast brilliantly (1 TX per hop), but had no answer for broadcast packets (position, nodeinfo, telemetry, channel messages). Managed flooding costs O(n) per broadcast. For Bay Area's 235 nodes, that's 4,301 TX per single position packet. Solution: Cluster-Distributor BroadcastInstead of flooding the entire network, broadcast propagates as a wave through clusters:
This is essentially @fifieldt's interior/exterior routing concept -- interior = flood within cluster, exterior = directed relay between clusters. Key Design DecisionsValley nodes as distributors, not mountain nodes. A mountaintop node broadcasting reaches 10+ clusters simultaneously, causing a collision storm (your SUNL problem exactly). A valley node broadcasting stays contained by terrain -- only its cluster hears it. The distributor election scores: Where valley nodes score ~1.0 and mountain nodes score ~0.1. Mountain nodes receive but don't relay. During intra-cluster mini-flood, mountain nodes hear the broadcast (they hear everything) but don't rebroadcast -- their TX range is too large and would leak to other clusters. They're passive receivers, not active relays. Natural signal spillover is free. When a valley distributor floods its cluster, nearby nodes in adjacent clusters often hear it too -- counted as reached with zero extra TX cost. Benchmark ResultsTested with 20 broadcasts per scenario, averaged:
Bay Area: 96% reach with 95% fewer transmissions -- and 6% MORE reach than managed flooding, because directed routing avoids the collision cascades that kill flooding at scale. What This Means for Real TrafficIf 100 nodes each send position every 15 minutes:
That's the difference between network congestion collapse and comfortable headroom. Bloom Filter Integration@h3lix1 your Bloom Filter approach from #8592 fits naturally at the cluster boundaries. When a border node relays to the next cluster, it can carry an RBF of which nodes already received the broadcast. The next cluster's distributor checks the filter before relaying to nodes that might already have it from signal spillover. This would reduce the remaining redundancy even further. Honest About Limitations
Try ItThe live simulator lets you compare all routing approaches side-by-side. Select any scenario including "Bay Area Mesh" and step through hop-by-hop. Source code: simulator/routing.py -- classes Your question "if we can crack how to make flood routing with as little airtime as possible, we might be on to something" -- I think this is that something. The trick is: don't flood the whole network. Flood small clusters, relay between them. -- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
Since this is clearly AI-generated, I'll feel free, too:
Btw. the simulator doesn't do anything when I open the page |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed review -- these are valid engineering concerns that deserve concrete answers. I'll go point by point. Re: "clearly AI-generated" -- yes, Claude helped with the writeup and the simulator code. The routing concepts and the constraints analysis are mine though. Speaking of which: Simulator fixThe simulator was broken due to orphaned code fragments from a bad file split (leftover lines from roundRect polyfill in 1. Non-local information requirementsFair point, but the critique assumes more global knowledge than the design requires. The weight formula NHS is not a global aggregate -- it's a local average of what a node sees from its direct neighbors' OGMs. An 8-node cluster doesn't need extra polling; the OGMs that maintain neighbor tables already carry this data. Where you're right: "path-wide" battery and load awareness (across multiple hops) is not feasible on LoRa. The implementation should evaluate only the next hop, not the full path. I'll clarify this in the proposal. 2. Memory constraintsThe math is correct but the assumptions are worst-case:
Realistic calculation: 2 routes x 35 destinations x 20 bytes = 1.4 KB. Plus neighbor table (16 x 20B = 320B) and cluster metadata (~200B). Total: ~2 KB -- fits comfortably in nRF52 RAM. You're right that explicit memory budgets should be in the proposal. I'll add a table. 3. Compute overheadBFS on a 30-node cluster with ~100 edges is ~130 operations -- microseconds on a 64 MHz Cortex-M4. Even 3x per destination for 35 destinations = ~14,000 operations, well under 1ms. But more importantly: BFS doesn't need to run on the node at all. Routes are built incrementally via distance-vector updates (like RIP/AODV): when a neighbor's OGM says "I can reach node X in 3 hops with quality 0.8", the node updates one table entry. That's a single comparison + write, not a graph traversal. Route decay ( I should describe the routing table mechanism as distance-vector rather than BFS in the proposal. The simulator uses BFS for clarity, but a real implementation wouldn't. 4. Radio / airtime -- this is the strongest objectionYour math is correct for the naive case: 100 nodes x 1 OGM/30s x 500ms-2s airtime = channel saturation. But OGMs don't flood globally in System 5. They stay cluster-local (1 hop only):
Still, I acknowledge this needs more work:
The retry concern (3-5 per hop x 3-5 hops) is valid but less severe than it sounds: System 5 sends unicast (1 TX per hop), not broadcast. Total airtime for a 5-hop message with 2 retries = ~15 TX. Managed flooding for the same message: hundreds of TX. The per-message efficiency is real even with retries. 5. Topology propagationSystem 5 does not require multi-hop topology knowledge. Each node knows:
The "16 extra entries" for routing across 3 clusters is correct and trivial: 16 x 20B = 320 bytes. Propagation cost: ~2-4 border summary messages per cluster-pair per 30s cycle. What's missing from the proposal is an explicit diagram showing what data lives where and how it propagates. I'll add that. Summary of what I'll improve based on your feedback:
Good feedback overall. The airtime point is the one that needs the most engineering work before this could be real. |
Beta Was this translation helpful? Give feedback.
-
|
Quick update -- based on @korbinianbauer's feedback (and your earlier points about broadcast traffic being 98% of the network), I've made significant revisions to the proposal and the documentation: What changed1. Distance-Vector instead of BFS 2. Next-hop metrics only 3. Adaptive OGM interval 4. Cluster-Distributor Broadcast (new -- directly from @h3lix1's point about 98% broadcast traffic)
Results: Bay Area (235 nodes): 4,301 TX with managed flooding vs 220 TX with cluster-distributor = 95% savings. Regional (500 nodes): 95,869 vs 517 TX = 99.5% savings. 5. Simulator fixed @h3lix1 -- re: your Bay Area concernsThe broadcast routing directly addresses your point about position/nodeinfo/telemetry dominating traffic. With cluster-distributors, a position beacon from one node costs ~30 TX to reach the whole 235-node Bay Area mesh, instead of ~4,000 TX with flooding. The half-duplex mountaintop blocking issue is also less severe because the distributor model generates far fewer simultaneous transmissions. Out-of-order delivery (your A-B-C -> C-B-A concern) is handled by the 2-byte sequence counter in the packet header. Gap detection is cheap and doesn't add TX overhead. @shalberd -- re: EU868 and GPSThe adaptive OGM interval now explicitly accounts for EU868's 1% duty cycle. At 60s intervals (moderate density), a node uses ~0.8% of its duty budget for maintenance traffic. The airtime budget table is in the updated How It Works page. GPS remains a soft requirement -- nodes without GPS can use pre-set coordinates or inherit cluster assignment from a GPS-capable neighbor. All changes are live on the site. The How It Works page has the full technical details including the new broadcast section. |
Beta Was this translation helpful? Give feedback.
-
They may not flood beyond 1 hop, but that doesn't mean they just stop at the borders of your geo-cluster. Every node in range or even slightly beyond it will detect a busy channel and cannot use this airtime. |
Beta Was this translation helpful? Give feedback.
-
correct, we get 60-80 km range for a hop in every direction on preset MEDIUM_FAST. |
Beta Was this translation helpful? Give feedback.
-
The 60-80km Elephant: Why Geo-Clusters Can't Be Radio-Isolated@korbinianbauer and @shalberd -- you're absolutely right, and this is the most important feedback so far. Let me address it head-on. The core problem: At MEDIUM_FAST, a single OGM "meant" for a 5km cluster occupies the channel for every node within 60-80km. Geographic clustering provides logical isolation but zero radio isolation. The airtime cost is real regardless of the intended scope. I've been thinking about this since your comments, and I see three viable paths forward: 1. Power-Controlled Routing Packets 2. Connectivity-Based Clustering Instead of Geo-Clustering 3. Piggyback Routing on Existing Traffic My honest assessment: Option 3 (piggybacking) combined with Option 2 (connectivity-based clusters) is probably the most realistic path. It adds zero airtime overhead, works within existing packet structures, and doesn't require hardware-level changes. The 60-80km range actually helps here -- it means a node's natural radio neighborhood IS a meaningful routing cluster. I'll update the simulator to model connectivity-based clustering with piggybacked routing metadata and post results. The key metric will be: how much routing convergence time do we sacrifice vs. dedicated OGMs, and is the delivery rate still acceptable? Updated airtime budget analysis for EU868 coming as well -- with explicit accounting for the shared channel problem you've identified. |
Beta Was this translation helpful? Give feedback.
-
|
@h3lix1 -- What is your opinion? |
Beta Was this translation helpful? Give feedback.
-
|
Update: Independent validation with Meshtasticator I implemented System V6 as a router module in the official Meshtasticator simulator — same radio model, same MAC layer, same collision detection as Managed Flood. Apples-to-apples comparison. Full benchmark: 18 simulations (20/50/80 nodes x 3/5/7 hop limits x MF/V6), 1h each, 30s message interval. Code and results: ClemensSimon/Meshtasticator (system-v6 branch) The key finding — V6 breaks the hop limit:
V6 with 7 hops costs less than Managed Flood with 3 hops. The hop limit exists because flooding generates O(n) transmissions per hop. V6 suppresses redundant rebroadcasts through passive route learning, so more hops do not cause congestion collapse. TX reduction across all scenarios: 29-40%. Learning effect is visible in time-series — V6 starts identical to Managed Flood and improves within the first 5 minutes as it learns which neighbors are good relays. Anyone can reproduce this: git clone -b system-v6 https://github.com/ClemensSimon/Meshtasticator.git
cd Meshtasticator
pip install -r requirements.txt
python loraMesh.py 50 --router-type SYSTEM_V6 --no-gui
# or run the full benchmark:
python v6_parallel_bench.py-- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so in a real mesh, or at least the ones that run modern firmware and don't take place at events, messages are much more sparse, and RF conditions change frequently. I will post a little list I use to check whether an algorithm has any chance a bit later on, but for this, does it pass the "mixed new and established node" test? |
Beta Was this translation helpful? Give feedback.
-
|
Update 2: Improved V6 with deferred rebroadcast + TX power control After analyzing why Meshtasticator results differ from my own simulator (LoRa is broadcast, not directed — every TX is heard by all nodes in range), I added three improvements:
Complete results (80 nodes, 1h sim, 30s msg interval):
The hop limit argument still holds: V6 at 7 hops = same TX as MF at 3 hops, with comparable reach and fewer collisions. At 5 hops, the collision reduction is most dramatic: -35% collisions with 11% fewer TX. Honest assessment: My own MeshRoute simulator overstates the advantage because it models "directed send" as 1 TX to a specific neighbor. On real LoRa, every TX is a broadcast. The realistic benefit of V6 is intelligent suppression — 10-35% fewer TX and up to 35% fewer collisions — not 97%. But this is enough to safely raise the hop limit, which was the original goal. Code: ClemensSimon/Meshtasticator system-v6 branch -- Clemens |
Beta Was this translation helpful? Give feedback.
-
This is an interesting idea - an extension of the managed flooding, but checking if I am being helpful. Unfortunately your reverse-contention method will black hole packets close to the origin.
We've looked at this, but RSSI is difficult to gauge and SNR is a better measure of "who can hear me". It's certainly worth revisiting to see if a modest threshold might help.
Again, snr doesn't always go down with rssi (and certainly doesn't go up with it either!), and moving nodes can quickly drop away. Worth investigating, perhaps. |
Beta Was this translation helpful? Give feedback.
-
|
Update 3: MPR + ECHO backbone — 57-61% fewer transmissions Two new mechanisms based on established protocols (OLSR MPR + goTenna ECHO): 1. MPR (Multi-Point Relay): Each node computes a minimal set of relay neighbors from passively learned 2-hop topology. Only designated MPRs rebroadcast. Topology analysis shows: average node has 10.5 neighbors, but only 3.1 MPRs needed for full 2-hop coverage — 71% of relayers are redundant. 2. ECHO backbone detection: After rebroadcasting, a node listens for 5 seconds. If a downstream node relays the same packet ("echo"), this node is on the broadcast backbone. If consistently no echoes → node is a leaf or redundant → stops rebroadcasting. Self-organizing, no control packets needed. Both mechanisms learn entirely from overheard traffic — zero extra airtime. Results (Meshtasticator, 30min sim, 30s message interval):
The hop limit argument is now overwhelming: V6 at 7 hops costs less than half of MF at 3 hops, with comparable reach. Evolution of V6 improvements in Meshtasticator:
All code reproducible: system-v6 branch git clone -b system-v6 https://github.com/ClemensSimon/Meshtasticator.git
cd Meshtasticator
pip install -r requirements.txt
python loraMesh.py 50 --router-type SYSTEM_V6 --no-gui-- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
How long does MPR take to learn, and how quickly can it recognise a change in performance? What triggers an echo node to restart broadcasting? |
Beta Was this translation helpful? Give feedback.
-
|
My generic checklist for seeing what will break new ideas is as follows: Checklist:
Explanation: RF conditions can change rapidly, and not always just in a temporary traffic lights-induced "zone of silence". Tropospheric lifts can mean messages propagate much further than expected. Events are assumed to be using "event mode", but what if they don't? What if people just forget to put it in eventually mode? And how will a new algorithm work in event mode? There are long range extended meshes in use. How do they stack up? |
Beta Was this translation helpful? Give feedback.
-
|
Update 4: Genetic Algorithm finds optimal V6 parameters — 56% TX, 55% collision reduction I made all V6 parameters configurable (12 parameters: route expiry, echo timeout, gossip probability, MPR interval, etc.) and ran a genetic algorithm to evolve the optimal configuration. GA setup: 8 generations, 10 individuals, fitness = TX_reduction * 2 + reach_ratio * 50 + collision_reduction * 0.5 Best genome found:
Result: 56% fewer TX, 55% fewer collisions (30 nodes, 15min sim, hop limit 3). The most surprising finding: route expiry of 30 seconds. The GA converged on aggressive forgetting — stale routes from 5 minutes ago are worse than no routes at all. Fresh passive learning from each new packet outperforms cached topology. This also naturally solves the resilience issues (node failure, partition recovery, mobile nodes) identified in the security analysis. Also implemented:
Full code + GA results: system-v6 branch # Run GA yourself:
python v6_evolve.py --generations 15 --population 10 --nodes 50
# Or use the best genome directly:
python v6_run_one.py 50 SYSTEM_V6 3 3600 30 ga_results/best_genome.json-- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
Update 5: Your robustness checklist — honest results @NomDeTom, I ran your exact checklist through Meshtasticator. Here are the results, including the failures:
What breaks:
What works well:
Fix needed: V6 should detect sparse networks (few neighbors) and automatically reduce suppression aggressiveness — fall back toward managed flooding when the network is too thin for MPR to work safely. I will implement this as a density-adaptive mode. Test code: -- Clemens |
Beta Was this translation helpful? Give feedback.
-
I think you/Clod has got that wrong. Managed flooding specifically prevents this. Pure flooding does this, though. Can you title the different scenarios? MF is managed flooding? What is the number - hops reached? hops required? Remember that going forward with "polite hops" for telemetry, most people will turn their hopstart up to 7 and leave it there. |
Beta Was this translation helpful? Give feedback.
-
|
Update 6: Security hardening — HMAC + Watchdog, resilient to 30% malicious nodes Two security mechanisms added, addressing the top threats from the roadmap: 1. HMAC Route Authentication 2. Watchdog Blackhole Detection Security test (30 nodes, varying % of malicious nodes):
Reach stays within 2-4pp of baseline even with 30% of nodes being malicious. Without HMAC, 30% malicious nodes would corrupt every route table in the mesh. Also fixed since last update:
Full V6 feature set now:
All code: system-v6 branch -- Clemens |
Beta Was this translation helpful? Give feedback.
-
Yeah, that's going to take some work to make work correctly. Packets over ~160 bytes start to drop in reliability pretty quick. |
Beta Was this translation helpful? Give feedback.
-
|
Update 7: Final stress tests — all 5 scenarios pass, V6 reach exceeds MF in 3 of 5 After adding channel-utilization adaptive suppression (#12), here are the final results across all of @NomDeTom's robustness checklist scenarios:
V6 reach exceeds managed flood in 3 of 5 scenarios (moving mesh, dense event, and previously in standard benchmarks with XOR coding). The sparse mountain scenario was the hardest to fix — it went from -34pp reach (broken) to -2.9pp (acceptable) through density-adaptive suppression. V6 now detects thin meshes and automatically reduces suppression aggressiveness. 12 mechanisms now active, all working together: No scenario breaks V6. No scenario shows V6 TX higher than MF. The worst reach delta is -5.2pp (linear chain) which is within acceptable range for 43% TX savings. Full code reproducible: system-v6 branch -- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
Update 8: Full stack — 15 mechanisms, container aggregation, fountain codes Added three more optimizations since last update: PHY-layer (mechanisms #12-14):
Data-layer (mechanism #15):
Final stress tests (all 15 mechanisms active):
V6 now has 15 active mechanisms across routing, security, PHY, and data layers. No scenario breaks it. In sparse networks, V6 reach exceeds MF by 15 percentage points. The full optimization stack:
Code: system-v6 branch -- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
Update 9: GA re-optimized with full 15-mechanism stack — all stress tests pass Re-ran the genetic algorithm with all 15 mechanisms active (including container aggregation, PHY optimizations). Key finding: the GA parameters must be tuned for robustness across ALL scenarios, not just one. GA v2 found parameters that maximized TX reduction in standard benchmarks (34% TX, 63% collision reduction) but broke sparse and linear scenarios. The fix: restored the GA v1 genome (30s route expiry, 26% gossip) which is robust everywhere, and raised the aggregation threshold to 8+ neighbors so sparse networks skip aggregation entirely. Final stress test results (GA-optimized, all 15 mechanisms):
V6 reach exceeds managed flood in 3 of 5 scenarios. No scenario has >10pp reach loss. Collision reduction up to 54%. The GA taught us something important about aggregation: it only helps in dense networks (8+ neighbors). In sparse networks, the 5-second collection window delays packets without benefit. The density-adaptive threshold ensures V6 never aggregates when it would hurt. All code on system-v6 branch. Anyone can reproduce: git clone -b system-v6 https://github.com/ClemensSimon/Meshtasticator.git
cd Meshtasticator
pip install -r requirements.txt
python v6_stress_test.py # NomDeTom checklist
python v6_evolve.py --generations 12 --population 8 --nodes 30 # GA-- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
Summary: What System V6 achieved today This started with @NomDeTom asking to see the mesh self-organize from a base start. That question led to a full day of building, testing, breaking, and fixing. Here is what exists now. What was builtMeshRoute Simulator (live demo):
Meshtasticator integration (system-v6 branch): 15 mechanisms, three layersRouting layer (9 mechanisms):
Security layer (2 mechanisms): PHY layer (3 mechanisms): Data layer (1 mechanism): ResultsValidated on @NomDeTom's robustness checklist:
V6 reach exceeds managed flood in 3 of 5 scenarios. No scenario breaks. The worst reach delta is -6.3pp (sparse) which is acceptable for 23% TX savings and 42% fewer collisions. What we learned
What's nextThe roadmap has the full picture. The biggest remaining wins are:
All code is MIT licensed and reproducible: git clone -b system-v6 https://github.com/ClemensSimon/Meshtasticator.git
cd Meshtasticator
pip install -r requirements.txt
python v6_stress_test.pyThank you @NomDeTom for the robustness checklist, @h3lix1 for killing System 5 (which led to something better), @korbinianbauer for the engineering review, and @shalberd for the EU868 perspective. -- Clemens, Bavaria |
Beta Was this translation helpful? Give feedback.
-
|
I've responded to some of your points further up, but I'll sum up my reaction to the mechanisms you raise here:
This is in quick succession - the suppression wears off after 30s or so? With reduced packet traffic with more recent releases, that will go down further.
Again, the suppression wears off after 30s or so?
Not sure why it's referred to as XOR - does this mean appending packets? I'm in favour of some possible consolidation, but I'm unsure how it can be achieved without breaking something.
Not sure on this one - how is authentication achieved? Manually? Automatically? From where?
How do they adapt? Different SF are mutually incompatible.
Not sure on this one - this removes the option to adjust CR.
Not sure on this one - will it reduce RX chances?
Delta compression is awful - our links are not and will never be reliable enough to achieve this. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @NomDeTom, Thank you for the detailed feedback — your robustness checklist and technical critiques were exactly what this needed. I took every point seriously, did an ABC analysis against real LoRa physics, and implemented fixes. Here's where things stand. Your checklist: 5/5 scenarios testedI ran all five scenarios from your checklist through Meshtasticator (not my own simulator — apples-to-apples against Managed Flood):
V6 reach >= MF reach in all five. The sparse scenario was the hardest — it took three iterations to get right (see below). What I changed based on your feedbackSNR instead of RSSI for relay selectionYou were right — RSSI is unreliable for LoRa. I replaced the link quality model with an SNR-based sigmoid using SF-specific demodulation thresholds. LoRa demodulates at -20 dB SNR on SF12 — RSSI-based quality completely misjudges links near this floor. Deferred rebroadcast: fixed the black holeYou identified that reverse contention (close nodes rebroadcast first) creates a black hole near the origin. I inverted it: far nodes get short delay, close nodes get long delay. This way packets propagate outward first, and redundant close-range rebroadcasts are naturally suppressed. Network Coding: 160-byte limitYou said "packets over ~160 bytes drop in reliability pretty quick." Agreed. XOR coding now only applies when both packets are <= 160 bytes. Telemetry/position (20-80 bytes) are ideal candidates; text messages are excluded. Delta Compression: removedYou called it "terrible — our links are not and will never be reliable enough." I agree completely. Removed from the roadmap. Drift on lossy links is unrecoverable. "The stable phase never arrives"This was your strongest point. My fix: graceful degradation based on confidence. Each node tracks how many of its neighbors have known MPR status:
This means V6 is never worse than Managed Flooding — it starts as a flood and gradually adds intelligence as it learns. MPR sets are also recomputed periodically (every 30 seconds + on any neighbor expiry) instead of being static. Sparse networks: the hardest fixYour sparse scenario (10 nodes) was the one that broke V6 the worst. Root cause analysis:
Fix: sparse networks (<=8 neighbors) now bypass defer entirely, get immediate parameter override (high gossip, no echo suppression, long route expiry), and this kicks in from the first packet — not after a warmup period. Answers to your open questionsHow long does MPR take to learn? MPR recomputes every 30 seconds or every ~50 overheard packets (whichever comes first). A new neighbor triggers immediate recomputation. Stale neighbors expire after 5 minutes and are removed from MPR sets instantly. What triggers ECHO restart? Implicit ACK — when a node hears its own forwarded packet rebroadcast by the next hop, that's the echo. If no implicit ACK after timeout (3.3s), the route is marked degraded and gossip probability increases. No extra packets needed. HMAC — how is authentication done? Channel PSK is already a shared secret in Meshtastic. HMAC = Adaptive SF — incompatible SFs? You're right, SF7 and SF12 can't hear each other. The current implementation only uses adaptive SF for unicast to a known next-hop (where we know their modem config). For broadcasts, it stays on the channel default. This is a targeted optimization, not a general mechanism. Implicit header / short preamble? Only applied to relay packets (recipients are already awake), not to originals. Conservative approach — if it causes issues in practice, it's easy to disable. Full learning curve benchmarks1-hour Meshtasticator simulations showing V6 improvement over time:
The learning curve stabilizes quickly — V6 doesn't need a long warmup to be useful. What's still honest
All code is on GitHub:
Thank you again for the checklist and the technical depth. It made the protocol significantly better. -- Clemens |
Beta Was this translation helpful? Give feedback.
-
|
You need to go and test this using real nodes. A test in a field or local area with 10 nodes and the power turned down should reveal where you need to improve. |
Beta Was this translation helpful? Give feedback.
-
Lol. None of this is experimental. Experimental implies experiments. Pure AI psychosis. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Context: What Meshtastic Already Does Well
Meshtastic's routing (v2.6/2.7) is already substantially better than naive flooding:
This proposal doesn't replace these — it builds on the same principles and asks: can we extend directed routing to all message types, not just DMs?
The Remaining Bottleneck
Both managed flooding and next-hop still scale as O(n) per broadcast message. The hop limit (3-7) remains necessary because each hop multiplies transmissions proportional to network size. This caps effective range.
Proposal: System 5 — O(hops) for Everything
A routing approach that achieves ~1 TX per hop for all traffic types:
W(r) = α·Q + β·(1-Load) + γ·Battdistributes traffic proportionally.Simulation: System 5 vs. Managed Flooding
Python simulator with EU868 LoRa model, tested on identical networks with 4 routers (Naive Flood, Managed Flood, Next-Hop, System 5):
The key metric: max load on the busiest node drops from 4,500-19,900 (managed flood) to 6-80 (System 5).
Biggest Practical Consequence
The hop limit becomes irrelevant. Each hop costs ~1 TX regardless of network size. 20 hops cost less than managed flooding costs for 1. This means:
Try It
The demo shows side-by-side animations of all four routing approaches on identical topology, simulation results with interactive charts, and resilience testing.
Questions for the Community
Beta Was this translation helpful? Give feedback.
All reactions