Under the Hood: Why Skydiving Software Takes Longer Than You Think

If you’ve been checking the airlogONE ecosystem lately and wondering why certain features are trickling out slowly, or why the hardware lineup keeps getting teased without shipping — this post is for you. We’re going to pull back the curtain and explain what’s actually in progress, what’s nearly done, and why building precision telemetry tools for airsports is genuinely, unapologetically hard.

The Dashboard: airlog.app Gets Discipline-Specific

The airlog.app analysis dashboard has grown beyond a generic jump-viewer. We’re rolling out discipline-specific TrackView pages — dedicated analysis layouts built around the unique data signatures of each skydiving discipline. A freefall track looks nothing like a canopy swoop, and the meaningful parameters differ dramatically. Cramming everything into one generic view means everyone gets a mediocre experience. Specialists get specialist tools.

CP View — Live, But Still Cooking

The Canopy Piloting (CP) view is already online. It’s functional, and serious CP jumpers can start loading their tracks right now. That said, we’re calling it “under development” honestly — because the analytical depth we’re aiming for isn’t there yet. CP analysis demands sub-meter accuracy on approach geometry, precise gate timing reconstruction, and approach angle deviation analysis that tolerates neither GPS noise nor timing jitter. If you use it now, you’ll get value. In a few weeks, you’ll get a lot more.

Performance View — Canopy Glide, Seriously Measured

This one is reserved. The new Performance view is built exclusively around data from our upcoming GlideMasterdevice (more on that below), and it’s not something you can meaningfully populate with standard GPS-only track data.

Why? Because real canopy performance analysis — L/D ratio, dynamic sink rate, airspeed-corrected glide, pitch/roll trim behavior — requires sensor fusion from a full IMU plus airspeed measurement, not just position deltas from a GNSS chipset. Deriving sink rate from Barometric altitude in turbulent air near the ground gives you noise, not data. GlideMaster measures the actual aerodynamic quantities. The Performance view is designed to receive and display exactly that.

Logbook Intelligence: Dropzone Database Integration

Manual logbook naming is tedious and inconsistent. We’ve integrated a comprehensive Dropzone database into the platform so that logbook entries are automatically labeled with the correct DZ name based on take-off GPS coordinates. The matching logic uses proximity to known DZ boundaries rather than a simple nearest-point lookup, which matters when multiple airfields are clustered in the same region.

For jumps at unknown or unlisted locations — remote boogies, demo jumps, private land — the fallback behavior is unchanged: the system resolves the nearest populated place from the coordinates and uses that. No gaps in the logbook.

Getting the database right — coordinates, naming conventions, country-specific DZ identifiers — has been a surprisingly large effort. Aviation data is fragmented across national databases, and skydiving dropzones don’t have the same standardized coverage that airports do. We’ve built and validated it manually against real jump data.

Account System Overhaul: Device Claiming, Proper Logins

The old device-to-account linking mechanism was functional but rough. We’ve redesigned the registration and ownership flow from scratch.

Users now register with their own chosen credentials (username + password) through a standard account creation flow. Each physical device displays its unique devID on boot, and users claim ownership of that device by entering the devID in the dashboard. The claim creates a secure server-side binding between the device’s hardware identity and the user account — no shipping paperwork, no manufacturer activation codes, no support tickets.

This also lays groundwork for multi-device accounts, device transfer between users, and fleet management for tandem/instructor setups — all of which are on the roadmap.

New Graphics Engine: CAD-Like Navigation for Jump Analysis

The visualization stack in airlog.app has been rebuilt around a new graphics library with significantly improved zoom granularity and map interaction. If you’ve ever tried to analyze a tight gate approach or a low-pull track deviation in the old viewer and found yourself fighting the zoom levels, this addresses that.

The headline feature is the ViewCube — a navigation widget borrowed from CAD and 3D GIS tooling. It sits in the corner of the 3D track view and gives you one-click jumps to orthographic projections:

North view — see lateral track deviation against the run axis
East view — cross-track displacement, good for spotting wind drift
Birds view (top-down) — the classic overhead track map, but now with accurate scale at any zoom level

