Launch your UAV from concept to sky faster and smarter

Choosing a high-resolution Barometer for Anymah: BMP580

By Aditya

/

April 28, 2025

This is the fourth part of our series on the development of the Wint Anymah flight controller, an ultra-light, compact and high-performance solution designed specifically for the next-generation nano UAVs. Designing a flight controller for compact, agile UAVs is a balancing act — finding the right compromise between small-size, high-performance and reliability is a challenge. In this blog, we will walk through the details of this process and explain the options we considered, and the approach we followed.

The previous part of this series talked about choosing an IMU which was small, and had low-noise and low-power characteristics. This part continues from here and goes into the next most important component, i.e. the Barometer.

This sophisticated flight controller is being entirely designed and manufactured in India, embodying our philosophy of "Making in India, Making for the World."

Requirements and constraints while choosing a Barometer

This section goes through the first part of the selection process - listing the requirements and constraints that must be considered while selecting the Barometer and prioritizing them. This was a relatively quick process.

Requirements

  • Good thermal stability to ensure reliability through different climates and seasons, especially in longer missions (this automatically implies that the Barometer must include an internal thermometer for accurate temperature compensation).
  • High-sampling rates, atleast 250 Hz to live-response to disturbances, especially in fast maneuvers.
  • Fast SPI interface, allowing fast data transfer from the Barometer to MCU (as compared to UART or I2C). Using SPI also allows the use of DMA, which doesn't work as well with other protocols.
  • Low power consumption, to allow greater flight time, especially in nano drones with smaller and lighter batteries.
  • Good documentation and support to facilitate platform-agnostic software driver design and implementation.

Constraints

  • The sensor must have reasonable cost & availability.

The constraint listed above seems quite obvious, but presents an important point. An exotic cutting-edge sensor would be overkill for our purpose, and we needed reasonable performance at reasonable pricing with strong availability, not a research platform, for a production-grade flight controller.

Vendors and options considered

Having listed the requirements, we finally narrowed down the search to 3 vendors - STMicroelectronics, Bosch & TDK. Each were popular silicon vendors with a strong supply-chain, support, documentation and portfolio of IMUs (and other sensors too).

Finally, we chose the BMP-580 from TDK Invense, as we found it to have the best combination of temperature stability, data-rate and power consumption. Here are all the options that we considered and why we rejected them -

  • ICP-20100 from TDK - This was rejected due to its lower pressure range (30-110 kPa vs 30-125 kPa for the BMP-580) and lower data-rate. In most other aspects, it was fairly similar to the BMP-580.
  • LPS22HH (consumer series Barometer) from STMicroelectronics - This was quickly rejected due to its maximum data-rate of 200 Hz. which made it unsuitable for nano UAVs which can perform high-speed maneuvers and need a higher sampling rate. Furthermore, its power-consumption was also inferior to Bosch's offerings.
  • BMP-390 from Bosch - This was quite similar to the BMP-580 (as both were from the same vendor), but had greater noise and a higher power-consumption, due to being slightly older.

Designing an evaluation board

This section walks through the process of creating an evaluation board for the BMP-580, which is the next step after selecting the sensor. It would have been better to buy a pre-existing evaluation board, but we decided to make our own to verify the decoupling capacitors and the SPI interface routing ourselves.

The final board (labelled) looks as shown -

BMP-580 Evaluation Board (PCB Breakout)

The evaluation board was designed to be simple, breadboard-friendly and re-usable beyond this project. It has the following features kept fairly simple and had the following features -

  • Dedicated voltage regulator and power LED - We used the LD39200 voltage regulator from ST, which is an ultra-low drop linear regulator with reverse current protection. The LD39200 has anadjustable voltage output and can supply a generous 2A. Additionally, it has a voltage drop of merely 0.13v at maximum load. Most importantly, the regulator has a wide input range, from 1.25v to 6v. In our case, we wanted 3.3v, and could power the board from an external 5v or 3.3v source without worrying about the sensor burning.
  • Separate headers for I2C, SPI and interrupts - The purpose of the breakout board is to break out the pins of the IC for convenient use. We decided to create separate rows for I2C and SPI on either side of the board, and make it breadboard friendly. This makes it much easier to evaluate the sensor than if the pins were shared and only on one side.
  • I2C address selection headers - These allow us to use shunt connectors to conveniently select the I2C headers, without messy wiring or ad-hoc soldering.
  • Pull-up resistor on Chip-Select and I2C Pins - This removes the need for external pull-up resistors, thus reducing evaluation time.

