MeshCore network simulator
A simulator built from scratch, with an attempt to be as close to real physics as possible (well, still a lot to verify!).
Why can't I send a private message (they're called Direct Messages — DM — but that's just a name) from A to B? Well, I can, but was it actually received?
My history with MeshCore started recently. I went through Meshtastic first, then, after some experiments, moved my focus to MeshCore. The idea was pretty simple — I have a small, remote house and wanted to experiment with sending some simple telemetry once a day (or rather, once a night). Having in mind that investing in a possible emergency network is a good idea too — let's set up a repeater or two.
I liked the fact that MeshCore is more silent, that it can route messages. So, what can go wrong?
Well... nothing went wrong. I just had to learn how a mesh network works, why DMs are not always received, why confirmations don't always reach the sender. How to learn that? Best way — understand how the network actually works.
So, my first step was to actually understand what my local network looks like. Who talks to whom? Which links are strong, which are barely there? I built a tool for that — meshcore-optimizer.
The idea is straightforward: connect to your companion radio, and let the tool progressively discover the network. It logs into repeaters (or uses trace when login isn't available), collects SNR measurements for every link, and builds a full topology map. It then computes optimal routes using a widest-path algorithm — essentially finding the path where the weakest link is as strong as possible. The whole thing runs as a Python application with a web-based map (OpenStreetMap, dark theme, because obviously) where you can click any two nodes and instantly see the best route between them.
This gave me a much clearer picture of my Gdańsk network — which links were solid, which ones were marginal, and where the routing bottlenecks actually lived.
But mapping the network only tells you what is. It doesn't tell you why.
I started experimenting with traces, following message paths hop by hop, trying to understand what happens under the hood when a DM travels through the mesh. Why does this particular path get chosen? Why does a confirmation get lost on the way back? Why does adding a repeater sometimes make things worse? To really answer these questions, I needed to go deeper into the firmware logic itself.
That's when the idea hit me — what I really need is a simulator. A controlled environment where I can set up any topology, inject messages, break links, and watch exactly what happens at every step.
I found meshcore_sim by Matthew Green, which was a great starting point. It gave me my first real insight into simulating MeshCore behavior and confirmed that the approach makes sense. But I quickly ran into its limitations — it was too slow for the kind of experiments I had in mind. I wanted to simulate dozens of nodes, run hundreds of scenarios, test edge cases with collisions and fading and adversarial conditions. I needed something faster. Much faster.
So I started building my own: meshcore_simv2.
(To be continued...)