Creating a long range/low latency/ low-cost digital radio link for UAVs & aerial photography

As my „not just another drone“ project grew very large over the last year I decided to split it up into different articles.

This article focuses on the communication link between a drone & ground station. As no affordable industry solution existed in 2016 I started to create my own. After spending months developing the software I decided to release it under the name of DroneBridge. DroneBridge is a set of modules plus an Android app that should help to make MultiWii (Betaflight/Cleanflight/iNav) and MAVLink based flight controllers more suitable for aerial photography. It aims to be a real alternative to solutions like DJI Lightbridge or OcuSync.

DroneBridge runs on a Raspberry Pi and uses the Pi camera module to deliver an HD low latency video feed over more than 2 km. It uses wifi hardware and patched drivers to push the hardware to its maximum. As a receiver, any Linux based computer can be used. It is recommended to use a Raspberry Pi as well since there are ready to use DroneBridge images for it.

While DroneBridge is designed as a UAV data link it is not limited to that single use-case. It is completely open and easy to use (thanks to a common library that handles all of the connection stuff) and perfectly fitted to handle any kind of data. Use it whenever you need high data rates (1-54Mbit), high range (0.5 – 35 km) and low latency (~110 ms for video).

one radio link for all data types

You can find the most current source code of DroneBridge here:

DroneBridge Repository


Update on Beta v0.6 release

The new release will have a common library for C/C++ and Python3 that enables everyone to easily develop their own implementations. The DroneBridge common library gives quick access to the DroneBridgte raw protocol, encryption & software diversity functions used by the modules.

Why build DroneBridge?

The EZ-WifiBroadcast project has come a long way and is very good at delivering low latency video over long distances. Since release 1.5 there also is the possibility to send RC signals. Without this, the user is forced to switch to 5.8 GHz for video transmission to not interfere with the radio control that usually operates at 2.4 GHz. With video over 5.8 GHz, the range gets halved.

However, it got a lot of shortcomings in terms of documentation and usability. Also, I wanted to add new features and allow others to easily integrate their own code etc.

Instead of trying to fix all these issues I decided that it is better to start an entirely new project and rewrite almost all of the code. By sticking to the base image provided by EZ-WBC I can take advantage of all the driver and OS modifications that were made.
The goal is to build a complete system that works with common UAV hardware. It must be easy to configure and use and capable of enabling low latency video, telemetry, RC and MSP/MAVLink two way communication.
An RC implementation that has more than eight channels, works perfectly with popular hardware and mimics a standard radio control including failsafe. Everything should be easy to configure using an app that acts as the UI for the whole system (drone & ground station)

One open system. A cheap and almost ready to fly solution for UAVs of all kind.

DroneBridge for Android: What can it do?

dronebridge app
DroneBridge app with explanations
The DroneBridge android app user interface

Display important information using an android app including:

  • RSSI of drone & ground station
  • low latency live video delivered by the WifiBroadcast project (~112 ms glass to glass latency)
  • Monitor autonomous missions (LTM & MAVLink telemetry)
  • Positions on a map including operator, drone and home point
  • All kinds of telemetry information
  • allows sending any MSP/MAVLink command to the flight controller
  • display battery status (voltage, cell voltage, percent using a battery model)
  • allows changing wifibroadcast settings (frequency, FEC etc.)
  • allows configuring DroneBridge settings

Modular design & custom protocols

Network Configuration
DroneBridge v0.6 System Architecture
USB Configuration

With DroneBridge one can send any MSP or MAVLink command directly to the flight controller. For example commands like:

  • Calibration of MAG and ACC
  • RC
  • Autonomous missions
  • PIDs
  • Rates

Hardware options

DroneBridge features support for the Raspberry Pi and the cheap ESP32.

DroneBridge long range hardware setup
DroneBridge long-range hardware setup

While the ESP32 only gives about 150m of range it is a cheap & easy way of getting started. Its meant for small & light builds and is supported by DroneBridge for Android out of the box. In the future users can create, edit and upload missions via the app.

Get DroneBridge for ESP32 here

DroneBridge for ESP32 hardware setup
DroneBridge for ESP32 hardware setup

Range test

The range was tested using:

  • DroneBridge v0.6 Beta (nightly/developer build)
  • Sender: 1x AWUS036NHA with a 3 dBi omni-antenna
  • Receiver: 1x TP-Link TL-WN722N v1.1 with a 5 dBi omni-antenna
  • Frequency: 2447 MHz
  • Distance: 1,8 km
  • Data rate: 18 Mbit
  • Video/Payload data rate: ~6 Mbit
  • Rural area, direct line of sight, ~same elevation, few valleys in between TX & RX
  • No bi-directional data was sent (RC implementation was not tested)
Terrain profile shows a max. elevation of ~525m and a min. elevation of ~480m. With the valley like profile the wave propagation in open space between GND and Drone can be approximated.


