Firmware v1.4.x Series - Mesh Algo Improvements
Going forward, ChatterBox firmware updates will be released rapidly and incrementally. Throughout January (and possibly February), the firmware updates will focus on improving the mesh algorithm for both communicators and nodes.
The most significant change so far in v1.4 is a move from neighbor-based deliveries to almost entirely graph-based. A more detailed description of the change is below. The 1.4 series will contain more mesh-related improvements, and possibly bug fixes if they arise.
It is recommended that you update all devices to 1.4.4 or higher, to take full advantage.
Firmware Flash Page (and backups/mirrors)
Firmware Flash Page Mirror Flash Page Secondary Mirror Flash Page
v1.3 and Older Algo - Neighbor Centric
As you can see, this algorithm can be highly dependent on whether a device currently believes another device is nearby or not. If devices have different tx power levels (amps), this may not be so reliable.
Receive a valid mesh packet
Save to our local mesh cache
Take a live look at nearby neighbors. Based on who I’ve seen in the last 2 minutes, which one(s) has a good path, as indicated by the mesh graph
Forward the packet to that neighbor
Periodically repeat steps 2-4 until the end recipient confirms delivery (with signature) or until I’ve handed to 2 neighbors
v1.4+ Algo - Graph Centric / Opportunistic
The decentralized mesh graph gives each device an ever-changing full cluster view of perceived connectivity between all on-cluster devices, in both directions. When choosing which way to forward a packet, the important part is can the recipient receive from me, not can I see the recipient.
Receive a valid packet
Save to our local mesh cache
Consult the mesh graph to determine if the recipient can typically receive packets from us or not
If so, attempt delivery. If not, plan a path, in reverse, with tunable weighting of importance between whether sender can see recipient, and vice versa.
Forward to the selected “hop”
Repeat steps 3-5 at varying intervals until end recipient confirms delivery or until sender-selected expiry has passed
Opportunistic Delivery
In addition to the algo steps above, 1.4.4 and higher makes use of a concept called “opportunistic delivery.”
At any point in time, if a device becomes visible (live packets recently seen from the target device) and we have packets for it, we check if delivery is likely to succeed (consult mesh graph) and if we’re likely to receive a direct confirmation from the other device (consult mesh graph). If so, we essentially drop what we’re doing and fire off packets.
This opportunistic delivery is rate-limited, so the cluster’s rotating frequency doesn’t become suddenly too busy. Nodes have greater leeway to do opportunistic deliveries, while communicators can do it, but in a more limited fashion.
Pair-specific frequency hopping is in play for these (an all) DM mesh deliveries, so only the first packet is exchanged on the cluster’s current frequency. The remaining packets during a delivery happen on frequencies only the sender/recipient devices can predict.
