ADS-B Data Feeds for Flight Operations: Acceptance Tests

Executive Summary

An ADS-B data feed for flight operations can help an operations control center (OCC) or flight department see where an aircraft was last observed, annotate a dashboard, and trigger a review when a track becomes stale. Suitability depends on the intended decision. A map tile that is useful for awareness does not, by itself, establish the flight's identity, current position, or compliance with an operator's approved flight-following and dispatch procedures. In the United States, Part 135 has explicit flight-locating procedures for flights without an FAA flight plan, while Part 121 domestic rules assign operational-control responsibility to the certificate holder and flight-progress monitoring to the dispatcher ^{[1] [2]}. A third-party track is not a substitute for those procedures.

The central procurement issue is the data contract, not access to an endpoint. ADS-B Exchange's sample separates response generation, cache time, processing time, and seen_pos, the age of the last position, and warns that aircraft fields may be absent ^{[3] [4]}. Its sample labels some clocks in epoch milliseconds, while its version 2 reference and streaming guide describe seconds with millisecond precision. A buyer should require the units and reference clock for the contracted endpoint in writing and test an actual payload before computing age ^{[5] [6]}. Identity also requires reconciliation: a transponder flight ID, registration, 24-bit address, and operator flight record are different keys, and the FAA identifies flight-ID mismatch as a US surveillance concern ^[7].

There is no defensible universal latency or coverage number for an operator's routes in the sources reviewed. The FAA explains that ground reception varies with altitude and terrain; OpenSky notes that low-altitude observation needs nearby receivers ^{[8] [9]}. Published vendor update statements describe products or layers, not the age a specific OCC will see. The recommended acceptance test is therefore a sampled flight-minute availability ratio: usable position minutes under an operator-defined freshness threshold divided by eligible flight-minutes. Record geography, ground and airborne phase, source type, identity confidence, gaps, and fallback outcomes. This is a proposed test method, not an industry benchmark.

Commercial rights and privacy are separate gates. The FAA says US ADS-B broadcasts may be received with ordinary equipment; a Privacy ICAO Address (PIA) changes the address relationship, while Limited Aircraft Data Displayed (LADD) does not alter the broadcast ^{[10] [11]}. ADS-B Exchange distinguishes personal, noncommercial community access from enterprise subscriptions, and other providers specify differing commercial, redistribution, and retention terms ^{[12] [13] [14]}. Select a feed only after the vendor documents field semantics, test-route evidence, rights, and a degraded-mode plan. Build an integration layer when the operator must join several sources and preserve a reviewable event trail; purchase an established feed or operational service for the source capability itself.

Introduction and Background

Automatic Dependent Surveillance-Broadcast (ADS-B) Out broadcasts aircraft position and other data for reception by ground stations and other aircraft. The FAA describes broadcasts about once per second, but that rate is an airborne transmission characteristic, not an OCC API service-level promise ^[15]. A commercial feed adds receivers, ingest, matching, caching, delivery, policy, and often other sources. FlightAware, for example, describes a Firehose stream combining radar, ADS-B, multilateration, datalink, status, and surface positions ^[16]. Thus a procurement label such as "ADS-B API" does not tell a buyer which observation produced a displayed coordinate.

This report addresses airline and charter OCC teams and business-aviation flight departments integrating a third-party feed for ground situational awareness, dashboards, or exception monitoring. It does not specify pilot surveillance, air traffic control separation, or approval of a flight-following system. The appropriate confidence level rises with the consequence of an action: a dispatcher viewing a broad traffic picture may tolerate an unknown identity; an alert that escalates an overdue company flight should require a known flight match, age, and documented fallback. ICAO's aircraft-tracking framework discusses monitored position reports and action on missed reports for specified operations; its reporting interval cannot be imported as a generic web-feed freshness threshold (Source: www.icao.int) (Source: www.icao.int).

The market offers different data shapes. ADS-B Exchange publishes an aircraft-oriented sample and a version 2 field reference. Cirium documents flight-status fields such as scheduled, estimated, and actual times, and a separate flight-track interface ^{[17] [18]}. AirNav Radar says its API blends ground and satellite ADS-B with airport, airline, and other data ^[19]. These are product descriptions, not comparative performance results. The buyer's question is whether a contracted feed consistently supports the intended workflow on its own fleet and routes, with permission to store and display the necessary records.

