Forty nodes and a mountain between two radios, on your machine. Break the link on purpose and read exactly why it broke — real MeshCore firmware, a sample-accurate LoRa channel, real terrain, and a demodulator that finds out for itself.
One binary. No service to deploy, no account, nothing to configure before the first run.
They arrive with different questions, and the tool answers all three against the same physics.
Coverage rasterised over real terrain and searched for the best site. Both link margins for any pair — both, because reachability is asymmetric — and the terrain cut-through that explains them. Import a live network from CoreScope, Beacon or MQTT and ask what it would do.
MeshCore's own code, not a reimplementation: routing, flood suppression, duty-cycle
policing and CSMA timing are the real thing. Point meshbench dev at a
checkout, run half the mesh on one build and half on another, same traffic, and diff.
meshbench serve exposes a node over TCP, a serial pty or Bluetooth —
the real companion protocol, spoken by real firmware. Your app cannot tell it from a radio
on a desk, and you can put forty nodes and a hill between it and the far end.
Most mesh simulators answer did the packet arrive from a link-budget rule. That tells you nothing about the case that actually matters: a marginal link, two nodes transmitting at once, a hill in the way.
Path loss over real terrain, thermal noise, and then every receiver's demodulator finds out for itself. Capture effect, partial collisions and sensitivity are emergent — nobody wrote them down as rules, which is why the failure you are chasing can happen here at all.
Airtime matches the firmware's own getEstAirtimeFor().
Its CSMA timing is built on that number, and a channel that disagrees desynchronises
silently.
.uf2 and .bin images under QEMU and Renode, with a matrix of what has been watched happening.meshbench test runs a fixture on real firmware and checks its assertions, for your CI or MeshCore's.Published board images, run under an emulator, and watched. Every row is a measurement — never a claim about the hardware. A blank means nobody has watched that board do that thing.
| Board | MCU | Emulator | How far it got |
|---|---|---|---|
| Generic_E22_sx1262 | ESP32 | QEMU | forwards, and answers after an idle |
| Heltec_t114 | nRF52840 | Renode | forwards, and answers after an idle |
| Heltec_t096 | nRF52840 | Renode | forwards, and answers after an idle |
| RAK_4631 | nRF52840 | Renode | forwards, and answers after an idle |
| Xiao_nrf52 | nRF52840 | Renode | forwards, and answers after an idle |
| Heltec_mesh_solar | nRF52840 | Renode | forwards, and answers after an idle |
| Heltec_v3 | ESP32-S3 | QEMU | forwards, and answers after an idle |
| LilyGo_TDeck | ESP32-S3 | QEMU | forwards, and answers after an idle |
| Ebyte_EoRa-S3 | ESP32-S3 | QEMU | forwards, and answers after an idle |
| Xiao_S3_WIO | ESP32-S3 | QEMU | forwards; idle behaviour not measurable yet |
| Station_G2 | ESP32-S3 | — | no emulation wiring recorded yet |
| Heltec_v2 | ESP32 | — | carries an SX1276, which is not modelled |
Forwarding is the row worth reading: it means the board took somebody else's packet off the air and put it back on, judged at the board itself, which is what separates a member of a mesh from a node that talks to itself. Measured one board at a time on an idle machine, on 4 September 2026 — several emulators at once make a twelve-core machine fall behind the wall clock, and a board running late looks exactly like a board that is broken. The two boards with no emulator have never been attempted rather than tried and failed. The full matrix has a column per capability.
No multipath, no oscillator error, no body loss, bare-earth terrain unless you load buildings, and an ESP32's Wi-Fi and Bluetooth stubbed rather than simulated.
Nearly every known bias points the same way, which is what makes the tool usable: if it says a link will not work, believe it; if it says a link will work marginally, go and measure.
It is stated in the interface, on every result, and What it does not do is a long, specific and maintained account of what the model omits, what it gets measurably wrong, and in which direction — including the parts never checked against real air.