NoctiNav Bridge: An ESP32 Telemetry Bridge (Early Concept)

Why another bridge

Modern UAV workflows often rely on small "glue" components: telemetry bridges, protocol adapters, simple tunnels that make different tools talk to each other.

Many of these exist already — and some of them work very well.

However, we repeatedly encountered the same problems in real work:

• ●Fragile configurations
• ●Unclear data paths
• ●Too many implicit assumptions
• ●Tools that work only if you already know everything

NoctiNav Bridge is our attempt to explore a calmer, more explicit approach.

This post describes the idea and design direction. It is not a release, and not a promise.

What NoctiNav Bridge is

At its core, NoctiNav Bridge is an ESP32-based telemetry bridge designed to sit between a flight controller and multiple consumers.

The primary goals are:

• ●Transparency instead of magic
• ●Presets instead of undocumented flags
• ●Visibility instead of guessing

It is intentionally small in scope.

Core capabilities (planned)

1. MAVLink over network

The bridge is designed to support common MAVLink network transports:

• ●TCP / UDP / UDPCI
• ●Tested with common GCS tools such as Mission Planner and QGroundControl

The goal is transport neutrality — not tool lock-in.

2. Telemetry fan-out (multi-UDP)

A common real-world need is to stream telemetry to multiple consumers at the same time:

• ●GCS
• ●Logging tools
• ●Visualization or automation software

NoctiNav Bridge is designed to support multiple UDP outputs from a single input, similar to SkyBrush-style workflows, without reconfiguration during operation.

3. Non-MAVLink tunneling (MSP)

Not all flight stacks speak MAVLink.

For this reason, the bridge is planned to support transparent byte tunneling for non-MAVLink protocols, such as:

• ●MSP (MultiWii Serial Protocol), used by Betaflight and iNav

4. Physical connectivity

Planned physical interfaces include:

• ●UART — flight controller
• ●USB — setup / diagnostics

The intent is to keep roles explicit: one interface for the vehicle, one for humans.

5. WebUI (human-ready)

A simple WebUI is planned to provide:

• ●Preset-based configuration
• ●Link status visibility
• ●Routing overview

The WebUI is not meant to expose every internal flag. It is meant to make intent visible.

6. BLE (limited scope)

BLE support is planned for:

• ●Provisioning
• ●Quick checks
• ●Local status access

BLE is not intended as a control plane.

7. MAVLink component identity (optional)

When appropriate, the bridge may identify itself as a MAVLink component.

This is intended for introspection and monitoring, not for replacing or impersonating a flight controller.

What this project is not

Clarity matters, especially early.

NoctiNav Bridge is not:

• ●A long-range radio
• ●A video encoder
• ●A safety controller
• ●A replacement for RC systems
• ●A drop-in production solution

Those problems deserve their own dedicated systems.

Inspirations and respect

This work is inspired by existing community projects, including (but not limited to):

• ●DroneBridge
• ●MavESP and SkyBrush-modified variants

These projects solved real problems and helped many people learn.

NoctiNav Bridge explores a different balance, not a replacement.

Status

• ✓Phase: Idea / early design
• ✓Availability: Not released
• Feedback requested: high-level use cases and workflows

We are intentionally starting slowly.

An early alpha build may be published later for experimentation and learning, clearly marked as such.

Closing note

Bridges sit in the middle of systems. When they fail, everything feels broken.

Our goal with NoctiNav Bridge is modest: make the middle boring, visible, and understandable.

Nothing more.