sim: ADAPTIVE flood routing with density-based relay selection and TX power saving

[Heilo27]

Summary

This PR adds a full native-C++ simulation harness for MeshCore, along with a new ADAPTIVE routing strategy that has been empirically validated across multiple topologies. Everything in the sim/ directory is simulation-only — no firmware code is touched.

What's new

ADAPTIVE routing strategy (sim/src/RoutingStrategies.h)

Hash-based relay gate selects a deterministic subset of nodes to relay each flood, with the subset size adapted to local neighbour density:

Tier	Neighbours	Relay %	Rationale
SPARSE	≤ 4	100%	Every relay counts; no redundancy to spare
MEDIUM	5–14	25%	Sufficient redundancy, reduced collisions
DENSE	≥ 15	15%	7–8 relayers covers full mesh; -70% collisions

Selection: hash(packet_seed XOR node_seed) % 100 < relay_pct

• Zero coordination — each node independently makes the same decision for a given packet
• Load balanced — different packets select different relay subsets
• Relay suppression — a node cancels its queued TX if it hears another node already relaying the same flood (hash-matched)

DensityEstimator (sim/src/DensityEstimator.h)

Passive neighbour density measurement from normal traffic — no extra protocol messages. Counts unique direct senders (hop_count == 1) over a 60-second sliding window. Thresholds are compile-time overridable.

Adaptive TX power saving (sim/src/SimNode.h)

Opt-in feature (power_save_enabled). ADAPTIVE-selected relay nodes reduce TX power in dense areas:

• DENSE tier: configurable, default 10 dBm (vs 20 dBm full power) — saves ~75% TX current
• MEDIUM tier: configurable, default 14 dBm — saves ~60% TX current
• SPARSE tier: always full power — marginal links need every dB

Motivation: at a high-density event (festival, conference), nodes running at full power 100% of the time waste battery and raise the local RF noise floor. Reducing power when you have 15+ neighbours: (a) saves battery, (b) shrinks interference radius via the LoRa capture effect, (c) doesn't hurt local delivery since nearby nodes still receive well above sensitivity.

Validated: 100% delivery maintained at MODERATE (-10 dBm DENSE) across all topologies tested.

Simulation infrastructure

File	Role
sim/src/SimBus.h	Virtual RF medium — packet delivery, collision model, channel models
sim/src/SimNode.h	Per-node MeshCore instance with metrics and routing hooks
sim/src/SimRadio.h	Radio abstraction — airtime estimation, LoRa capture effect (6 dB threshold)
sim/src/SimMetrics.h	Flood delivery rate, latency, per-flood aggregation
sim/src/SimRuntime.h	Deterministic clock and RNG for reproducible runs

Channel models available: FullMeshModel, ChainModel, GridModel, PositionalModel.

Scenario suite

Scenario	What it validates
scenario_adaptive	ADAPTIVE vs DEFAULT vs PATH_SNR_HYBRID across FM50/Chain/Grid
scenario_concurrent	2–8 simultaneous flood sources
scenario_longchain	20-hop chains at marginal SNR (6 dB)
scenario_mixed	ADAPTIVE + legacy DEFAULT firmware interoperability
scenario_dutycycle	EU 1% duty cycle enforcement
scenario_relay_pct_sweep	Grid sweep to find optimal DENSE%/MEDIUM% operating point
scenario_txpower	TX power saving vs delivery rate vs energy — festival use case

Key empirical results

• FM50, ADAPTIVE vs DEFAULT: equal delivery rate, -65% airtime, -70% collisions
• Chain-20: ADAPTIVE stays at SPARSE tier throughout — identical behaviour to DEFAULT. No regression on sparse topologies.
• TX power MODERATE (-10 dBm DENSE, -6 dBm MEDIUM): 100% delivery maintained, ~35% energy reduction
• Legacy interop: zero delivery regression when ADAPTIVE and DEFAULT nodes coexist
• Duty cycle: ADAPTIVE uses ~40% fewer TX budget slots than DEFAULT at the same load

