Native and emulated firmware

MeshBench runs the real MeshCore application on every node. There are two ways it can do that, and choosing between them is the first decision in any piece of work.

Native MeshCore compiled for the host machine MeshCore application MeshCore radio driver radio shim, linked in in place of the SPI transport deterministic - faster than real time a few MB and a fraction of a core per node Emulated the published image for a real board MeshCore application MeshCore radio driver emulated CPU, SPI and GPIO talking to a modelled SX1262 wall time - not reproducible about 150 MB and a core per node same Both feed the same channel model, so a native node and an emulated one can share a mesh.
The application and its radio driver are identical in both. They differ only in what sits under the driver: a linked shim, or a modelled chip reached over an emulated SPI bus.

Which to use#

nativeemulated
what is compiledMeshCore, for the hostnothing; the released .bin runs as published
the radioa shim linked where the SPI transport would bean SX1262 model over an emulated SPI bus
speedfaster than real time on a small networkwall time, always
same seed, same resultyesno
cost per nodea few MB, a fraction of a coreabout 150 MB and a core
how many nodeshundredseight, on a twelve core machine
answershow does this change behave on a networkdoes this release work on this board

Native is the arm to measure with. Comparisons, regression gates, protocol studies, coverage questions. Repeatability is the point: the same seed and the same scenario give the same answer, so a difference between two runs is a difference between the two firmwares.

Use emulation to check a release. It runs the artefact people flash, on a model of the chip they flash it to, so it answers whether that build comes up, configures itself and puts a correctly formed packet on the air.

Why emulation cannot be measured#

An emulated node executes instructions at the emulator's pace, so simulated time is tied to the wall clock. Two runs of the same seed interleave differently and produce different numbers. That is a property of the approach, not a defect to be tuned out.

It also has a hard ceiling. Each emulated node is a separate emulator process running in real time. Beyond roughly eight on a twelve core machine, nothing reports an error: boot times stretch, simulated time falls behind, and the result looks like a mesh that has gone quiet.

Mixing them#

A scenario can hold both. A single emulated node in a native mesh is a common and useful arrangement: the network around it is fast and repeatable, and the node under test is the real image.

Firmware is assigned per role or per node, so making one node emulated is a matter of giving it a board image while the rest keep a native build.

MeshBench documentation. Built from the running application, not from mock-ups. Screenshots are window-only captures; see CLAUDE.md for the rule that keeps them current. Edit this page.