Automatic OOOI times: why flight-tracking data gets them wrong

Short answer: a service that derives your OOOI times from public ADS-B or flight-tracking data can usually estimate your airborne times (OFF and ON) within about a minute, but it cannot truly measure your block times (OUT and IN). ADS-B carries no gate field, and a transponder starts and stops transmitting by pilot procedure, not when the aircraft actually leaves or reaches the blocks. So any product reading your OOOI off the network is guessing, and on IN it guesses late. KármánLogs reads your real times from your own phone instead.

What OOOI is, and why it is normally a measurement

OOOI is four events: Out (off the blocks), Off (wheels up), On (wheels down), In (on the blocks). In airline operations these are not guessed. They are produced by the aircraft itself: onboard ACARS detects each one from real sensors, the parking brake, the cabin doors, and the weight-on-wheels squat switch, and reports them to the airline. The gate times you see on a ticket trace back to that sensor data, distributed through industry feeds. They are measurements.

That matters because the whole value of OOOI is precision. Your night time, your takeoffs and landings, and your block-to-block totals are only as accurate as the four times underneath them.

What ADS-B actually broadcasts

ADS-B Out is a surveillance signal. It broadcasts your position, altitude, velocity, identity, and an air-or-ground status, about once a second while you are moving or airborne (14 CFR 91.227). What it does not contain is any gate or block field. There is no "left the blocks" message and no "reached the gate" message anywhere in the data. Block times simply are not in there, so they can only ever be estimated from the signal, never read from it.

Where ADS-B-derived OOOI breaks down

The failure is not uniform. It is worst exactly where it matters most.

IN (block arrival) is genuinely unreliable. Pilots are taught to keep the transponder transmitting through the entire taxi-in and to switch it off only after arriving at the parking spot or gate (FAA AIM 4-1-20). So the last ADS-B message you send is not block-in, it is shutdown at the gate, which happens after the whole taxi-in. At a large airport with a long taxi, that is many minutes late. An app deriving your IN time from "last seen on ADS-B" is systematically biased late.

OUT (block departure) is only a rough approximation. Transponder transmission tends to begin around pushback, so the first surface message lands near your OUT time, often within a minute. But it is an inference about when the transponder was switched on, not a measurement of leaving the blocks. The regulations even require ADS-B Out "in the transmit mode at all times" while the equipment is powered (14 CFR 91.225), so a powered aircraft can be transmitting well before it moves. The gate line triggers nothing.

OFF and ON (takeoff and landing) are the strong cases, but still inferences. A tracker estimates them from your trajectory and the air-or-ground status bit. On retractable-gear aircraft that bit is driven by the squat switch, which is genuinely useful. But coverage from ground receivers is weakest at low altitude near runways, which is precisely the takeoff and landing regime, and fixed-gear aircraft fall back to a tuned groundspeed threshold that can lead or lag the actual moment. Good, usually within a minute, but not a stamped event.

There is also the messy real world: transponder behavior is inconsistent and sometimes simply off. The FAA has documented airports logging around 20 transponder-off events per day from aircraft that should have been transmitting (SAFO 15006).

Does ATC track your OOOI?

No. OOOI is an airline operations concept, not an air traffic control one. ATC uses ADS-B and radar for separation and surface movement, it does not compute anyone's block times. The companies that publish OOOI-style times are flight trackers, and the honest ones tell you where the numbers come from: real gate times are "what is printed on airline tickets," supplied by the airlines, and when those are unavailable the tracker falls back to runway times with the caveat that "there can be a significant difference in gate and runway times due to long taxi times" (FlightAware FAQ). The FAA's own performance database sources gate-out from airline OOOI feeds or estimates it (FAA ASPM definitions). In other words, the accurate gate times come from the aircraft's sensors through the airline, not from ADS-B.

How KármánLogs does it instead

KármánLogs does not pull your times off the network. It detects them on your iPhone, from inside the aircraft, using the phone's own GPS (with a barometric cross-check at takeoff) and the airport database built into the app:

• OUT when your aircraft actually starts moving on the airport surface.
• OFF when you actually become airborne.
• ON at touchdown.
• IN when your aircraft comes to a stop at the destination.

Because your phone is on board and measuring your aircraft continuously, there is no ground-coverage gap and no dependence on when a transponder happened to be transmitting. It is opt-in, free for everyone, and your location never leaves the phone, nothing is uploaded (see where your data is stored). Those four times then feed the app's automatic night, takeoff, and landing math, the same engine described in how OOOI times power automatic logging. Prefer to enter your times yourself? You can, and the math is identical.

The takeaway: be skeptical of any logbook that fills in your OOOI from public flight data. It is estimating, and estimating worst on the block times your logbook actually records. Times measured on board, from your own aircraft, are the ones worth keeping.

Want the basics first? Start with logging a flight in seconds.

This guide is educational and summarizes how these systems work as of the date above. Always verify against the current 14 CFR text and FAA guidance when in doubt.

Still need help? Email support@karmanlogs.com.