LANDING.AERO's stated role is custom flight-operations software and data integration, including dashboards and bridges between existing systems (Source: www.landing.aero) (Source: www.landing.aero). That perspective is relevant to the integration decision, while the feed and any approved operational-control service remain separate procurement choices.

Key Changes in Evaluating a Feed

From a map point to a decision record

An aircraft icon should be treated as a record with provenance: the provider, source type, address or identifier, position, position time, delivery time, and matching state. ADS-B Exchange's sample warns that its response may mix adsb_icao, mlat, and tisb source types ^[20]. Its reference defines multilateration (MLAT) as a position calculated from arrival-time differences at receivers, and Traffic Information Service-Broadcast (TIS-B) as traffic information about a non-ADS-B target ^{[21] [22]}. The downstream application should preserve those labels; a blended track should not silently appear to be an aircraft-originated ADS-B position.

From one timestamp to several clocks

A feed can contain aircraft message time, receiver time, source processing time, cache time, and the consumer's own receipt time. ADS-B Exchange says its streaming timestamps are stamped by receivers rather than aircraft ^[23]. OpenSky's state vector separately records time_position, the last position update, and last_contact, the last valid message contact ^{[24] [25]}. A fresh message without a fresh position should not reset a position-age alert. Conversely, a delayed API response should not make an older coordinate appear current merely because its HTTP response was just received.

From a single identifier to a resolved flight

The 24-bit aircraft address, call sign or flight ID, registration, and scheduled flight instance answer different questions. ADS-B Exchange defines flight as a call sign, name, or registration-like eight-character field, while its r field is registration pulled from a database ^[26]. FlightAware warns users to treat its flight-instance ID as opaque ^[27]. Cirium permits a status lookup by carrier, flight number, and date, or a unique provider identifier ^[28]. A responsible integration stores each original key and the match decision separately, with a confidence state such as confirmed, candidate, or unresolved. An exact flight-ID match matters in the US ADS-B context according to the FAA; it should never be inferred from a similar-looking label alone ^[7].

From endpoint access to a permitted workflow

A working developer key says little about commercial use, storage, or redistribution. ADS-B Exchange describes community API access for personal and noncommercial use and enterprise data as ongoing subscriptions ^{[12] [29]}. OpenSky says commercial or operational REST API use requires written permission and a license ^[30]. A proof of concept should therefore test the contracted product, data layers, rights, and rate limits, with a written transition to production. The operator should also distinguish its internal dashboard from customer-facing or partner redistribution, because the rights may differ by audience and data layer.

The Data Contract: Identity, Age, and Missing Fields

The first acceptance artifact should be a field-level contract. It should say which timestamps are generated by which system, whether units are seconds or milliseconds, how nulls and absent keys differ, and whether a position is measured, multilaterated, rebroadcast, or estimated. ADS-B Exchange's sample defines seen_pos as seconds since last position update and says all aircraft fields are optional when unavailable ^[31]. Its version 2 reference separately defines seen as age since any message ^[32]. OpenSky similarly says time_position can be null when no position report has arrived in the prior 15 seconds, even while last_contact can update from another valid message ^{[33] [25]}.

Table 1 is a proposed minimum contract for a ground operations application. The examples are documented field semantics; the acceptance rules are operator decisions.

The table implies an important control: age is computed at the consumer, with the contract specifying which source clock to trust. For example, if a record reports seen_pos, the adapter should carry both the provider value and its own received-at time. If the source supplies only a current-looking response clock, the adapter cannot reconstruct position age. The ADS-B Exchange streaming guide explicitly derives absolute position time by subtracting seen_pos from now; its endpoint-specific units still require confirmation against live contracted payloads ^{[37] [6]}.

Identity should be reconciled against the operator's own flight record, not used as a join key without inspection. A tail may operate successive legs; a call sign can change; a position can be available while a scheduled flight match is absent. OpenSky says its tracking data is not currently mapped to commercial flight schedules ^[38]. Cirium separates schedules, flight status, and flight track APIs ^[39]. These differences support a practical model with separate aircraft, flight leg, and observation entities. Keep the original provider payload, matching rule version, and human override in an audit trail. This is a design recommendation, not a claim that a vendor supplies those controls.

Coverage and Freshness on the Operator's Routes