About -75 ~ -77 dBm signal strength depending on the accurate orientation of the receiving antenna. Packet-loss was around one packet per second. With a diversity setup on the receiving side, the packet-loss could be further reduced. Looking at the signal strength I think a few more meters could be gained so two kilometers seem to be the maximum you can get out of the card-antenna combination.


  1. Howdy! This is my first visit to your blog! We are a group of volunteers and starting a new project in a community in the same niche. Your blog provided us valuable information to work on. You have done a extraordinary job!

    • Love to hear that! Keep me posted! I hope I find so time during the next weeks to debug and release v0.3 lots of improvements there.

    • Oh sorry! You are right. I put in an expiration date so people do not use old versions of the app. I will try to upload the most current one by tomorrow. Thanks for pointing that out!
      BTW. I will have some time next week so you can expect DroneBridge v0.3 in short. You can find the most current code under the nightly branch in the repository.

  2. Hello,
    I’m looking forward to discover this new release!
    I tell you again, it’s a great job.


  3. Hi,

    is it possible to use the Software in combination with the navio 2 addon board?

    Thanks and regards

    • Not sure but I don’t think so. As far as I know the Raspberry Pi runs a custom real-time kernel when used with Navio2. I would guess you will have a hard time getting the DroneBridge modules + WifiBroadcast video link running on it. DroneBridge/Wifibroadcast also uses a patched kernel to improve range.

      But you could use the Android app to track your UAV by forwarding the MAVLink telemetry stream to UDP port 1604. In the future you will also be able to create & upload missions

  4. Great project – Congrats.
    Actually I’m comparing your project and three others – original WBC, EZ-WBC and SVPCOM fork of WBC. I try to find easiest one to implement.
    I hope you will evaluate your in future 🙂

    • Stay tuned for v0.6. I am fixing some stuff on DB for ESP32 and then finish the release. It will make DroneBridge the king of the hill when it comes to extendability etc. Performance-wise I do not think there are any differences between the systems. Under the hood they all share the same drivers etc.

  5. Where is the android app located?? And any new rpi images coming ?? I would realy love to see some people running this real world anyone still interested?

  6. Hello! Very nice project, thanks!
    But I am getting ” Beta is expired” in android app (v 2.0.0), couple weeks ago was OK.
    And no new version at github

    • Great work – Congratulations!
      Because your project supports inexpensive hardware – ESP32 support, your project is extremely interesting . Thank you for saving money for drone lovers.
      But I have a suggestion. can you support new hardware – Nvidia JETSON NANO, (please!!!!)? !!! It is an very powerful for money computer for computer vision-ability to expand the drone’s autonomous flight capabilities. Sorry for my english!
      Many thank!

    • Thanks a lot. First of all, never excuse your english. It’s all good 😉
      The Jetson Nano is amazing yes. I was thinking about supporting it but I never had an actual (personal) use case. So spending the time and money on it would not make sense for me.
      However, I think it is not too hard to get it running. You would need to replace the parts of the software that rely on Raspberry Pi firmware functions (capturing video, displaying video, OSD) and you are good to go. On the air side this would only mean that you need to replace the call to raspivid by an equivalent gstreamer (or something else) call. You need to end up with a raw H264 stream. That one will just be passed on to the video module like we do it now.

    • Video is independent from the FC firmware. LTM telemetry is supported by the OSD. So yes. But support is deprecated, so no new features and only minimal fixes

    • Thank you for your answer. So I can get the Sensor Data from the FC to the Pi. But can I also control the copter over the Pi?

    • Sensor data = Telemetry
      Control = MSP with Betaflight

      Control via MSP is supported. Via a second serial connection to the FC you can get LTM telemetry which is sent down to the ground and rendered by the OSD. But you can do something else with the data as well. Just integrated into your code. Telemetry via MSP (1 serial connection for Control&Telemetry) is not supported by default. You would need to write/modify your own applications, in which you can use the DroneBridge library to transmit the data.

  7. Hello.
    Beautiful project!
    I am assembling dronebridge with raspberry pi zero (AIR) + rasberry pi4b (GND)
    It is possible to implement on the AIR raspberry pi zero, the reading of
    1) i2c imuMPU9250 + BMP280 i2c
    2) rs232 gps NEO-6M
    See them on DroneBridge android app user interface.
    Thanks Wolfgang.

    • You can of course write your own apps that run on the Pis and use the DroneBridge library for transmission between GND & AIR. Unfortunately it is not possible to display custom data within the Android app. It is on my table but no idea when it is integrated.

  8. Thank you for the advice. I am a Windows user (but I can install linux on my PC) and I am not a programmer, so I do not really understand how to install DroneBridge on Jetson Nano. In return, I’m quite hard-working and have time.
    Can you give us specific instructions on how to do this for orther Linux system?

    • Yes, but you will need additional hardware for adding a second camera. You will also need to implement the code for switching yourself since I do not have any hardware for testing.

  9. Hello. i flashed the image on the sd cards. now im booting the gnd and air pi. everything seems okay but they dont connect to eachother and i dont get a video signal. can somebody help me?

    greetings from Germany

  10. I had some problems with getting the two sides talking also but now transmitting video.
    Here are some things to check:
    Are you using higher output USB power supplies? If the current capability is below 2 amps, that is not enough.
    Are you using the recommended Radios. These two pairs of radios work:
    1 pair of Alfa Networks: AWUS036NH chipset: Ralink RT3070
    1 pair of Alfa Networks: AWUS036NHA chipset: Atheros AR9271
    Do you have a Raspberry Pi camera installed on the Air side? The camera tells the Pi that it is the Air side unit.
    Do you have a monitor connected to the HDMI output of the ground unit? This displays the OSD and video

  11. Hey Wolfgang! I’ve been working on drones in my lab for 5-6 years now. We’ve never really focused on the communication link aspect, so we’ve always bought RFD900s and similar stuff. But we’ve reached their limit, we need a lower latency link. However, not for a UAV’s link to the ground station, but to another Pixhawk running Ardupilot on a moving vehicle.

    Range is not an issue in our case, but limiting the added weight to our drone is important, hence why we’re leaning towards using ESP32. I’ve never used an ESP32, and I’m finding so many contradicting information online. I was wondering if I could poke your brain and get your opinion on what would be the best way to achieve this?

    Basically, I’m looking to create a bidirectional Mavlink link between 2 Pixhawks using 2 ESP32.
    Is DroneBridge the right solution for me? I know DroneBridge is meant to be installed on the drone-side, and then a GCS can connect to the ESP’s generated wifi. My case is going to be different. I’ve also heard of ESP-NOW, which seems promising, but the packet size of 250 bytes is limiting. The drone actually sends RTCM data (received by another link with an RTK base station) to the vehicle, and the vehicle sends its position, velocity and heading back to the drone. I’ve heard that RTCM packets can be up to 1023 bytes long (am I wrong?).

    I’m pretty much lost and haven’t found many resources covering these issues. I’d be very glad if I could have your opinion on this, and discuss some more if you have the time. Thanks!

    • Hi John,
      I do not think that DroneBridge is the right solution for you, since the ESP32 implementation is not optimized for such a scenario. It is optimized for Range & Bitrate. However, you could still try it out, by using one ESP32+DroneBridgeForESP32 on Drone1 and another ESP32 in Drone2 running in station mode with a custom application that connects to Drone1. That way both drones will be able to communicate with each other via Wifi. Maybe that already does the trick for you. I cannot say anything about the latency here.
      An alternative would be the mentioned ESP-NOW as a protocol, but I do not know anything about latency there (internet says ~2ms-4ms). It looks like you will have to split the RTCM packets (ESP32 firmware might be able to do that for you). That will lead to more delay and packet loss will have a bigger impact. You will also have to implement it yourself. You might be able to modify the DroneBridge for ESP32 code.
      Another solution might be a LoRA based link. Those are also available in small form factors and offer good performance. LoRA is optimized for range.

      As you can see there is no perfect solution. You will have to do some testing and implement stuff yourself.
      I would first try and see if a simple Wifi bridge with two ESP32 works. Use DroneBridge for ESP32 on one drone and connect with the other drone to the access point. That would be the lowest effort and will lead to a stable link, as long as the two drones are close to each other (~100m)
      If that does not work switch to ESP-NOW. This will require low implementation effort, since you can use the code from the Wifi implementation. You will just have to change a few things.
      If all that does not do the trick you might be looking into other radio links like LoRA etc. ExpressLRS uses LoRA for example, but does not really offer a back channel.

  12. Hi,

    DroneBridge for ESP32 is really useful. Figuring out the TX/RX pin numbers for different ESP32 board with messy or nonexistent documentation can be cumbersome, though. How about starting a collection of working configs on the GitHub page? Here’s what worked for me to connect a Pixhawk 32 v6:

    Hardware: D1 Mini ESP32 WiFi + Bluetooth:
    UART TX PIN: 3
    UART RX PIN: 1
    UART BAUD: 1000000 (haven’t tried to go higher yet, seems to work fine thus far incl. paramter transmission and telemetry with minimal latency)

    • Hi! Almost any pin on the ESP32 can be configured as TX/RX. I am not sure about performance when non-native UART pins are used, but since the telemetry link is no where near maxing out the ESP32 UARTs performance it should be no problem at all. I would recommend to pick two pins that seem to be fit for the job and then set those in the config.

Leave a Reply

Your email address will not be published. Required fields are marked *