I think I'm going to have a go at implementing a mesh network scheme/algorithm inspired by the ones used in batman-adv IV for my project. I can't actually implement batman-adv it's too much work and inappropriate for the ESP platform. The bare bones of the mesh algorithm on the other hand looks like a good candidate and unlike a lot of things floating around online this is an active open source project that's been through multiple iterations of working on the difficulties of mesh networking.
I need to think through how ESP-Now not having a broadcast mechanism will affect it. ESP-Now can send a packet to all a node's peers, but that's not the same thing, those peers need to be found and actively added in the first place.
I've done a trivial test of ESP-Now that involves running SoftAP and periodically scanning for the beacon frames, then switching the SoftAP off once you've joined the mesh. However this would very swiftly end up with multiple isolated meshes that can't find each other.
Current thinking is to have some nodes, at least one per mesh, run as SoftAP, to maintain options for peer discovery, spinning up more periodically if none are directly visible from a section of the mesh.
Likewise ESP-Now adds another layer of complication/admin as the peer table is limited to 20. This peer list will have to be pruned/updated, not something that happens in batman-adv, which only considers if a node is one-hop reachable. So there will be three potential states for a node, one-hop reachable peers, one-hop reachable non-peers and multi-hop reachable.
Thing is I know I could fix this easily if I just started sending my own crafted vendor action frames, especially broadcasts, but this way lies an even deeper rabbithole of reinventing the wheel than the one I'm already in. Using the standard SoftAP and Wi-Fi scanning libraries are an expedient way to avoid this I hope.
No comments:
Post a Comment