Cooperative surveillanceImplementation status: BidirectionalInput supportedOutput supported

ADS-B 1090ES: one frame in, one frame out

ADS-B extended squitter is the raw broadcast an aircraft transmits about itself. SynapseCommand publishes a bidirectional adapter that translates individual frames, and the most important thing about it is the decoding it refuses to perform.

This adapter is at TRL 8 as part of the complete, qualified SynapseCommand product. The supported edition, exchange direction and interface scope are listed below. What TRL 8 covers and how it differs from the engineering levels below. All current adapters are listed on the interoperability hub.

About the standard

What ADS-B is

A 1090ES message is a 112-bit frame. A small number of type codes carry identification, surface position, airborne position, velocity and operational status, and each frame stands alone on the air.

The format states no time at all. The one time-like bit says only whether a position is synchronised to a fixed epoch, which is a flag about time rather than a time.

It also states no unambiguous position in a single frame. Latitude and longitude arrive as compact position reporting values, which describe a position within a zone rather than a position.

Operational relevance

Why this matters to a commander

Raw extended squitter is what a locally deployed receiver produces, which matters in environments where a national surveillance feed is not available or not trusted.

The distinction between what has identified itself and what has not is the foundation of counter-uncrewed-aircraft work, and it starts with reading the cooperative broadcast directly.

Working from raw frames also makes it possible to compare a local receiver against a processed feed, which is a way of noticing that one of them is wrong.

What is implemented

The exact behaviour, not a capability claim

Ingest takes one frame in the standard hexadecimal text form and produces one Entity and one Event.

Because the format carries no time, the observation instant is the receipt instant on every frame, and the object records that this is what it is rather than implying the aircraft stated a time.

The receiver timestamp in the extended text form is a free-running counter since the receiver started rather than a wall clock. It is parked and never read as a time, because an adapter that treated it as one would date every frame to 1970.

Global position decoding, which pairs an even frame with an odd frame received within a few seconds, is out of scope, and the reason is structural rather than effort. Two frames are two transmissions that must be joined across time, and an adapter is a pure function of one payload, so a global decoder would either emit a half-populated object or hold a cache. A cache inside a translator is fusion performed where nothing audits it. A payload holding two frames is refused outright, so the pair cannot be smuggled in through the framing.

Local decoding, which needs one frame plus a reference position already known to be nearby, is the supported path.

Egress emits extended squitter frames. An Entity emits the type code it arrived as, and a Track emits one position frame per sample in the track's own order, which is the only shape this format has for a history.

  • 01
    Type codes 1 to 4
    Aircraft identification.
  • 02
    Type codes 5 to 8
    Surface position.
  • 03
    Type codes 0 and 9 to 18
    Airborne position, barometric altitude.
  • 04
    Type code 19, subtypes 1 to 4
    Airborne velocity.
  • 05
    Type codes 20 to 22
    Airborne position, satellite derived height.
  • 06
    Type code 28 subtype 1, type code 31 subtype 0
    Aircraft status and operational status.
  • 07
    Out of scope
    Everything else, each named in the coverage document with the reason it is out.
Direction of exchange

Which way the data actually moves

Into the canonical model

  1. 1090ES frame
    One 112-bit frame in hexadecimal text form.
  2. Entity and Event
    Observation instant is the receipt instant, and says so.

Out of the canonical model

  1. Entity or Track
    Canonical objects.
  2. 1090ES frames
    One position frame per track sample.
Workflows

Where this data is used

Local air picture

Frames from a locally deployed receiver become canonical objects without passing through a third party feed, which is what makes the picture sovereign in the literal sense.

Cooperative subtraction

Identifying what has declared itself is the first step in isolating what has not, which is the core of the counter-uncrewed-aircraft problem.

Feed comparison

Because the same airframe derives the same identifier here and in the Category 021 and Category 048 adapters, a raw receiver and a processed feed can be compared without any of the three adapters coordinating.

Implementation evidence

Every claim above has a file behind it

These paths are in the public repository, published under Apache 2.0. The adapter module for this page is adsb.