Bug fixes (found during development)

• DensityEstimator: replaced seen[64] fixed array with std::unordered_set — was silently capping unique neighbour count at 64
• SimBus::onTransmit: added len > 255 guard before memcpy into 255-byte buffer
• SimNode p_forward gate: >= → > — was silently suppressing relays at exactly p_forward=1.0

Building

cd sim
mkdir build && cd build
cmake ..
make -j4
./scenario_adaptive
./scenario_txpower

Requires a C++17 compiler. No dependencies beyond what's already in the repo (uses lib/ed25519, deps/arduinolibs/Crypto).

Not in this PR

This PR is simulation-only. The ADAPTIVE strategy would need firmware integration work (replacing the node_seed with a pub-key-prefix hash, hooking getRetransmitDelay()) before it could run on hardware. That's a separate conversation — wanted to get the algorithm validated first.

[gafu42]

" adapted to local neighbour density"

this is a thing like meshtastic made, and i hated it.
in meshtastic the traffic reduction worked by SNR, relays with good snr doesnt repeat if someone with a lower SNR repeated first. In the real world with, nodes with bad antennas and indoor antennas, this enforced the mesh to be relayed through the link with the lowest quality. Sometimes this was a distant node, but often it was a bad performing one close to the sender, hindering the good one to repeat. This made the mesh very bad perfoming as soon as the mesh was growing.

on my view this will do something similar.
The "top height" relays, which can receive repeats from a wide area will stop repeating in favor to ones, which can receive only one or two others because their not optimal place oder bad antenna.

In addition to this you need a setting to switch it off on top of the hill repeaters, and then the folks down with their little ones will do it too.

so no offence. i think the benefits from this will not work in the real world, because of not ideal repeaters

[Heilo27]

Oh absolutely I get that. It would need tweeking for sure. My thought was using this in crowds would be beneficial and stop the constant re-broadcasting of every single message which causes drop messages and collisions. And it doesn’t base it off of signal quality it bases it off of a hash, which just kind of randomizes it and it only does it when there are enough nodes nearby that it’s becoming a problem so greater than 12 to 15 nodes the system starts to re-broadcast transmissions select selectively using a hash when a radio receives a message. It helps choose whether or not it will re-broadcast it to everyone else in other words it lowers overall network Clutter by 60% saves battery life on your radio since it’s not re-broadcasting every message needlessly and fewer re-broadcast means fewer collisions. I did think of provisions for edge cases and I think that there is definitely room for improvement however, in simulator, I tested this theory and it did show a dramatic reduction and dropped Messages power usage, but still ensuring 100% coverage. I absolutely think hilltop nodes don’t need this, and there is the ability to turn it on and off or maybe not even be flashed with this version of the firmware at all but for mobile notes, this would be very valuable in situations with a large gathering of people. -RyanOn May 15, 2026, at 6:40 AM, gafu ***@***.***> wrote:gafu42 left a comment (meshcore-dev/MeshCore#2466) " adapted to local neighbour density" this is a thing like meshtastic made, and i hated it. in meshtastic the traffic reduction worked by SNR, relays with good snr doesnt repeat if someone with a lower SNR repeated first. In the real world with, nodes with bad antennas and indoor antennas, this enforced the mesh to be relayed through the link with the lowest quality. Sometimes this was a distant node, but often it was a bad performing one close to the sender, hindering the good one to repeat. This made the mesh very bad perfoming as soon as the mesh was growing. on my view this will do something similar. The "top height" relays, which can receive repeats from a wide area will stop repeating in favor to ones, which can receive only one or two others because their not optimal place oder bad antenna. In addition to this you need a setting to switch it off on top of the hill repeaters, and then the folks down with their little ones will do it too. so no offence. i think the benefits from this will not work in the real world, because of not ideal repeaters —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>