These straight-axis views are invaluable for disciplines where canopy positioning matters, but they’re useful for any jumper who wants to understand where the wind actually pushed them versus where they intended to go.

Wind Data: Layered Forecasts, Source Selection

Wind at altitude is never uniform, and treating it as a single vector is one of the larger approximations in skydiving planning tools. The layered wind forecast system in airlog.app now supports multiple data sources — Winds Aloft(the FAA/aviation model) and Open-Meteo (open-access ECMWF-derived forecast data) — with user-selectable sourcing for both the dashboard display and the on-device forecast sync.

The two models have different strengths: Winds Aloft has strong coverage over North America at standard pressure altitudes; Open-Meteo gives better global coverage and higher vertical resolution in its ensemble runs. Letting users pick which source feeds their planning means jumpers can use the model they trust for their region and conditions.

JumpPlanner: Drift Calculation That Actually Respects Physics

This is the feature we’re most excited about for broad accessibility — and it’s available to everyone, registered users and guests alike.

The JumpPlanner is a pre-jump exit point calculator that integrates wind across all available forecast layers from exit altitude down to a selectable opening altitude, then computes the canopy reachable area from that opening point given user-defined glide parameters.

The math isn’t trivial: the freefall drift is computed by numerically integrating the wind vector over each altitude band (weighted by time-at-altitude from a freefall speed model), producing an accurate displacement vector by the time a typical pull altitude is reached. From there, a canopy glide cone — accounting for wind influence on heading vs. groundspeed at each altitude layer under canopy — defines the reachable footprint at the ground.

The result: you set your typical opening altitude, canopy glide ratio and speed, and the current wind profile from the forecast for the selected DZ, and the planner shows you exactly where to exit and how much margin you have. No mental math, no finger-in-the-wind guesses on a new DZ.

Hardware: What’s In Test

GlideMaster — Canopy Performance Analyzer

GlideMaster is in heavy field testing right now. It’s a compact device designed to mount under canopy and continuously measure the aerodynamic quantities that actually define canopy performance: true airspeed (via a MEMS anemometer), altitude, 3-axis IMU, and GNSS — all fused into a real-time data stream that feeds the Performance view in airlog.app. Getting the sensor fusion right at the chaotic dynamics of a swoop approach — high sink rate, fast heading changes, turbulent wake — is not a solved problem. We’re logging lots of test jumps and validating against known performance baselines.

airlogONE Motion — After a Long Wait

This one has been in development longer than we originally planned, and we want to explain why.

The airlogONE Motion started as an iterative hardware revision. It ended up as a near-complete redesign. The requirements grew: waterproofing to a meaningful standard (not “light rain okay”), compatibility with AR glasses, mounting compatibility with existing helmet mounts, a significantly larger battery to support extended sessions, and speech output — not a beep sequence, actual spoken altitude callouts via headphone.

Every one of those requirements individually would be straightforward. Together, they interact. Waterproofing constrains connector choices, which affects the programming and charging interface. AR glasses require new interfaces. Battery size competes with the form factor. Audio output in a sealed enclosure requires careful design that doesn’t compromise the IP rating.

We’re in final integration testing. The sensor stack is complete: dual barometric altimeter, 6-DOF IMU, GNSS, magnetometer — everything is logging and the firmware is running. What remains is environmental stress testing and production preparation. It’s impressive hardware. It needed the time it took.

More Devices

There are additional devices in active development that we’re not ready to talk about in detail yet. What we can say: the product line is expanding beyond what’s currently listed, and the common thread is dense sensor integration with real-time data streaming to the airlog.app ecosystem.

The `.air` Format: One Binary to Rule Them All

All of this analysis capability — CP gate reconstruction, canopy performance curves, fused altitude traces, layered wind correlation — depends on one thing: having the right data in the first place. Which is why we’re formally introducing the .air file format as the native data container for all airlogONE devices going forward.

Why Binary, and Why Now?

Earlier logging approaches either wrote human-readable CSV (large, slow to parse, lossy on floating-point precision) or leaned on fragmented per-sensor files. Neither scales well when you’re logging 10 samples per second across a full sensor stack for a 70-second freefall plus canopy ride. The .air format is a compact, structured binary container — smaller on flash, faster to transfer, and lossless across the full dynamic range of every sensor.