Apart from a higher data rate that other sensors, the BMP-580 also has oversampling, which allows decreased noise at high-data rates, at the cost of a slight increase in power-consumption. This is crucial in nano drones, where high-speed maneuvers and high proximity between the Flight Controller and Propellers causes high noise.

A potential improvement in the breakout would be the addition of the Adafruit Qwiic connector, which would make it compatible with a vast ecosystem of sensors.

This evaluation board follows the same form-factor (shape and connectors) as the ICM-45686P. This is an intentional design choice to make the wiring on a breadboard simpler (SPI is a bus and having all the connectors on the same side is convenient to work with). This also makes the development faster.

Being a Barometer, it is helpful to be able to mount it on a fixed base (breadboard) with the other sensors, giving a stable and shared reference frame for all readings. If the pins were instead on a single side (requiring direct wiring to the MCU), the sensor would be dangling from wires, making the readings inconsistent and impossible to interpret.

Creating a platform-agnostic software driver

After designing the physical breakout board, we needed a robust software foundation to maximize the potential of the BMP-580. Our goal was to create a driver that wasn't just functional but adaptable across multiple platforms and projects, and able to provide the AGL and MSL altitude. This approach aligns with our philosophy of building reusable components that provide long-term value.

Architecture for flexibility and performance

Similar to our ICM-45686P driver, the BMP-580 driver architecture also provides a layered approach with clear separation of concerns -

The key to platform agnosticism lies in our Hardware Abstraction Layer (HAL). We designed an interface structure that defines the essential communication functions -

And functions of the following form -

The init, configuration and data functions implement the logic of executing a transaction with the Barometer, by using the functions pointed to by the interface structure. This allows the consumer of the driver to implement the communication for their platform and communication protocol (SPI or I2C).

This structure allows us to inject platform-specific implementations while keeping the core driver logic consistent. Whether we're running on an STM32, ESP32, or any other microcontroller, the driver's behavior remains predictable.

Handling DMA in a cross-platform mannger

For high-speed sampling applications like flight control, Direct Memory Access (DMA) is crucial. Our driver provides both polling-based and DMA-based reading modes.

Specifically when using DMA, the driver provides a function to start the DMA process, and another function which to be called on the completion of the DMA transfer. This allows the DMA read functionality to be performed in a cross-platform manner.

Instrumentation

Beyond simply using the sensor, the driver also includes instrumentation to provide insights into usage and speed-up debugging in case of errors or unexpected behaviour -

  • Performance metrics tracking - Our driver maintains statistics on communication speed and failure rate.
  • Self-diagnosis - Our driver implemented self-test functionality which works with the built-in self-test functionality of the sensor to give exceptional reliability.

Evaluation process

After finishing the hardware and software development process, the next steps are to thoroughly use the sensor in dynamic environments (such as stationary, vibrating, oscillating etc.) and test various sensor fusion algorithms.

The first part of the evaluation process is to individually test the breakout board and software driver with the STM32F4 MCU breakout board (from the previous part), similar to unit testing in software development. Once proper functioning has been determined, the next step is to place the sensor in various environments (static, vibrating, oscillating etc.) and characterize its tolerance, power-consumption etc.

After testing the sensor individually, the next step is to combine data from multiple sensors (multiple IMUs as well as other kinds of sensors) to characterize sensor fusion algorithms, which will be covered in a separate blog.

Conclusion

The BMP-580 has emerged as a suitable choice for our nano flight controller, offering great performance and efficiency whilst being low-cost and small. We will use it on our flight controller to provide relative altitude measurements and improve the resilience of our sensor-fusion algorithms.

The next step involves choosing and evaluating a magnetometer (3-axis digital compass), which will follow a similar process to the IMU and Barometer.

Through this blog, we hope to build transparency with our community by sharing our development and engineering process. If you have any thoughts or suggestions, you can share them with us at aerowint.com/contact, or write to our founders directly at aditya@aerowint.com or milind@aerowint.com.