No coverage graphic can substitute for a trial on the actual operation. The FAA says ground ADS-B receiver range varies with aircraft altitude and terrain, as well as transmitter and receiver characteristics ^{[8] [40]}. Its US coverage maps show estimates at several heights above ground, which illustrates why a cruise track says little about a low-level or ramp segment ^[41]. OpenSky similarly says low-altitude monitoring requires both nearby receivers and low-flying traffic, and its map excludes satellite data ^{[9] [42]}. Geographic maps should therefore be treated as hypotheses to test, with the provider's data-layer definition attached.

The trial should stratify by route, altitude band, ground phase, time of day, fleet type, and source type. Include remote stations, oceanic segments, high terrain, airport surface movement, and handoffs between ground and satellite reception where relevant. FlightAware describes distinct terrestrial and satellite ADS-B subscription layers and different surface coverage by area ^{[43] [44]}. Aireon describes a space-based ADS-B reception approach; that does not establish that a buyer's chosen API exposes a particular space-based layer or gives a particular age ^[45]. Ask the vendor to name the data layer in the quote and in each sample record.

Feed latency should be decomposed into observation-to-receive, receive-to-provider, provider-to-consumer, and consumer processing. The FAA's approximately once-per-second ADS-B Out description refers to broadcast, not the final dashboard ^[15]. FlightAware claims terrestrial positions multiple times per minute over land and a separate once-per-minute satellite layer; these are vendor descriptions, not route-specific API measurements ^{[46] [47]}. Aviation Edge says its Flights Tracker API updates around every five minutes, while its Schedules API updates around every fifteen; that is a product statement about update cadence, not proof of age for one flight ^[48]. The procurement test should measure actual delivered position age and gap duration at the application edge. ADS-B data feed reliability testing should also record duplicate records, timeouts, reconnects, and time until the degraded-state label appears.

A missing point is not automatically a missing flight. A receiver gap, absent field, unrecognized identifier, source transition, cache delay, or exhausted entitlement can yield different symptoms. Aviation Edge says its tracking and airport-schedule services use different sources, so their results may differ ^[49]. AirNav Radar says its on-demand responses stop when monthly credits run out ^[50]. Distinguish no observation, stale observation, failed delivery, failed match, and not licensed in logs and user interface. Each state calls for a different diagnosis and fallback; collapsing them into an empty map marker hides useful evidence.

Implementation Considerations and Process Changes

Choose the workflow before a freshness threshold

A single freshness threshold for every screen is hard to defend. Define the decision first, then a maximum position age, a maximum continuous gap, and the consequence of missing data. A passive map may display an older point with a prominent age label; an exception alert may require a fresher point and a confirmed flight match. The threshold must be documented as an operator acceptance criterion, measured in a representative trial, and revisited when routes or source layers change. It is not a regulatory number inferred from ADS-B transmit rate or ICAO aircraft-tracking intervals ^[15] (Source: www.icao.int).

Reconcile with approved records and fallback sources

For US Part 135 flights without an FAA flight plan, 14 CFR 135.79 requires certificate-holder procedures for locating each flight and timely notification if overdue or missing ^{[1] [51]}. For US Part 121 domestic operations, 14 CFR 121.533 assigns operational control to the certificate holder and monitoring duties to the aircraft dispatcher ^{[2] [52]}. These are jurisdiction-specific rules, not instructions to replace an approved procedure. An OCC can use a third-party track as an additional cue while the responsible people follow their manuals, operations specifications, and approved channels.

A fallback design should list each alternate source and its authority for that workflow. EUROCONTROL's Network Manager business-to-business service offers flight-plan and flight-data retrieval to eligible aviation stakeholders, while its Flight Information Collaborative Environment publishes updates to subscribers (Source: www.eurocontrol.int) (Source: www.eurocontrol.int). Cirium's status API includes scheduled, estimated, and actual times, which can corroborate leg status but are not coordinates ^[17]. SITA describes aircraft-to-ground communication through cellular, broadband, and Aircraft Communications Addressing and Reporting System (ACARS) networks, where the operator has access and rights (Source: www.sita.aero). The fallback matrix should distinguish a position source from a plan, status, or direct aircraft report.

