Embedded firmware / UAV data link
QSPI-to-Wi-Fi bridge firmware on an ESP32 for a drone data-link moduleTechnical advisory and firmware prototyping
A Wi-Fi data-link firmware prototype for an agricultural drone maker
A maker of crop-protection drones was planning a new drone version with an onboard data-link module with Wi-Fi, built on Espressif MCUs. Its engineers had limited experience with the ESP-IDF platform and doubted whether an ESP32-PICO with a custom pinout could sustain the data rate they needed.
Establish whether the required bitrate was achievable and deliver firmware for a QSPI-to-Wi-Fi bridge with a minimum bitrate of 40 Mb/s. The application had to boot quickly and support over-the-air updates with a factory-reset option, and be documented well enough for the client's engineers to build similar systems themselves.
- Product
- QSPI-to-Wi-Fi bridge firmware on an ESP32 for a drone data-link module
- Buyer
- Drone makers adding an onboard Wi-Fi data link to a new vehicle version
- Engagement
- Technical advisory and firmware prototyping
- Indeema scope
- Driver-level feasibility check, Requirements and system design, Bootloader and bridge firmware, Test setup and demonstration, Firmware delivery tooling, Integration support and follow-up
The product need
What had to become possible
Establish whether the required bitrate was achievable and deliver firmware for a QSPI-to-Wi-Fi bridge with a minimum bitrate of 40 Mb/s. The application had to boot quickly and support over-the-air updates with a factory-reset option, and be documented well enough for the client's engineers to build similar systems themselves.
Ownership, made clear
Where the work started and what Indeema owned
Starting system
A data-link concept
The client had the idea for a new drone version carrying a Wi-Fi data-link module; the bridge firmware did not exist yet.
Espressif hardware
The design used an ESP32-PICO with a custom pinout; the ESP32-C6 was also part of the project silicon.
A candidate network stack
The client had initially considered the Oryx network stack for the module.
Indeema owned
Driver-level feasibility check
Examine the low-level SPI driver in ESP-IDF to confirm the bitrate requirement could be met before writing the application.
Requirements and system design
Write a functional requirements document for the bridge and a system design document so the client's team could set up similar systems independently.
Bootloader and bridge firmware
Implement the bootloader and the bridge application, then add client-side firmware after a change request to enable two-way data transfer between the bridge and the client.
Test setup and demonstration
Build a hardware setup simulating the client-bridge interaction, measure throughput with a high-speed logic analyzer and demonstrate the prototype to the client.
Firmware delivery tooling
Set up a dedicated server for firmware downloads and a GitLab repository with access for the client's team.
Integration support and follow-up
Support the client's engineers in setting up both components, then reduce RAM and flash use, remove unused code paths, tune buffer sizes and review GPIO usage for later hardware revisions.
Worked with
QSPI to the onboard side
The bridge acts as QSPI master and the client side as QSPI slave, with GPIO for user input on both ends.
Wi-Fi to a server
The bridge runs a Wi-Fi access point for configuration and a Wi-Fi station link for data transfer to a server, using UDP.
Logs and updates
UART carries logs to a console; firmware images are served from an NGINX-based download server.
Product constraints
What made the engineering difficult
- 01
Wi-Fi limits throughput
Reaching the required end-to-end QSPI-to-Wi-Fi rate was constrained mainly by Wi-Fi speed, not the SPI bus.
- 02
Custom pinout
The ESP32-PICO used a custom pinout, so the feasibility of the high-speed QSPI path had to be confirmed on that specific setup.
- 03
Boot time and safe updates
The module had to boot quickly and accept over-the-air updates with a factory-reset fallback.
- 04
A new platform for the client
The client's engineers were new to ESP-IDF, so the prototype also had to serve as a reference they could maintain.
Engineering judgement
Decisions that shaped the product
Native ESP-IDF over Oryx
Use the native ESP-IDF network stack instead of the Oryx stack the client first considered, because it sped up initial development and is easier to maintain.
Confirm feasibility at the driver
Study the low-level SPI driver first, so the requirements and design rest on a confirmed bitrate path.
Engineer the dataflow end to end
Tune packet size and a custom QSPI configuration so both the QSPI and Wi-Fi sides run at their maximum practical speed.
Measure on a realistic rig
Validate on a hardware setup that simulates the client side, with a high-speed logic analyzer, before demonstrating.
Document for handover
Pair the prototype with a system design document so the client's team can reproduce and extend the setup.
Delivered product capability
What the product can do
- 01
Bridge firmware prototype
Bootloader and bridge application on ESP-IDF that forwards QSPI data over Wi-Fi.
- 02
Client-side firmware
Firmware for the client side enabling two-way data exchange with the bridge.
- 03
Tested and demonstrated setup
A hardware rig simulating client-bridge interaction, used for logic-analyzer tests and the client demonstration.
- 04
Design documentation
Functional requirements document, system design document and final technical documentation.
- 05
Firmware delivery
A firmware download server and a shared GitLab repository for the client's team.
- 06
Resource tuning
Follow-up work on RAM and flash footprint, buffer sizes and GPIO allocation.
Product change
What changed for the product team
The client gained a working, documented firmware prototype for its data-link module: bridge and client firmware demonstrated on a test setup, design documents, and a repository and download server its engineers could continue from on native ESP-IDF.
For a drone or robotics team that needs to move high-rate data from onboard electronics onto a wireless link, the case shows how to check feasibility at driver level, choose the network stack and hand over a measured prototype rather than an untested design.
- The bridge reached the client's required transfer rate in logic-analyzer tests, at the QSPI level and end to end over Wi-Fi.
- Bridge and client firmware were demonstrated to the client on a hardware setup simulating their interaction.
- The client's engineers received design documents and integration support for working with ESP-IDF and ESP32 SoCs.
Product evidence
A closer look at the product
Technology, in context
C · C++ · Python · ESP-IDF · ESP32-PICO · ESP32-C6 · SPI / QSPI · UART · Wi-Fi Soft AP · UDP · NGINX · GitLab
A comparable product problem?
Drone data-link bridge firmware
Bring the product context, the system that already exists and the engineering decision you need to make.