Source and fixtures

  • Adapter source
    packages/cdm/synapse_cdm/adapters/adsb.py

    Both directions, the compact position reporting decision and the parked receiver counter.

  • Fixtures
    packages/cdm/synapse_cdm/fixtures/adsb/

    Raw frames, parsed twins and golden canonical output.

  • Field by field coverage
    packages/cdm/synapse_cdm/FORMAT_COVERAGE.md

    The ADS-B row set, including every excluded type code and the reason for the exclusion.

Test evidence

  • Harness test
    tests/test_cdm_adsb_adapter.py

    Replayed by the validation harness shipped in the same package. Its six fixture checks keep PASS, FAIL and SKIP distinct and assess loss only within the adapter's declared scope.

  • Adapter contract test
    tests/test_cdm_adapter_contract.py

    Asserts that every shipped adapter obeys the pure-function-of-one-payload contract.

Conformance levels (L3, L4) are scoped adapter evidence declared in each release manifest for the published fixtures and supported subset. They are not product or agent Technology Readiness Levels, and neither is certification or validated integration with a named system.

Manifest-backed assurance, release 2.2.0 record

The cards below are the historical 2.2.0 manifest record, linked at that release's commit. The current release is 3.3.0; its manifests are at the v3.3.0 commit. VERIFIED is a scoped claim-status axis. Neither maturity nor claim status means external certification or integration with a named system.

  • adsb
    CLI alias:
    adsb
    Module:
    adsb
    Direction:
    bidirectional
    Edition/profile:
    Unknown
    Level (3.3.0):
    L3, manifest-declared
    Claim (3.3.0):
    VERIFIED, not deployed-system acceptance
    Preservation basis:
    Value-presence heuristic
    Round trip:
    bytes-level tolerance on published fixtures
    2.2.0 record:
    L4 VERIFIED, historical release-specific record. Release 3.3.0 declares L3: L4 now requires declared field mappings and a loss ledger, not the value-presence check

    DF17 and DF18 extended squitter, with the declared message-type subset.

    Limit: Local decoding is supported; stateful global even/odd frame pairing is outside the adapter.

What these conformance levels mean

Conformance levels (L3, L4) are scoped adapter evidence declared in each release manifest for the published fixtures and supported subset. They are not product or agent Technology Readiness Levels, and neither is certification or validated integration with a named system.

L3 means required provenance survives translation. L4 adds applicable roundtrip evidence under the adapter's declared tolerance. L5 would require every applicable public conformance gate to pass. L6 requires an independent real implementation or system and cannot be awarded from this repository's synthetic fixtures.

Status and limits

What is claimed, and what is not

Implementation status: Bidirectional

The published adapter implements both translation directions: the format into the canonical data model, and the canonical data model back out to the format. Both directions are replayed by the validation harness against shipped fixtures.

Last reviewed against the published implementation on 2026-09-06.

Limitations

  • Global compact position decoding is not implemented, and a payload containing two frames is refused.
  • No time is available from the format, so every observation instant is a receipt instant and is labelled as one.
  • The receiver counter in the extended text form is parked and never interpreted as a clock.
  • Only the type codes listed above are in scope.

Related reading: evaluating ADS-B integration evidence, a case study of what this adapter's evidence establishes and where acceptance testing begins.

Security boundary

  • No receiver configuration, site location or network detail appears in the published layer.
  • Translation is stateless, so nothing about a previous frame influences the next one.
Questions

Frequently asked

Why is global position decoding excluded?
It requires pairing two frames received seconds apart, which means holding state across payloads. An adapter here is a pure function of one payload, and a cache inside a translator is fusion happening where nothing audits it. The local decoding path, which uses one frame plus a known nearby reference, is supported.
What time is recorded against an ADS-B observation?
The receipt instant, and the object says so explicitly. The format carries no time, and the receiver counter in the extended text form is a free-running counter rather than a wall clock, so it is parked rather than read.
How does this relate to ASTERIX Category 021?
Category 021 is what a ground station emits after it has already decoded, validated and quality assessed the same broadcasts. Both adapters file the aircraft address under the same identity namespace, so one airframe derives one identifier across both without either adapter knowing about the other.