When two sources disagree, the integration should preserve both observations and surface the discrepancy. Establish a rule for source priority by field and phase, record which observation informed an alert, and require a human review path for consequential exceptions. An operational data hub reference from AWS includes third-party global flight tracking beside other operational data and stores original ingested data in an immutable form; that is an architecture example rather than evidence of any operator's implementation ^{[53] [54]}. A replayable log lets teams reproduce why a dashboard showed a point or why an alert fired.

Build or buy the integration layer

Buying a licensed feed supplies collection, processing, and delivery that would be costly to reproduce across regions. Building a thin integration layer can still be justified when an operator must join feed observations with its fleet roster, flight schedule, alert workflow, and audit record. Compare total costs for feed rights, integration, monitoring, support, replay, identity resolution, and future provider changes. A custom software studio can build this layer around an existing operation; LANDING.AERO states that it builds tailored integration and dashboards rather than an off-the-shelf operations platform (Source: www.landing.aero) (Source: www.landing.aero). The operator still needs a qualified data provider and its approved operational-control or flight-following service where required.

Privacy, Licensing, and Provider Procurement

ADS-B is a broadcast technology, but public reception does not grant every downstream use right. The FAA says an aircraft using a Privacy ICAO Address still broadcasts data receivable by off-the-shelf equipment, and its Limited Aircraft Data Displayed program does not alter the underlying broadcast ^{[10] [11]}. For a US operator, PIA and LADD should be checked separately in a privacy review. Outside the United States, obtain jurisdiction-specific advice before publishing or redistributing identifiable movement data; this report does not infer a global privacy permission from the FAA page.

The commercial contract should name the legal entity, permitted users, products, data layers, redistribution audiences, storage duration, deletion duties, and handling of privacy requests. ADS-B Exchange says a company project needs a commercial API license even if the project does not make money ^[55]. FlightAware's general terms reserve commercial or distribution use absent an express license, and it says Firehose pricing depends in part on redistribution scope ^{[13] [56]}. OpenSky's terms require written permission for commercial and operational API use ^[30]. Flightradar24's API storage rules limit accumulated raw data to thirty days, a concrete retention term to evaluate before designing a long-lived audit store ^[14]. Do not generalize one provider's terms to another.

Table 2 turns the article's evidence into a request for proposal and acceptance matrix. Each cell is a question or proposed test, not an assertion that a named vendor meets it.

The matrix has no universal pass threshold. A buyer should specify the threshold and denominator before seeing vendor data, then apply the same method to each candidate. Vendor documentation can establish what a field means or a license permits; only the operator's trial can establish whether the service supports its routes and workflows. If a provider offers a combined status and position feed, insist on separate provenance for each component. SITA says its Flight Status API can return a local-airport or full-flight view, and supports sharing private data with approved parties, illustrating why audience and scope must be explicit (Source: www.developer.aero) (Source: www.developer.aero).

Data Analysis and Evidence

As of October 2026, published numerical statements are useful for designing a trial, but they measure different layers. The FAA's once-per-second ADS-B Out description is a broadcast characteristic ^[15]. OpenSky's API documentation says a position timestamp can be null after fifteen seconds without a position report, which is a field behavior rather than a provider service guarantee ^[33]. FlightAware reports generally four to six seconds of MLAT computation and processing delay; this applies to its MLAT process, not its ADS-B API end-to-end delay ^[57]. Flightradar24 says its system updates aircraft positions approximately every three seconds, and Aviation Edge states an approximately five-minute tracker update cadence; each is a vendor description of its own product and neither resolves an operator's route-specific freshness ^{[58] [48]}. These figures should not be pooled into a league table.

Table 3 is a test-method proposal for the denominator and numerator, with deliberately illustrative arithmetic (Hypothetical Example). It is not a published benchmark, a provider result, or a regulatory target.

The example's 90% is arithmetic only. An operator could have the same ratio with short scattered gaps or with a long uninterrupted loss on one remote leg. Report the sample size, time window, fleet and route mix, age threshold, identity rule, exclusions, and uncertainty alongside every result. Stratify surface, climb/descent, cruise, oceanic, and high-terrain observations. For a comparative trial, use the same eligible flights and sampling times for each provider, and preserve raw observations so a later rule change can be replayed. Do not extrapolate a month of one route into a global availability claim.

