Trifecta bridge — beta 6

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

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

Two builds per board, same code, different tradeoff:

• _debug files — BRIDGE_DEBUG, MESH_DEBUG, MESH_PACKET_LOGGING, WIFI_DEBUG_LOGGING all on. Noisier serial output, and debug logging has a real (small) timing/CPU cost on a busy repeater, but gives full visibility into bridge/routing decisions. Use this for testing, troubleshooting, or pairing with watch_boards.py below.
• Plain files (no _debug suffix) — functionally identical, debug logging stripped out. Quieter and slightly leaner/faster, since nothing is spending time formatting and pushing log lines out over serial every packet. Use this once you're done actively debugging and just want the repeater running.

What's new since beta 5

• The IP bridge's reconnect no longer retries at a flat interval forever. On a real connect failure it now backs off (10s → 20s → 40s → 60s, capped) instead of hammering every 5 seconds indefinitely. The cap is deliberately short (60s, not minutes) — this bridge only ever has one peer, so there's no shared server to be polite to, and the priority is noticing the peer come back quickly.
• Fixed: that backoff wasn't actually escalating past 20s. The periodic DNS re-resolve (kicks in after a couple of failures, in case the peer's address genuinely changed) was resetting the failure counter on every successful lookup — DNS succeeding says nothing about whether the peer itself is reachable, so this silently capped the backoff at 20s regardless of how long the real outage was. Now the counter only resets on an actual successful connection.
• The backoff distinguishes "no WiFi at all" from "WiFi's up but the peer isn't answering." A WiFi outage isn't the peer's fault and shouldn't cost the same escalating penalty — while WiFi itself is down, retries stay at a short flat interval (persistent, not growing) so reconnecting happens quickly the moment WiFi actually comes back, rather than potentially sitting out a long backoff window that had nothing to do with the peer at all.
• The board's clock now re-syncs via NTP every 12 hours, not just once at boot. These boards have no battery-backed RTC, so the clock was previously set once (at boot or WiFi reconnect) and then left to drift for the rest of the uptime. Same "only if WiFi is actually configured" guard as the original sync.

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, b to dump bridge status, c to toggle watching companion boards, from every connected board 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, debug logging on or off. 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.