In upcoming software versions, we’re introducing a new feature: the ability to select the “altimeter source” - that is, barometric, GPS_AGL, or fusion. This makes airlogOne the first altimeter/tracker to offer this capability.
To make the right choice for yourself, you need to know a little about the technology, the reasons behind it, and the consequences. I’ll try to explain all of that here over the next few days. Comments, experiences, and suggestions are, of course, welcome to help guide our future software development.
Altitude Source: Why Baro Alone Is Not Enough
When we talk about altitude in skydiving, it sounds simple - but in reality, there is no single “perfect” source.
That’s why this feature introduces Altitude Source: a smart way to choose between Barometric altitude, GPS-based AGL, and Fusion of both.
In our experience, the barometric altitude is the weakest method - even though it is almost always available.
That sounds harsh, but in real skydiving conditions it’s true.
Why Barometric Altitude Fails in Practice
It depends on atmosphere assumptions that are rarely true
Baro altitude is derived from pressure using ICAO standard atmosphere models.
At real drop zones, actual weather almost never matches that model. So what you see is not truly real.
It is highly sensitive to airflow and device position
In fast flight, especially with an arm-mounted altimeter, pressure inside and around the device changes with body/arm position.
So the sensor reacts to aerodynamics, not just vertical position. Filtering helps reducing noise, but creates delay and overshoot
Strong filtering is required to make the baro altitude readable, but delay is unavoidable.
In 1 second you may drop ~50 m. A 1-second lag is already large - and often still not enough to flatten the noise. The result can be design-critical behavior: lag, overshoot, and wrong values when fall rate changes quickly. Nobody talks about this.
Why GPS_AGL (above ground level) Matters
GPS altitude is independent of dynamic pressure effects from fast maneuvers.
That makes it a better physical reference for comparability. GPS altitude is referenced to the sea level - so when on Ground at your drop zone, it doesn't show zero. But thats what you expect from your altimeter, and is also the only information you need when approaching the ground. So we need to compensate for the DZ elevation (its distance from the sea level).
To get a good quality elevation, we cannot use the values the GPS reciver gives when jusr t started - we need to give it a while to collect all necessary satellites.
We therefore gate calibration by GPS vertical accuracy (VACC): only when accuracy is good enough do we accept and store the DZ ground value. This avoids locking in a bad reference and make sure we have a perfect value.
GPS_AGL is the official refernce altitude for special disciplines: Speed Skydiving and Wingsuiting. So here it is a natural decision: use what is required.
GPS Limits: Not Immune to Reception Problems
GPS is physically stable in principle, but it can suffer from reception issues:
- poor sky view
- multipath near structures
- temporary fix degradation
So GPS can be “right model, wrong moment” if signal quality drops.
Why Fusion Is the Best Compromise
Fusion combines:
- GPS-based stability (absolute reference),
- with baro continuity when GPS quality is temporarily degraded.
So users get a practical result: more robust than baro alone, and more operationally stable than pure GPS alone.
Bottom Line
No single sensor wins in every condition.
Altitude Source makes that explicit — and gives users transparency about what they are seeing: BARO, GPS_AGL, or FUSION, including fallback behavior when quality is not sufficient.