Trifecta bridge — beta 3

Trifecta repeater firmware (real LoRa + ESP-NOW bridge + IP bridge, all at once) — beta 3.

Built from commit 467c10f1 on the espnow-ip-bridge branch. Covers Heltec V3, Heltec V4, and Xiao S3 WIO.

This build has debug logging enabled (BRIDGE_DEBUG, MESH_DEBUG, MESH_PACKET_LOGGING, WIFI_DEBUG_LOGGING) — noisier serial output than a normal release, in exchange for full visibility into bridge routing decisions. Pairs with watch_boards.py below.

What's new since beta 2

• Fixed: a repeater's own broadcast traffic (adverts, flood replies) could get misrouted to a single bridge instead of reaching everyone. The heuristic that redirects a reply straight back out the bridge it came from was also catching FLOOD-route sends and zero-hop self-adverts — both of which are meant to reach everyone, not bounce back to one peer. Found live: a repeater's own self-advert would silently fail to reach a peer repeater over the bridge whenever it happened to fire shortly after any unrelated bridge traffic. Fixed for both cases; always falls back to broadcasting to everyone whenever it isn't confidently a genuine reply.
• New: RF-preference delay now covers first contact, not just already-established replies. Previously only the path-return reply got a brief hold-back (giving a real RF path a head start before mirroring over the IP bridge) — the very first message between two new peers had no such protection, so the IP link could win the race and become baked into the learned route even when a working RF path existed. Now the whole first-contact message family (requests, responses, text messages, admin logins) gets the same treatment.
• New: that delay skips entirely when the destination is already known to be bridge-only reachable (e.g. an ESP-NOW-only companion with no LoRa radio at all) — so the two main use cases for this feature (LoRa-less companion, indoor repeater backhaul) aren't taxed with pointless latency; only genuinely redundant RF-vs-bridge topologies pay the delay.
• Changed: bridge-neighbour tracking now recognizes companions, not just other repeaters — needed for the above to actually detect a bridge-only companion as bridge-only. The stock, RF-only neighbors CLI table is unchanged. Table size is now matched to the RF-neighbour table instead of a fixed, unexamined cap of 8.

Repeaters (Xiao S3 WIO, Heltec V3, Heltec V4)

Which file to flash:

• -merged.bin — for a blank/fresh board. Flash at offset 0x0:
  esptool.py --chip esp32s3 write_flash 0x0 <file>-merged.bin
• plain .bin (no -merged suffix) — app-only, for upgrading a board that's already running MeshCore. Preserves identity, WiFi credentials, and BLE bonds. Flash at offset 0x10000:
  esptool.py --chip esp32s3 write_flash 0x10000 <file>.bin

After flashing, configure over the standard MeshCore serial CLI (set bridge.channel, set bridge.secret, set wifi.ssid, set wifi.pwd, set ip.host, etc.) — no custom tooling needed.

Monitoring multiple boards at once

python3 watch_boards.py

Auto-detects every connected board, connects to all of them, and streams their debug output live in one terminal — press n to dump neighbors.all from every connected repeater at once. See the script's own --help for details.

Full writeup, use cases, and setup details: https://smellyspice.github.io/MeshCore/

This is an unmerged personal fork, not reviewed by MeshCore maintainers — a developer/beta release for testers who want to help shake it out, not something to run on a mesh anyone actually depends on. This build specifically also ships with debug logging left on, which is noisier and slightly heavier than a real release build. If your mesh matters to you or to other people using it, wait for something further along than this. See the writeup for known limitations before flashing.