# DroneBridge for ESP32: a seven euro radio link for drone telemetry over WiFi or ESP-NOW > DroneBridge for ESP32 is Espressif based firmware that turns a cheap module into a bidirectional telemetry link between a flight controller and a ground station, carrying MAVLink, MSP or LTM over serial to WiFi, over WiFi long range, over ESP-NOW at up to a kilometre, or over Bluetooth LE, with AES-GCM encryption in every mode. It carries telemetry only, and there is no video path. **DroneBridge/ESP32** — DroneBridge for ESP32. A secure & transparent telemetry link with support for WiFi and ESP-NOW. Supporting MAVLink, MSP, LTM or any other protocol - Repository: https://github.com/DroneBridge/ESP32 - Website: https://drone-bridge.com/ - Stars: 1,130 · Forks: 237 - Language: C - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/dronebridge-esp32 ## What it is, and the limit that shapes everything DroneBridge for ESP32 is a firmware for the popular ESP32 modules from Espressif Systems, and the project describes it as probably the cheapest way to communicate with your drone, UAV, UAS, ground-based vehicle or whatever you may call them. The limit is stated early and it is not a footnote. DroneBridge for ESP32 is a telemetry and low data rate only solution, and there is no support for cameras connected to the ESP32 since it does not support video encoding. That is the first thing to establish, because the obvious question about a drone telemetry link is usually whether it can carry video, and the answer here is no. A video downlink is a different product with different hardware requirements, and this firmware is about the small, frequent, bidirectional messages that a flight controller and a ground station exchange: attitude, battery, GPS, mode changes, and the heartbeats that tell each side the link is alive. The second structural point is about the data model, and it comes from a change in v2.0. It also allows for a fully transparent serial to WiFi pass-through link with variable packet size, and as of release v2.0 no continuous stream of data is required anymore in MAVLink and transparent mode. That last clause is a meaningful design change rather than a detail. The older model of a serial to WiFi bridge was a continuous stream, which means the link has to keep up with a constant rate and the receiver has to buffer. Removing the requirement for a continuous stream means the link becomes a series of discrete packets, which is what makes a protocol like ESP-NOW usable at all, since ESP-NOW is a connectionless broadcast mechanism with a much lower throughput than WiFi. The primary language is C, the licence is Apache-2.0, and the homepage is drone-bridge.com. The recent releases are v2.4.1 on 2026-09-12, v2.4.0 on 2026-08-26 and v2.3.0 on 2026-08-20, and the repository is not archived, with the last push on 2026-09-12. The topic tags name the ecosystem precisely: ardupilot, inav, ltm, mavlink, msp, pixhawk, qgroundcontrol, multiwii, multicopter, telemetry, communication-systems, datalink, espressif, espnow and esp32. ## The four transports, and the range each one buys you The feature list is where the engineering shows, and the transports are the first item: bidirectional, covering serial-to-WiFi, serial-to-WiFi Long-Range, serial-to-ESP-NOW link, and Bluetooth LE. The range figures come next, and they are what determine which transport you choose. Up to 150m of range using standard WiFi. Up to 1km of range using ESP-NOW or WiFi LR Mode, with the sender and receiver both having to be an ESP32 with LR-Mode enabled. The requirement that both ends be LR-capable is the practical constraint. WiFi LR mode is a feature of the ESP32 radio that extends the range at the cost of throughput, and the ESP-NOW path gets its kilometre from the fact that it is a short-range protocol pushed hard rather than a long-range protocol by design. Encryption is stated as covering all modes, including the ESP-NOW broadcasts, secured using AES-GCM 256 bit. That last detail is the one that matters for a broadcast protocol, because ESP-NOW is connectionless, so there is no session to negotiate keys in. Securing the broadcasts themselves means the payload is encrypted before it goes out, which is the only place it can be secured in that mode. Then the other operational facts. Affordable at about 7 euros for the module. Weight under 8 grams. Easy to set up with a power connection and a UART connection to the flight controller. Fully configurable through an easy-to-use web interface. The protocol support is broad: MAVLink, MSP, LTM or any other payload using the transparent option. And there is parsing work behind that, which is listed as separate features. Parsing of LTM and MSPv2 for more reliable connection and less packet loss. Parsing of MAVLink with the injection of Radio Status packets for the display of RSSI in the GCS. The RSSI injection is worth a note, because it solves a problem that is otherwise awkward. When the link is ESP-NOW at a kilometre, knowing the signal strength matters, and the native radio status message may not be what the ground station expects from a particular telemetry source. Injecting a Radio Status packet with the RSSI means the ground station shows a link quality indicator that reflects the actual radio rather than the flight controller's own idea of it. Finally there is a fully transparent telemetry down-link option, reliable and low latency. The transparent option is the escape hatch, and it is what makes the firmware usable with a protocol nobody has written a parser for yet, at the cost of losing the parsing improvements. ## The drone light show edition, and what it changes There is a special edition of the firmware, the Drone Light Show Edition, and the differences are not cosmetic. It is a special version optimised to work for drone shows using Skybrush, and the release to get is on the project website rather than the repository tags. Its feature list starts with Skybrush support, which is the actual point: a light show is dozens or hundreds of drones in the air, and the show controller has to address them as a group and keep them in step. Remote power management of the show drone, with sleep and wakeup, is the second item and it is the one that shows the domain. A drone in a show has to be asleep until its cue, because a hundred drones all powered and transmitting would swamp the link. Waking a drone on demand is a protocol concern, not a power concern, since the ESP32 has to be reachable to be woken. Then there are lots of additional checks to improve safety and reliability, which is the phrase that tells you what the edition is for. A light show over people is a different safety class from a hobby flight, and a link that drops a packet at the wrong moment is a drone that does not move when the show says it should. Over the air updates for the ESP32 come next, which matters for a fleet, since reflashing a hundred drones over USB is not a plan. WiFi6 with OFDMA and 5GHz support on supported ESP32 chips is the throughput item, and it addresses the show case directly, where many nodes on one channel need to share it fairly. The ESP32-C3, ESP32-C5 and ESP32-C6 support follows, so the newer and cheaper Espressif parts are covered rather than only the original. The final item is a commercial support suite, an Open Source Commercial Support Suite, to help you flash, manage and maintain your drones efficiently, and to script your own tools following the given examples using the DLSE API. That is a different kind of project entry than the rest of this repository, where the code is Apache-2.0 and the surrounding infrastructure is documented for self-service. One more claim is worth repeating because it sets the scale of what the project is used for. DroneBridge for ESP32 can be used to control drone swarms at a low cost, and the number of drones is only limited by the channel capacity and the processing power of the ESP32s. The illustration in the README shows the connectionless ESP-NOW protocol being used for increased range of 1km or more, and the text notes that the range can exceed a kilometre with external receiving antennas. ## Flashing, wiring and the web interface The setup path is deliberately frictionless, and there are two steps where people usually go wrong. Flashing is recommended through the official online flashing tool at drone-bridge.com/flasher, and the wiki covers the other routes. The repository itself contains flashing_instructions.txt, and the release packaging is done by create_release_zip.sh with a PowerShell equivalent in create_release_zip.ps1, so the artefacts are built by script rather than by hand. The wiring instruction has one line that matters more than the rest. Connect the UART of the ESP32 to a 3.3V UART of your flight controller, and it is not recommended to use the ESP32s pins that are marked with TX and RX since they are often connected to the internal serial output, so go for any other pin instead. Those marked pins are the ones the ESP32 uses for its own console output, so wiring telemetry to them puts your flight controller data and the chip's debug output on the same wire. The second step is to set the flight controller port to the desired protocol, which is a flight controller setting rather than an ESP32 one. And the power warning is specific: check out the manufacturer datasheet, because only some modules can take more than 3.3V, and follow the recommendations by the ESP32 board manufacturer for powering the device. A flight controller UART is 3.3V logic, and some ESP32 dev boards have 5V tolerant pins on some of their other pins and not others. Configuration is done through the web interface. You connect to the WiFi network DroneBridge ESP32 with the password dronebridge, then in your browser type dronebridge.local, or 192.168.2.1 in Chrome with the http prefix, into the address bar. The note that you might need to disable the cellular connection to force the browser to use the WiFi connection is the kind of detail that only appears when someone has written it down, because a browser on a laptop with both a cellular modem and WiFi will often prefer the cellular interface and fail to resolve the local name. Then you configure as you please and hit save. The configuration persists, and the repository has a config_defaults/ directory and a db_params.csv, which suggests the settings are stored with defaults and a parameter table, alongside the sdkconfig files that carry the build configuration. The official board is featured in the image with the ESP32C6, and the project asks you to use one of the officially supported and tested boards, saying the boards are very affordable, have everything you need, and are also very compact, perfect for use on any drone. ## Connecting a ground station, and the UDP detail that catches people The ground station side is the last piece, and it has one rule that is worth knowing before you spend an evening on it. The ESP will auto-send data to all connected devices via UDP to port 14550, and QGroundControl should auto-connect using UDP. You can also connect via TCP on port 5760 or UDP on port 14550 to the ESP32 to send and receive data with a GCS of your choice. The supported list is QGroundControl, Mission Planner, mwptools, impload and others. Then the rule: in case of a UDP connection the GCS must send at least one packet, for example a MAVLink heart beat, to the UDP port of the ESP32 to register as an endpoint, and you add the ESP32 as a UDP target in the GCS. There is also a manual option to add a UDP target using the web interface. This is not a quirk of the implementation, it is how UDP works. The ESP32 sends its telemetry to an address, and until the ground station sends something to that address the ESP32 has no idea where to send to. A TCP connection establishes itself, so the TCP path needs no such gesture. On UDP, the first packet from the ground station is what gives the ESP32 a return address to use. That is why the documentation mentions the heartbeat specifically. A MAVLink heartbeat is a small, periodic message that every ground station sends anyway, so making it the trigger costs nothing extra, and it is what causes the ESP32 to start streaming to that endpoint. Support is a Discord channel for questions and general chatting, and the wiki at dronebridge.gitbook.io carries the detailed pages for hardware and wiring, installation, configuration and the officially supported boards. The repository carries a wiki/ directory with the images and diagrams those pages use, and an AGENTS.md at the root. For a developer extending the firmware, the layout is visible in the top level listing. There is main/ for the application, components/ for the reusable pieces, case/ for the hardware variants, frontend/ for the web interface, config_defaults/ for the default settings, a test/ directory, the CMakeLists.txt and Makefile, and the sdkconfig, sdkconfig.defaults and sdkconfig.defaults.esp32 files that carry the ESP-IDF build configuration. The Makefile is the standard ESP-IDF project include, with PROJECT_NAME set to db_esp32 and project.mk pulled in from IDF_PATH, so the build is an ordinary ESP-IDF build and anyone with the IDF toolchain can compile it. ## Conclusion DroneBridge for ESP32 fits a hobbyist or a small drone operator who needs a cheap bidirectional telemetry link rather than a video downlink, and who wants the ESP-NOW range for a swarm setup where a WiFi link would be congested. It is the wrong choice if you need to carry video, since the firmware does not support video encoding, and its range is modest: about 150 metres on standard WiFi and up to 1 km on ESP-NOW or WiFi LR Mode. Before flashing, read the wiring notes about the 3.3V UART and the flight controller power rail, and use the official flashing tool rather than assembling a toolchain yourself. ## FAQ ### What does DroneBridge for ESP32 do and what can it not do? It bridges a drone's flight controller to a ground station over serial-to-WiFi, serial-to-WiFi long range, serial-to-ESP-NOW or Bluetooth LE, carrying MAVLink, MSP, LTM or any other payload. It is a telemetry and low data rate only solution, and there is no support for cameras connected to the ESP32 because it does not support video encoding. ### How far can DroneBridge for ESP32 reach? Up to 150 metres with standard WiFi, and up to 1 km using ESP-NOW or WiFi LR Mode, where the sender and receiver must both be ESP32s with LR-Mode enabled. All modes are encrypted with AES-GCM 256 bit, including the ESP-NOW broadcasts. ### How do I connect a ground station such as QGroundControl to DroneBridge? The ESP auto-sends to all connected devices via UDP on port 14550, and QGroundControl should auto-connect over UDP. You can also use TCP on port 5760. Over UDP the ground station must send at least one packet, such as a MAVLink heartbeat, to the ESP32's UDP port to register as an endpoint, after which you add the ESP32 as a UDP target in the ground station, either manually or through the web interface. ### How do I configure DroneBridge for ESP32 after flashing it? Connect to the WiFi network DroneBridge ESP32 with the password dronebridge, then open dronebridge.local in your browser, or 192.168.2.1 in Chrome, configure the settings and press save. The README notes you may need to disable the cellular connection so the browser uses the WiFi interface. ## Sources - [DroneBridge/ESP32 on GitHub](https://github.com/DroneBridge/ESP32) - [License: Apache-2.0](https://github.com/DroneBridge/ESP32/blob/master/LICENSE) - [Project website](https://drone-bridge.com/) - [README](https://github.com/DroneBridge/ESP32/blob/master/README.md) - [Releases](https://github.com/DroneBridge/ESP32/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dronebridge-esp32