A second useful metric is age at the consumer: for each accepted position, subtract the observation or receiver timestamp from the application's receive timestamp after confirming both clock units and synchronization. Report median, 95th percentile, and maximum, plus the share above the workflow threshold. Separately measure time from a provider disconnect to a visible degraded-state label and to the approved fallback. The sample-versus-reference disagreement over ADS-B Exchange's now unit makes this validation necessary before calculating an age distribution ^[5]. Quantitative reports should identify vendor claims as claims; no independent, current, route-specific benchmark was established by the cited documentation.

Implications and Future Directions

The most durable procurement artifact is a versioned feed contract and test dataset, not a screenshot of a coverage map. Provider APIs and entitlements change; the operator should retain a small set of representative payloads for each source type, a mapping specification, and acceptance results by route and phase. A new field, dropped field, or altered timestamp unit then becomes a detectable contract change. The original observation and its transformed alert should remain traceable through the integration layer, subject to license and retention terms.

Source diversity can improve resilience, but only if independence and rights are understood. A status provider may draw from a different input than a position provider; Aviation Edge explicitly says its own tracking and schedule services use different sources ^[49]. EUROCONTROL flight-plan data and a commercial positional feed answer different questions (Source: www.eurocontrol.int). A satellite layer may extend geography while changing cadence and licensing; FlightAware lists separate terrestrial and satellite ADS-B layers ^[43]. Redundancy should be proven in the same trial, including simultaneous gaps, identity disagreement, and switchover behavior.

Operational software teams should expose uncertainty to users. A stale point should show its last observation time and source. An unresolved flight match should not silently attach to a company leg. An alert should link to the evidence and the operator's documented review process. Those are design controls, not promises that a third-party feed meets a regulatory requirement. The next procurement cycle should repeat the same route sample and data-rights review, because a successful trial is time- and scope-bound. For approved flight following, dispatch, and direct aircraft communications, the operator should retain the responsible established services and procedures.

Frequently Asked Questions (FAQs)

What is an acceptable ADS-B feed latency for an OCC?

There is no universal API latency number in the cited sources. Define the screen or alert's decision, specify a maximum position age at the consumer, and test it on representative routes. The FAA's ADS-B Out broadcast rate and a vendor's website update statement measure other layers ^{[15] [58]}. Measure delivery errors and gap length alongside age.

Can an ADS-B address identify the active flight?

It identifies an aircraft address, not necessarily the operator's active leg. Join it with a transmitted flight ID, registration source, schedule or dispatch record, and time window; retain unresolved matches. ADS-B Exchange's flight field may be a call sign, flight name, or registration, and Cirium's status lookup uses carrier, flight, and date or a unique provider ID ^[28].

Does a blocked or privacy-protected aircraft disappear from every feed?

No such universal conclusion follows. The FAA says a PIA aircraft's broadcasts may still be received and LADD does not change broadcast data ^{[10] [11]}. Display and redistribution depend on the provider's policies and the buyer's contracted rights. Ask how the vendor handles privacy requests and how the operator will handle identifiable data.

What should happen when the feed goes stale?

Show a degraded state, preserve the last observation with its age, and route the review to the approved operator process. Use the fallback matrix to distinguish an unavailable position from a flight-plan, flight-status, or direct-aircraft report. ICAO's aircraft-tracking discussion emphasizes monitoring expected reports and acting on missed reports in its applicable framework (Source: www.icao.int); it does not make a commercial map a substitute for an approved process.

Conclusion

An ADS-B feed can be a valuable ground situational-awareness input when its observations are interpreted with their clocks, sources, identity limits, rights, and gaps intact. Procurement should begin with a specific OCC decision and end with a route-specific, repeatable acceptance test. The provider must document field semantics, source labels, contracted coverage layers, delivery and replay behavior, privacy handling, and license boundaries. The operator must define its own freshness and matching criteria, measure usable flight-minutes and long gaps, and keep a traceable fallback to approved records and procedures.

The central distinction is between a position observation and an operationally resolved flight. A valid coordinate can be old; a recent message can lack a new position; an aircraft address can be unmatched to a leg; a licensed internal view can be unsuitable for redistribution. The integration layer should carry those states forward visibly. Buy the source capability from a provider with the necessary rights and evidence. Build or commission the joining, alerting, and audit layer only where the operator's workflow needs it. Revalidate both when routes, feeds, terms, or procedures change.