Interactive Mesh Network Simulation

1

I came across an interesting project on GitHub called MeshTasticator GitHub - GUVWAF/Meshtasticator: Discrete-event and interactive simulator for Meshtastic. , which aims to simulate a mesh network. This inspired me to build a similar simulation as an interactive web app using p5.js: (this link is to the running version, not the editor)

The Simulation

In this web app, you can click on the large gray area to add nodes to the mesh network. Try to keep the nodes less than 100 pixels apart. Clicking on “Node 0 Send” will initiate a message transmission from the first node. You will then see the message propagate from node to node. Nodes that are currently transmitting are highlighted with a red circle. Stops once reach the Hop Limit (which can be changed globally)

The number displayed on each node represents the number of messages it has received. This helps visualize how far messages travel within the network.

mySketch (1)
(the animation is perhaps a bit fast to really see what going on, in reality can go much slower)

Limitations and Simplifications

This is a simplified simulation and doesn’t attempt to replicate real-world radio characteristics. Here are some key simplifications:

Perfect transmissions: All transmissions are guaranteed to be received within the set radius (default 100px) by any node within that perfect circle. There is no external interference considered, or that links could be sub-optimal.

Simulated cross-talk: However, the simulation attempts to model cross-talk. When two nodes that are outside of each other’s transmission range transmit simultaneously; a node in the middle that can hear both transmissions, experience reception failure due to the overlapping signals. This is represented by a red node. (this cross talk was not something I really thought about with meshtastic before building this!)

In reality, messages affected by cross-talk could potentially be retried (don’t know if normal firmware does this). This simulation doesn’t implement message retries, so each message is only transmitted once from each node.

Message queuing: Each node maintains a perfect queue where all messages are stored and retransmitted once there’s a gap in transmissions (duty cycle permitting). A second red number on a node indicates the number of messages queued waiting for transmission, if duty cycle is blocking transmission. Queue will clear, when duty cycle allows.

No automated replies are implemented. It just sends out a message from a node (although can have multiple senders at once!), and see it get retransmitted. Also all nodes re-transmit, no different roles (eg some repeaters that don’t generate their own messages)

The units are approximate. They’ve been kinda tuned, but the units might be off, the key thing is can just vary them to see relative effect.

Settings

You can adjust various settings in the simulation. Nodes can be configured to transmit automatically at set intervals instead of relying on manual button clicks. There’s also an option to have all nodes transmit simultaneously (which can get visually overwhelming). Play around with the sliders to see how these settings impact the network.

Can also add/remove nodes while simulation running. just click to add a new node. Click a node to remove it.

Metrics

The overall success rate displayed represents the proportion of nodes that have received all transmitted messages. This metric will naturally be lower if you have isolated groups of nodes outside of each other’s transmission range, as some nodes will never be able to receive all messages.

Editing the Code

If you’re interested in modifying the code behind this simulation, you can access it through this link: p5.js Web Editor . This online editor requires some familiarity with JavaScript and p5.js. Editing this link will create a copy that you can save if you sign up for an account. No danger of breaking the version above!

5 Likes
2

Very nice! This is easier in use than my Python-based simulator.

I realize it’s only a simplified simulation, but I just want to give some comments:

  • The hop limit doesn’t seem to be correctly implemented; looks like the original transmitter already bumps it down. If set to 3, it means 4 nodes in a chain can receive it.
  • A node doesn’t rebroadcast a packet anymore if they already heard someone else doing that (except for ROUTER and REPEATER roles). The node that will transmit first is based on the received SNR.
  • I see you added a 5% chance that nodes will transmit at exactly the same time, which is nice, because that may indeed happen. However, you could calculate what the actual chance is, because it happens when they pick the same slot from the contention window.
  • Even if node 0 doesn’t hear node 2 good enough to receive their packets, when node 2 transmits at the same time as node 1, it might be that 2 adds enough interference that it cannot receive the packet from 1 anymore.
2 Likes
3

Thanks for the review - was sure there would be some bits I misunderstood. (part of the motivation for building this was to better understand the system!)

  1. Ah, was unsure how that worked. Will update.
  2. ok. wasn’t aware of that. Will see if can emulate that. Do want to shuffle nodes, so that not always broadcast in same order.
  3. that was a late edition as an experiment, but seemed worth having. Certainly 5% was a plucked out of the air at random. Had read about the contention window, but kinda forgot! (considering making use of ‘random’ optional, so can get repeatable results, or get ‘varied real world’ results)
  4. have wondered about that, certainly the 100px ‘hard’ cutoff, should be more varied.
1 Like
4

Fixed the Hop Limit issue. Turns out it was only on the manual send button that had issues, got broken in refactoring. The repeat sending was working why didn’t notice.

… the others are going to take more thought!

2 Likes
5

I’m just started experimenting with implementing that.

Test version: p5.js Web Editor
… which removes the message from the queye, if heard to for a second time.
(currently all nodes have it enabled, so kinda like all CLIENT)

Although currently it just using a random delay between reception, and retransmission. ratehr than trying to model SNR - need to investigate that!

Can ‘reproduce’ unreliable mesh communications because of it. A carefuly constructured, mesh can mean that a message can’t get though to some nodes. Ie if a node ‘critical’ to continued forwarding, hears a retransmission from another node, it wont actully resend.

Ironcially I can’t figure out to capture it, the behaviour of the demo changes when use P5’s saveGif funtion.

… although still might just be an issue with the simulation, real world usage might be better.

6

Simulation5
This is shows a when it works. Messages start at the left mode and propagate out.

If the North node transmits first, then the message reaches the chain on the top right, all nodes.

But if the South node retransmits first, then the north node will never retransmit, meaning the top right nodes never receive the message.

I suppose demonstrates that in this contrived situation the North Node should really be a ROUTER, so that it will always retransmit first.