Choosing a robust, high-performance barometer for Mahymah: LPS22HH
By Milind
/
July 31, 2025
This is the fourth part of our series on the development of the Wint Mahymah flight controller, a powerful multi-domain system designed for demanding next generation UAVs. Building a flight controller for such diverse environments is a careful balancing act — combining high computational performance, precise sensing, and robust architecture within a compact and reliable design. In this blog, we'll walk through the key design choices, the trade-offs we evaluated, and the approach we ultimately adopted.
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 up to 200 Hz to support responsive altitude tracking during fast or dynamic maneuvers, while still maintaining real-time compatibility with the control loop.
- 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 contributing to overall system efficiency and longer mission endurance in battery-constrained platforms.
- 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 Barometers (and other sensors too).
Finally, we chose the LPS22HH from STMicroelectronics, as we found it to have the best combination of temperature stability, pressure range, 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 26-126 kPa for the LPS22HH) and lower data-rate. In most other aspects, it was fairly similar to the LPS22HH.
- ICP-10111 from TDK - This was quickly rejected due to its limited sampling rate and lack of oversampling or filtering options, which made it unsuitable for high-speed control loops. Additionally, while it offered excellent power efficiency, its dynamic performance and noise handling were inferior compared to other available options.
- BMP390 from Bosch - This was quite similar in function to the LPS22HH but had higher noise, a shorter pressure range, and slightly higher power consumption. The LPS22HH offered better shock resistance, cleaner pressure output, and overall reliability.
Designing an evaluation board
This section walks through the process of creating an evaluation board for the LPS22HH, 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 -
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.
The LPS22HH also supports oversampling, which helps reduce noise at higher data rates with only a slight increase in power consumption. This is particularly valuable in high-performance platforms where fast altitude updates are needed during aggressive maneuvers and where aerodynamic disturbances near the sensor can introduce significant pressure 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-42688P. 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 LPS22HH. 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-42688P driver, the LPS22HH 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 manner
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 STM32H7 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.
Handling Note for LPS22HH
The LPS22HH is rated for Electrostatic Discharge (ESD)protection up to ±2 kV (HBM), offering basic protection during handling. It complies with JEDEC J-STD-020 and JESD22-A113 for moisture sensitivity and reflow soldering, supporting peak reflow temperatures up to 260 °C. The device is also highly durable, capable of withstanding mechanical shocks up to 22,000 g along any axis.
Conclusion
The LPS22HH has emerged as a suitable choice for our flight controller, offering reliable performance and low noise in a compact and efficient package. We will use it to provide accurate relative altitude measurements and strengthen the robustness of our sensor-fusion algorithms during dynamic flight conditions.
The next step is to integrate the current sensors (along with others we've already evaluated) into a prototype and begin initial testing, calibration and tuning of the full system.
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 milind@aerowint.com or aditya@aerowint.com.