Multi-source ADS-B fusion

Why single-source tracking falls short

Every ADS-B aggregator depends on a network of volunteer-operated ground receivers. The coverage of any individual network is inherently uneven. Receiver density is high near cities and airports, sparse in rural areas, and nonexistent over oceans. An aircraft transiting a gap between receivers drops out of the feed entirely until it enters range of the next station.

AeroScope's primary sources, adsb.fi and adsb.lol, are both community-operated networks with strong coverage across Europe, North America and parts of Asia-Pacific, but no single one of them hears everything. Aircraft at low altitude, in terrain shadow, or beyond a receiver's range are missing from either feed alone, and each network occasionally rate-limits requests during load.

That is what the OpenSky Network fallback is for: when adsb.fi or adsb.lol cannot answer, AeroScope queries OpenSky instead, so a rate limit on one source degrades the picture rather than blanking it. Reports of the same airframe from more than one source are merged on the ICAO 24-bit hex address, so it appears once, not twice.

• adsb.fi and adsb.lol have different volunteer receiver footprints, so their coverage is complementary, not identical.
• OpenSky is queried as a fallback, not a third parallel stream, to stay within its free-tier rate limit.
• Oceanic and remote-area gaps stay open: AeroScope uses no satellite source and operates no receivers of its own.
• Two further community networks are recognized but not live: airplanes.live currently returns an access error pending permission, and ADS-B Exchange would require a paid key that is not in use. See data sources for current status.

Data sources

AeroScope draws on two primary community networks plus one academic fallback. Two further networks are recognized in the wider ADS-B ecosystem but are not enabled on AeroScope today; they are listed here for completeness, not because they contribute data. The authoritative, always-current list lives on data sources.

Source status

See data sources and provenance for the same table kept current sitewide.

ICAO hex deduplication

When more than one source covers the same airspace, overlapping reports are inevitable. The same Boeing 737 might appear in both the adsb.fi feed and the OpenSky feed. Without deduplication, the map would show two icons for one aircraft, with slightly different positions depending on each source's receiver geometry and update timing.

AeroScope deduplicates by ICAO 24-bit hex address. Every Mode S transponder is assigned a globally unique 24-bit address at the time of aircraft registration: this is the canonical identifier that all ADS-B sources report. When multiple sources report the same hex code, AeroScope merges them into a single track using the following rules:

• Position, altitude, velocity and heading are taken from the freshest, most internally consistent report available for that hex, cross-checked against the Kalman filter prediction.
• Callsign and squawk code are filled from whichever source reports them first; these rarely conflict across sources.
• If one source has a field another lacks, for example an aircraft type designator, that field fills the gap rather than being left blank.
• The timestamp of last update is always the most recent report from any source, so the track stays current.

Deduplication flow

Grid-based fetching system

Querying a large coverage area with a single bounding-box API call is inefficient and often impossible. Most ADS-B APIs limit bounding-box size, return paginated results for large areas, or increase latency proportional to area size. AeroScope solves this with a grid-based fetching strategy that divides the coverage area into cells and queries each independently.

The coverage area, a center point and a radius, is tessellated into rectangular grid cells, each sized to stay within the API's bounding-box limits. Each cell is fetched independently, and the results are merged before deduplication. This approach has three advantages:

• Stays within per-request bounding-box size limits imposed by each API.
• Allows selective high-frequency refresh of cells near the station center while outer cells update at the standard 12-second cycle.
• Failed cell fetches do not block other cells: partial results are still merged into the tracking picture.
• Rate limit budget is distributed across cells, with priority given to cells containing known geofenced areas.

COVERAGE GRID (SCHEMATIC)

Schematic only: an illustration of how cells tile around a station center, not a live reading. Purple cell = station center. Cyan border = active fetch cells. Gray border = low-priority outer cells.

Per-aircraft confidence

Not every report is equally trustworthy. AeroScope computes a confidence score for each aircraft from the fields that report actually carries: whether position and altitude are present, how fresh the report is, and whether the source flags degraded navigation accuracy. Reports that fall below a low-confidence threshold are treated as unreliable rather than plotted at face value. This runs per aircraft on every cycle; it is not a fixed weight assigned once to an entire source.

Where fusion sits in the pipeline

Fusion is one stage in the same pipeline every aircraft goes through, described in full on how it works. In outline:

Why there is no satellite feed

Ground-based ADS-B receivers have an inherent limitation: line of sight. Over oceans, deserts and polar regions where no volunteer receiver exists, aircraft still transmit ADS-B, but nobody on the ground is listening, so they drop out of every ground-based feed, AeroScope included.

Commercial operators solve this by putting receivers in orbit. Aireon, for example, operates ADS-B payloads on the Iridium NEXT constellation, and some paid aggregators buy access to that feed. AeroScope does not: it holds no satellite contract and none of its active sources, adsb.fi, adsb.lol or OpenSky, carry satellite-relayed positions. An aircraft that AeroScope is tracking over land will drop off the map once it is far enough from the nearest coastal receiver, and it will not reappear until it nears land again. This is a real, stated limit, not a gap to be talked around; see limitations and coverage.

What happens when a source is slow or down

A failed or slow fetch from one source does not take the whole picture down. The other sources keep feeding the pipeline for that cycle, so coverage in the affected area is reduced rather than lost outright, and it recovers on its own once the source responds again. Live service health, including whether a source is currently degraded, is published on the status page rather than claimed here as a fixed guarantee.

Why a 12-SECOND cycle

The heavier enrichment-and-detection pipeline runs on a cycle of about 12 seconds, separate from the faster 7-second position refresh the map uses for smooth motion. Twelve seconds gives the pipeline time to fetch, deduplicate, score and push results without polling adsb.fi, adsb.lol or OpenSky faster than their own documented limits allow, or faster than community aggregators actually refresh their own data server-side.

Frequently asked questions