ADS-B Data Integration: What an Adapter Can and Cannot Prove

ADS-B data integration converts aircraft surveillance messages into information that another system can interpret. A working adapter can demonstrate how a supported message becomes a structured observation, how its origin is recorded and what survives translation. It cannot, by itself, establish that the aircraft's reported position is correct, authenticate its identity or prove that an operational system has accepted the feed.

SynapseCommand's published ADS-B implementation makes those boundaries inspectable. This first article in our adapter series examines the evidence an integration team should request, using the public implementation as a concrete case study. The detailed message coverage remains in the ADS-B adapter reference.

At a glance

The aviation background comes from the FAA's ADS-B guidance. The implementation and evidence statements above come from the release-pinned ADS-B manifest.

Start with the feed, not the label

“ADS-B support” is too broad to define an interface. A receiver may expose individual radio frames, while a surveillance service may deliver processed reports. Another provider may supply a proprietary JSON representation. Each requires its own input contract.

ADS-B also includes distinct aviation data links. The FAA's equipment guidance distinguishes 1090ES from the 978 MHz Universal Access Transceiver. Support for one should not be presented as support for both. The SynapseCommand implementation discussed here declares 1090ES.

ASTERIX Category 021 occupies another layer. EUROCONTROL defines CAT021 as a structure for exchanging ADS-B messages. Its publication page currently lists Edition 2.7, published on 3 July 2025. That is a standards publication fact, not evidence that any particular adapter implements every item in that edition.

This is an architectural comparison, not a ranking. A raw feed and a processed feed can serve different purposes. The important question is what processing has already happened before the data reaches your system. SynapseCommand documents its CAT021 implementation separately within the broader ASTERIX family.

Three layers of evidence to keep separate

1. The message was decoded as intended

The first layer concerns syntax: whether the input has the expected shape, passes applicable checks and yields the intended fields. The public ADS-B adapter tests include CRC checks, position-reference behaviour and round-trip tests.

Those tests provide inspectable evidence about particular inputs and behaviours. They do not make every possible input valid, and a successful decode does not establish that a transmitter's statement is true.

2. The translated observation retains its meaning

The second layer concerns semantics. A number can survive a translation while losing its unit, reference system or qualification. An observation can remain structurally valid while its timestamp is misunderstood.

The repository's field-coverage document records how ADS-B fields are mapped or retained outside core model fields. This is where a reviewer can distinguish a first-class canonical value from source information kept for later interpretation.

For an integration team, retaining both the value and its meaning is the acceptance question. Merely finding the same number somewhere in an output object is weaker evidence.

3. The complete integration behaves acceptably

The third layer concerns the deployed chain: acquisition, delivery, translation, downstream processing and presentation. Our recommended review model treats this as a separate acceptance activity, with its own requirements and evidence.

For example, a correctly translated observation can still arrive too late for a consumer's requirement. A reconnect can introduce duplicates. A display can hide uncertainty that the data model preserved. These are illustrative integration risks, not reported defects in SynapseCommand.

The public adapter contract places translation apart from filtering, enrichment and decision logic. That separation gives reviewers a useful way to assign responsibility. The platform architecture provides the wider context in which translated data is used.

Time, position and identity need explicit boundaries

A receipt timestamp is not an aircraft timestamp

In this implementation, an ADS-B observation uses the receipt instant because the supported frame does not provide a complete absolute observation timestamp. The basis is recorded explicitly. The receiver counter carried by an extended text envelope is retained without interpreting it as a wall clock, as documented in the adapter source.

The practical consequence is a review question: what does each time field mean at each boundary? Receiver time, ingestion time and the time represented by an observation must not be treated as interchangeable simply because they are all displayed as timestamps.

A position depends on its decoding context

The same implementation supports local Compact Position Reporting decoding with a configured reference position. Without that reference, it retains the raw CPR fields and leaves position unavailable. Pairing separate even and odd frames for global decoding is outside this adapter's stateless contract.

A plotted coordinate therefore needs a stated basis. Reviewers should ask whether a reference was supplied, where its suitability was established and whether downstream consumers can see the decoding qualification. The source explicitly documents the risk of a plausible but incorrect local position when the reference is unsuitable.

This is not a general claim that global CPR decoding is undesirable. It is a design boundary: processing that combines multiple transmissions belongs in a component whose state and assumptions can be reviewed separately.

An identifier is not authenticated identity

The ADS-B source distinguishes corruption detection from authenticity. It checks CRCs but keeps affiliation UNKNOWN. A callsign or address can be preserved accurately without being independently verified.

The engineering implication is that systems should retain the distinction between “this message reported this identifier” and “this aircraft's identity has been established”. Likewise, a missing cooperative report is not sufficient evidence to classify an object or establish that the airspace is empty.

These distinctions become consequential when observations contribute to a common operational picture. A shared display should carry forward the limits of its inputs, alongside the information those inputs provide.

What the SynapseCommand implementation demonstrates

In the 3.3.0 release, the ADS-B manifest declares bidirectional translation, maturity level L3 and claim status VERIFIED. Its evidence discussion records byte-exact ingest round trips for published byte fixtures while explaining why the declared level remains L3: the preservation check uses a value-presence heuristic rather than a path-bound field ledger.

That distinction matters. Reproducing fixture bytes is useful evidence for those fixtures. It does not establish a general guarantee that every meaningful source field survives every possible transformation. The declared level, the test outcome and the scope of the fixtures answer related but different questions.

The manifest also leaves the exact standard edition unspecified and names that limitation. Readers should therefore avoid turning “1090ES adapter” into a claim of comprehensive conformance to a particular DO-260 edition. The public record provides a supported subset and inspectable implementation, not a substitute for a fully specified procurement requirement.

“Bidirectional” describes software translation. The adapter implementation emits frame representations from supported canonical objects. That does not establish an installed radio transmitter, an operational broadcast service or aircraft-equipment approval.

The open-source integration layer lets engineers inspect the data contract and translation code. It does not make the private operational platform or a particular deployment independently verified. Evidence should follow the component and release to which it actually applies.

What to ask before accepting an ADS-B integration

The following checklist is our synthesis for technical evaluation. It is not an additional SynapseCommand certification scheme or a claim that a deployment has passed these checks.

Ask for the evidence against a pinned release. A current website, an older manifest and results from a different package version can each be accurate individually while failing to describe one reproducible baseline.

The most useful acceptance record connects a requirement to a supported behaviour, a test and an explicit limit. An unexplained capability badge cannot provide that chain. The interoperability catalogue is the starting point for identifying which adapter and exchange direction a proposed integration needs.

Why this distinction matters now

SynapseCommand published release 3.3.0 on 8 October 2026. This article examines the ADS-B implementation within that current public baseline; it does not announce ADS-B as a new capability introduced by that release. The dated release record allows the discussion to be checked against a specific software version.

For engineers and acquisition teams, the value of a public adapter is the ability to examine what it preserves, what it derives and what it declines to claim. That makes the next integration conversation more concrete: agree the actual input, the required meaning and the evidence the receiving system will need before acceptance.

Discuss an ADS-B integration with the feed format, required exchange direction and acceptance criteria identified.