How MeshCore Scales Where Other LoRa Meshes Hit Walls | Magnus919
A reasonable overview of the MeshCore architecture and tunable parameters.
Probably the only part I don't agree with is the idea that the companion/repeater dichotomy is an inherent part of the MeshCore architecture. I don't believe it is, although it's certainly part of the _practical_ implementation. That is to say, if someone wants to use MeshCore purely as a private point-to-point link, then they can jettison the motions of companions and repeaters entirely. As a person to person mesh network, though, companions and repeaters are essential. The distinction I'm trying to draw is that MeshCore can be a lot more than text messages sent amongst friends.
While reading, the explainer for the three-tier t delay seemed especially analogous to me to how circuit breakers are arranged: a nearby power strip might have a fast-tripping 15 amp thermomagnetic breaker, the upstream main panel might be using a 20 amp curve B (moderate trip rate) thermomagneric breaker, and the utility might be using a magnetic 400 amp breaker. By their nature, thermomagneric breakers will handle localized faults that are 3-5x the rating, while the utility's magnetic breaker will trip precisely at 400.1 amps, to protect line-side equipment. Whereas if the utility breaker tripped first, it would unnecessarily black out a whole neighborhood.
Also observe that MeshCore's "flood-then-direct" behavior is identical to that of Ethernet (ie unknown unicast, then unicast), except that Ethernet frames do not get appended with the network path as they progress, which is akin to the postal service where letters arrive at their destination but with no indication of the routing. Accordingly, the MeshCore sender necessarily reserves space to store the mesh route, choosing a tradeoff between node-count (up to 64) or granularity (up to 3 bytes per repeater). This seems complex, but just like with the tax code, complexity is necessary to handle every reasonable scenario.
I will also reiterate the ongoing bug in MeshCore's encryption, which is the use of AES-ECB in the year 2026. Although it's AES-256, ECB has been a known encryption vulnerability for decades and should not have been used in the MeshCore spec. Meshtastic appears to have avoided this particular foible.
Note: the author's blog mentions in the About page that some AI is used to assist in his writing.
Probably the only part I don't agree with is the idea that the companion/repeater dichotomy is an inherent part of the MeshCore architecture. I don't believe it is, although it's certainly part of the _practical_ implementation. That is to say, if someone wants to use MeshCore purely as a private point-to-point link, then they can jettison the motions of companions and repeaters entirely. As a person to person mesh network, though, companions and repeaters are essential. The distinction I'm trying to draw is that MeshCore can be a lot more than text messages sent amongst friends.
While reading, the explainer for the three-tier t delay seemed especially analogous to me to how circuit breakers are arranged: a nearby power strip might have a fast-tripping 15 amp thermomagnetic breaker, the upstream main panel might be using a 20 amp curve B (moderate trip rate) thermomagneric breaker, and the utility might be using a magnetic 400 amp breaker. By their nature, thermomagneric breakers will handle localized faults that are 3-5x the rating, while the utility's magnetic breaker will trip precisely at 400.1 amps, to protect line-side equipment. Whereas if the utility breaker tripped first, it would unnecessarily black out a whole neighborhood.
Also observe that MeshCore's "flood-then-direct" behavior is identical to that of Ethernet (ie unknown unicast, then unicast), except that Ethernet frames do not get appended with the network path as they progress, which is akin to the postal service where letters arrive at their destination but with no indication of the routing. Accordingly, the MeshCore sender necessarily reserves space to store the mesh route, choosing a tradeoff between node-count (up to 64) or granularity (up to 3 bytes per repeater). This seems complex, but just like with the tax code, complexity is necessary to handle every reasonable scenario.
I will also reiterate the ongoing bug in MeshCore's encryption, which is the use of AES-ECB in the year 2026. Although it's AES-256, ECB has been a known encryption vulnerability for decades and should not have been used in the MeshCore spec. Meshtastic appears to have avoided this particular foible.
Note: the author's blog mentions in the About page that some AI is used to assist in his writing.