The structure is deliberately layered: a 1024-byte plaintext header sits at the top of every file, human-readable, containing jump metadata — device serial, jump number, date, start position, sample rate, exit and deployment altitudes, freefall time, peak speed. You can read an .air file and immediately know what jump it is. Everything after offset 1024 is binary packet data.

Inside the Packet: 110 Bytes, 10 Hz

Each data packet is 110 bytes at a fixed 5/10/20 Hz sample rate. A sync word opens every packet — the parser can re-lock after any corruption without losing the whole file. The payload covers the complete sensor picture:

Positioning & GNSS: Latitude and longitude at 10⁻⁷ degree resolution (roughly 1 cm at the equator), GPS altitude (MSL) and AGL, horizontal and vertical accuracy estimates from the GNSS receiver, and a GPS quality indicator — so the analysis tools always know how much to trust the position fix at any given sample.

Velocity vector: North, East, and Down velocity components as separate signed integers. This is the raw 3D velocity from the GNSS solution — not derived from position deltas, but the actual Doppler-derived velocity output of the receiver. Heading is stored separately at 10⁻⁵ degree resolution.

Airspeed: True airspeed from the onboard MEMS anemometer (where fitted) — data that GPS simply cannot give you. This is what separates a GlideMaster track from a standard GPS log.

Altitude stack: Three altitude values coexist in every packet — GPS MSL altitude, barometric AGL (from the fused pressure/temperature model), and a fused altitude that combines both. This redundancy is intentional: the analysis tools can select the most appropriate source per use-case, cross-validate them, or detect sensor anomalies by watching the three diverge.

Full IMU: Quaternion orientation (w, x, y, z) stored as 16-bit integers — enough resolution to reconstruct body attitude to the degree. Alongside the quaternion: a static gravity vector (what the IMU sees when stationary, useful for calibration drift detection), raw 3-axis accelerometer in G-force units, 3-axis gyroscope, and 3-axis magnetometer for heading fusion.

Event marking: A single mark byte per packet. The firmware writes specific event IDs at detected exit, pull, and landing — but the field is also user-triggerable from the device button. Useful for marking specific maneuvers mid-jump for later analysis.

Wind Footer: Atmospheric Profile Attached to the Jump

Optionally appended at the end of every .air file is a 304-byte wind footer, identified by a WND magic header. It carries a full atmospheric profile: 49 altitude layers, each storing wind speed, wind heading, and temperature — timestamped to the forecast fetch time. This means the wind model that was active on the device at jump time travels with the file, allowing post-jump analysis to correctly attribute observed drift to the forecast wind layers rather than back-calculating from track data alone.

Smaller, Denser, More Useful

Compared to a CSV export of equivalent data, a .air file for a typical jump — ~70 seconds freefall, ~4 minutes canopy — is roughly 5–8× smaller with no information loss. On a device with 4 MB of available flash, that’s the difference between storing 20 jumps and storing 150+. It also means sync transfers to the app complete in seconds rather than tens of seconds over BLE.

Starting today, all airlog.app analysis tools ingest .air natively. The format is versioned (currently v5.2) and we maintain a public manifest spec — if you’re building third-party tooling or research pipelines on top of airlogONE data, the format is fully documented and designed to be parsed without proprietary libraries.

Why This Takes As Long As It Does

Skydiving hardware and software sits at an uncomfortable intersection: it needs consumer-grade UX (jumpers aren’t embedded engineers), aviation-grade reliability (failures happen at altitude, not at a desk), and sports-science-grade accuracy (the data is only useful if it’s actually right).

Every sensor driver, every forecast API integration, every UI interaction has to be validated against real jump data — which means real jumps. You can’t unit-test a canopy performance analyzer in a lab. You have to jump it, repeatedly, in varied conditions, and compare the output against ground truth.

We’re a small team. We jump the gear we build. That’s both our constraint and our quality filter.

airlogONE — Telemetry for the serious skydiver.