mlat.uk
Under the hood · designed, built and run by one person

How mlat.uk works.

  • SDR receivers
  • Multilateration
  • Data engine
  • Live API
  • One engineer

A volunteer network of software-defined radios, a Rust multilateration server, a purpose-built data engine and a bespoke streaming API, fused into one live picture of air, maritime and space traffic. Every layer, from the antenna to the pixels, was designed, written and is operated by one person. This page follows a single radio signal from the antenna to your screen.

Open the live map Sources and credits
…feeders contributing
6continents
…positions a day
…lifetime positions
The whole stack

Three domains in, one picture out.

Air, maritime and space data arrive by completely different routes. They are kept apart until the data engine, where they are normalised into one object model and published as a single stream.

mlat.uk system block diagram Air, maritime and space data flow from sensors and public sources through ingest, a data engine and Redis into a streaming API, then via Cloudflare to the map, telemetry, replay and the installable app. SENSORS & SOURCESINGESTDATA ENGINESTATEAPICLIENTSAIR · ADS-B, MODE S, MLATMARITIME · AISSPACE · ORBITAL ELEMENTSREFERENCE DATA1090 MHz RF chainantenna → filter→ LNA → SDRDecoder softwarereadsb / UltrafeederMode S decode, stampsreadsb aggregatordedupe, track, mergemlat-server-rsclock sync, TDOA solveKalman filter (Rust)aircraft workerhex-sharded threadstar1090-db enrichmentroutes, tierstrimmed + delta publish12345162 MHz RF chainantenna → filter→ LNA → SDRDecoder softwareAIS-Catcher / ShipfeederAISHub exchangevessels from peersAIS UDP ingestNMEA sentencesmaritime workerNMEA decodeMMSI mergelocal feed beats AISHubtrimmed + delta publish67CelesTrakGP / OMM elementsSATCAT catalogueElement loadergroups, tiers, refreshspace workerSGP4 propagationelements for browsers8Public datasets and routesOurAirports · NOAA AWC, SWPC · tar1090-db · adsb.imairdata + routecacherefresh, cache, sanity-check9REDIS · live statepub/sub + snapshots10PostgreSQL + PostGISdaily partitions · routes · heat cells11APIIn-memory live setevery aircraft, vesseland satellite, by idViewport + detailwhat is in view,ranked by zoomChange streamonly what changed,compressedStatic + historytracks, replay, search,cached JSON1213CLOUDFLARE EDGE · TLS · CACHEMap (tar1090-derived)live change streamSGP4 in the browserone selection modelTelemetrylive tables, graphscached JSONReplay + heat map10-minute history framesInstallable appsame map, full screen14

Swipe sideways to see the whole diagram.

  • Air
  • Maritime
  • Space
  • Fused stream
  • Batch, history and reference data
  1. Receive. Antenna, filter and LNA feed the SDR, which digitises 1090 MHz. The decoder software (readsb) demodulates and decodes Mode S, stamping each frame with a 12 MHz timestamp.
  2. Beast feed. Deduplicated Beast frames go to feed.mlat.uk:30004 and into the central readsb aggregator.
  3. MLAT feed. The same receiver sends timestamped frames to mlat-server-rs on 31090, and the server returns each receiver’s sync state and results over the same connection.
  4. Multilaterated positions go back into readsb as Basestation (SBS) lines, so ADS-B and MLAT share one track per aircraft.
  5. Aircraft stream. readsb pushes only the aircraft that changed to the aircraft worker.
  6. AIS. The same RF chain on 162 MHz feeds AIS decoder software (AIS-Catcher or Shipfeeder), which sends NMEA over UDP to the maritime ingest.
  7. AISHub. Vessel data exchanged between contributors is pulled in; local receivers take priority.
  8. CelesTrak. Orbital elements and the SATCAT catalogue are loaded, grouped and tiered.
  9. Reference data. Airports, weather, hazards, the aircraft database and routes are refreshed and cached by the airdata and routecache workers.
  10. Live state. Each worker publishes trimmed, delta-only updates to Redis and writes periodic snapshots.
  11. History. Positions that cannot be predicted from the last one are written to PostGIS in daily partitions.
  12. API ingest. The API subscribes to the live updates and holds the whole live set in memory.
  13. History reads. Tracks, replay frames and heat cells are read from PostgreSQL on demand.
  14. Delivery. Changes stream to each viewer through Cloudflare; static and history responses are cached at the edge.
In five stages

The same flow, one stage at a time.

Every stage does one job and hands a smaller, cleaner stream to the next.

  1. 1

    Sensors and sources

    • 1090 MHz ADS-B and Mode S from SDR receivers
    • 162 MHz AIS from maritime receivers
    • CelesTrak orbital elements
    • AISHub vessel exchange
    • Airports, weather, aircraft database
  2. 2

    Ingest

    • readsb: Beast in, tracked aircraft out
    • mlat-server-rs: clock sync and multilateration
    • AIS NMEA over UDP
  3. 3

    Data engine

    • Aircraft, maritime and space workers
    • One object model for all three
    • Redis live state, PostGIS history
    • Enrichment, routes, metrics
  4. 4

    Bespoke API

    • Every live object in memory
    • WebSocket viewport deltas
    • Level-of-detail tiers
    • JSON, tracks, history, search
  5. 5

    Clients

    • Map, a modified tar1090
    • Telemetry tables and graphs
    • Replay and heat maps
    • Installable phone app
Stage 1 · The receiver

Local SDR: from antenna to Beast.

Everything starts at a volunteer’s antenna. An aircraft’s transponder broadcasts ADS-B and Mode S on 1090 MHz; vessels broadcast AIS in the maritime band around 162 MHz. A software-defined radio digitises a slice of spectrum, and software does the rest.

The receive chain matters more than anything downstream, and it has the same shape on every band: antenna → filter → low-noise amplifier (LNA) → SDR → decoder software. The antenna decides what can be heard. The band-pass filter stops strong out-of-band signals from overloading the receiver. The LNA, placed ahead of cable loss, sets the noise floor. The SDR digitises the band, and software decodes it. Range comes from getting each link right, not from more power.

Demodulation and decoding. The decoder software (readsb for 1090 MHz) samples the radio at 2.4 Msps, finds Mode S preambles, checks the 24-bit CRC and attempts single-bit error correction. It decodes DF17/18 extended squitters, resolves compact position reporting (CPR) pairs into latitude and longitude, and keeps a per-aircraft state. Messages leave the receiver in Beast binary format, which carries the 12 MHz timestamp on every frame that multilateration needs.

Sharing. Most feeders run the SDR-Enthusiasts Ultrafeeder image. Two lines send data to the network:

ULTRAFEEDER_CONFIG=
  adsb,feed.mlat.uk,30004,beast_reduce_plus_out;  # ADS-B (Beast)
  mlat,feed.mlat.uk,31090;                        # MLAT timestamps

AIS receivers (AIS-Catcher or Shipfeeder) send NMEA sentences to feed.mlat.uk over UDP. No account or key is needed; the contributor guide has the details.

At the receiver

ADS-B / Mode S
1090 MHz, PPM, 1 Mbit/s frames of 56 or 112 bits
AIS
161.975 and 162.025 MHz, GMSK at 9,600 baud, 25 kHz channels
RF chain
Antenna, filter, LNA, SDR, decoder software, on every band
Sample rate
2.4 Msps for 1090 MHz
Decoder
readsb, beast_reduce_plus output
Time base
12 MHz Beast timestamp on every frame
Transport
TCP (Beast, MLAT), UDP (AIS NMEA)
Stage 2 · Aggregation

readsb: the front door.

Every feeder’s Beast stream lands on a central readsb, readsb, the decoder most of the community uses. It decodes, de-duplicates and tracks: if forty receivers hear the same aircraft, the network still holds one record, with the best position, a message count and the strongest signal.

readsb also carries the multilaterated positions. The MLAT server (next section) writes its results back to readsb as Basestation (SBS) lines, so a position worked out from timing differences appears in the same track as an ADS-B one, flagged as mlat.

From there, readsb pushes only aircraft that have new data to the data engine over a JSON port, and passes client and receiver state to the Telemetry page. The hot decode thread is the capacity limit on the aggregation side, so it is measured continuously and capacity is planned against it.

Aggregation, in practice

Input
Beast from every feeder, around 24,000 messages per second at 139 receivers
Decoder
readsb, running as the central aggregator
MLAT results in
SBS from mlat-server-rs
Output
A stream of changed aircraft, plus client and receiver state
Stage 2 · Multilateration

mlat-server-rs: positions without a transmitter.

Many aircraft, especially older ones, send Mode S replies that carry no position. But if three or more receivers hear the same transmission, the differences in arrival time fix where it came from, because radio travels about 300 metres per microsecond. That is multilateration (MLAT).

The hard part is time. Receivers do not share a clock, so the server must learn each pair’s clock offset and drift. It does this from aircraft that do broadcast their position: the known geometry tells it when a signal should have arrived, and the difference is a measurement of the two clocks.

The original is wiedehopf’s fork of Oliver Jowett’s Python mlat-server. It is single-core bound, so mlat.uk runs mlat-server-rs, a multithreaded Rust rewrite that speaks the same receiver protocol and Basestation output, so no feeder had to change anything.

The pipeline

  • Connection handling. Parallel I/O threads decode each receiver’s zlib-framed protocol.
  • Clock synchronisation. Receiver pairs are sharded across clock workers, each maintaining an offset-and-drift model with outlier rejection.
  • Matching. Aircraft are sharded by ICAO address; copies of one transmission from different receivers are grouped within a time window.
  • Solving. A least-squares solve (MINPACK lmdif, a Levenberg–Marquardt method) turns the arrival-time differences into a position and altitude.
  • Smoothing. An unscented Kalman filter tracks each aircraft over time and rejects bad fixes.
  • Output. Filtered positions go to readsb as Basestation lines; per-receiver results and health state go back to feeders.

Measured, not claimed

CPU, live
49% → 21% of a core for the same traffic, with 7% more receivers (2.2×)
CPU, replay
14 minutes of production traffic: 148 s → 60 s (2.5×)
Position maths
13.9 s → 2.6 s on the same input (5×)
Agreement
Median 12 m from the original; the original differs from itself by 5–6 m
Determinism
All 1,830 results reproduced exactly against a virtual-clock run of the Python pipeline
Against ADS-B
Median error about 105 m, equal to the original, and an upper bound because the truth carries network jitter

Most of the server’s CPU is network and protocol work, not the maths, which is why the whole-server saving is smaller than the saving on the position solve. Licensed AGPL-3.0-or-later.

Open source, as a gift to the community. mlat-server-rs is public so that anyone running a multilateration network can use it, learn from it or adapt it.

Stage 3 · The data engine

One picture from three kinds of data.

The data engine is what turns ADS-B tracks, AIS sentences and orbital elements into a single common operating picture. It is bespoke: three domains, one object model, one stream, one set of rules for what is important.

Aircraft

Reads the readsb JSON stream. Ingest is sharded by ICAO hex across worker threads, one per CPU less one. Records are enriched from the tar1090 aircraft database (registration, type, operator, military and interesting flags) when a feed lacks them.

Vessels

Decodes AIS NMEA from local receivers over UDP, optionally pulls AISHub, and gives local feeds priority over the exchange so a vessel is never double-reported. Static data (name, dimensions, destination) merges with position reports by MMSI.

Satellites

Loads CelesTrak orbital elements and the SATCAT catalogue, groups them, and propagates positions with SGP4. The same elements are published to browsers, so clients can compute positions locally, and any past position, with no history stored.

How the stream is kept small

  • Trimmed copies. Each update is published with only the fields the map draws; the full record is stored only for the object a viewer has selected.
  • Delta-only. Objects whose published fields have not changed are held back, with a periodic heartbeat so late joiners and expiry stay correct.
  • Pub/sub plus snapshots. Updates fan out through Redis; workers also write periodic snapshots so a restarting service picks up where it left off.
  • One live set. The API owns the in-memory picture and answers viewing queries itself.

Supporting workers

  • Route cache. Resolves callsign to origin and destination with LRU, Redis and PostgreSQL layers, and drops routes that do not fit the aircraft’s position and heading.
  • Airdata. Airports, METAR and TAF, SIGMETs, space weather and the aircraft database, refreshed on schedules.
  • Feeders and metrics. Contributor stats, MLAT sync links and site-wide figures that drive the Telemetry page.
  • Housekeeper. Daily partitions, retention and heat-map roll-ups.

History without the weight

Positions are written to PostgreSQL with PostGIS, partitioned by day so retention is a cheap drop. Only positions that cannot be predicted from the previously stored one are kept (turns, climbs, speed changes, plus at least one per minute), so straight flight costs almost nothing. Replay reads ten-minute chunks of this history; heat maps read hourly cells rolled up from it and merged into daily cells as they age. Satellites are never stored: their orbits are the history.

The common operating picture

How three domains become one.

An aircraft, a ship and a satellite have nothing in common physically. The engine gives them one shape: an id, a position, a motion vector, a tier and a lifetime. After that, everything downstream treats them alike.

AirMaritimeSpace
IdentityICAO 24-bit hex (~ prefix for non-ICAO)MMSINORAD catalogue number
Source of truthVolunteer ADS-B and MLAT, via readsbLocal AIS receivers, then AISHubCelesTrak orbital elements
How a position arisesReceived, or multilaterated from timingReceived AIS position reportsComputed with SGP4 from elements, server and browser
Update modelPush, roughly every second per aircraftPush, every few seconds to minutes per vessel classRecomputed continuously, no feed to wait for
Tier 0 (always shown)Military, emergency squawks 7500, 7600, 7700Military, active distress beaconsMilitary and space stations
History48 hours by default, thinned by predictability72 hours by default, thinnedNone stored: orbits are the history
EnrichmentRegistration, type, operator, routeName, dimensions, destination, flag stateOwner, launch, orbit class, element age
01

Normalise

Each worker maps its source into the shared object shape and a single time base, in the same units: feet, knots, degrees, Unix seconds.

02

Rank

Every object is given a tier, so the API can decide what matters at each zoom without knowing what kind of thing it is.

03

Stream as one

One WebSocket carries all three layers. The browser uses the same selection, labels, tracks and search for a ship as for an aircraft.

Stage 4 · The API

A bespoke, streaming API.

The API is written for exactly one job: keep a map current, for many viewers at once, without wasting a byte. It holds every live object in memory and does its own spatial filtering, because a general-purpose database cannot answer “what is in this box, at this zoom, that I have not already been told” as cheaply.

Only what you are looking at. A viewer tells the server which part of the world it is viewing and which layers it wants. The server sends what is in view, then only what changes, so a phone receives a few kilobytes a second rather than the whole picture again.

Level of detail. Every object is ranked, from the things that always matter (military, emergencies, stations) down to everything else. Zoom decides how deep into that ranking a viewer sees: a world view shows what matters, and zooming in adds the rest, without objects flickering in and out as they change.

One service for everything else. The same API serves the Telemetry tables, recorded tracks, replay history, search and the reference datasets, compressed and cached at the Cloudflare edge wherever it can be, and the live streams are limited to the mlat.uk sites.

API at a glance

Live
One stream per viewer, answered from memory
Detail
Ranked by importance, revealed by zoom
Identity
One namespace per layer: aircraft, vessels, satellites
History
Recent aircraft and vessel history; satellites computed
Replay
Stored positions replayed in short chunks; heat maps from rolled-up cells
Edge
Cloudflare in front
Stage 5 · Clients

A map that grew out of tar1090.

The map began as tar1090, wiedehopf’s fast, WebGL-accelerated aircraft map, and it still carries tar1090’s object model, layers and keyboard shortcuts. mlat.uk’s changes are published under the same GPL.

The change that makes it multi-domain is at the seam: the WebSocket client feeds objects into the same code path a readsb poll would, so vessels and satellites reuse the aircraft machinery for selection, labels, tracks and search. On top sit satellites propagated in the browser, a first-person Horizon and Sky view, replay and heat maps, and an installable full-screen app.

Delivery

Static at the edge, live from the stream.

This website and the map are static assets served by Cloudflare Workers, so the pages load from the edge nearest you. Only the live data touches the origin: one WebSocket per viewer, answered from memory.

Because the heavy work (decoding, multilateration, fusion, filtering) is done once on the server, a phone receives a few kilobytes a second for the part of the world it is looking at.

Built by one person

One engineer. The whole stack.

There is no company, team or organisation behind mlat.uk. Every layer on this page was designed, written, tested and is run by one person, alongside the volunteers who feed it. The same person who stands at the antenna also wrote the server that locates aircraft and the code that draws them on your phone.

Radio

Antenna, filtering and low-noise amplification for 1090 MHz and AIS, tuned until reliable range went from around 50 to over 200 nautical miles. The community receiver network grew from that single station.

Multilateration

A multithreaded Rust rewrite of the MLAT server, validated against the original on recorded production traffic, then cut over live with no change for any feeder.

Data engine

The workers that turn ADS-B, AIS and orbital elements into one object model, with enrichment, route checks, tiering and delta-only publishing.

API

A streaming API built around a single question: what does this viewer need to see right now, and what have they not already been told?

Interface

The map, the Horizon and Sky views, replay and heat maps, the installable app, and this website, all on Cloudflare’s edge.

Operations

The container stack, capacity planning, load and replay benchmarks, monitoring and the graphs on the Telemetry page, so there is always a measured answer to “will it scale?”

That is also why it is built the way it is: each stage has one clear job, measured against the one before it, and nothing is added that cannot be explained on a single page. If you run a receiver, you are part of it.

Sources and credits

Built on other people’s work.

mlat.uk exists because of open-source software and open data. Thank you to everyone below.

SourceUsed forLicence / terms
tar1090The inspiration and base of the map: object model, layers and interface. Modified for mlat.uk, with the changes published under the same licence.GPL-2.0+
readsbMode S and ADS-B decoding on receivers and the central aggregator. Derived from dump1090 and the original readsb.GPL-2.0+
mlat-serverThe reference multilateration server and receiver protocol (wiedehopf’s fork of Oliver Jowett’s), which mlat-server-rs reimplements.AGPL-3.0
mlat-server-rsThe Rust multilateration server running on mlat.uk.AGPL-3.0+
SDR-Enthusiasts UltrafeederThe feeder container most contributors run, and the community that supports it.Open source, see repository
tar1090-dbAircraft registration, type, operator and military flags.Open source, see repository
satellite.jsSGP4/SDP4 satellite propagation in the browser.MIT
d3-celestialStar chart data (Hipparcos, ESA) for the Horizon and Sky views.BSD-3-Clause
AISHubVessel positions and static data exchanged between contributors, merged with local AIS receivers.Data sharing agreement; credited as Data: AISHub contributors
CelesTrakOrbital elements (OMM/TLE) by group, and the SATCAT catalogue behind every satellite’s details.Public data, credited
NOAA Aviation Weather CenterMETAR, TAF and SIGMET hazard areas.US Government public data
NOAA Space Weather Prediction CenterPlanetary K-index and the OVATION aurora forecast.US Government public data
OurAirportsAirport catalogue with runways and frequencies.Public domain
adsb.imCallsign-to-route lookups, cached and sanity-checked against the aircraft’s position and heading.Service terms apply
OpenStreetMap and OpenFreeMapBase maps and the building footprints in the 3D Horizon view.ODbL © OpenStreetMap contributors
Open-MeteoTide, sea state and weather on port cards.CC BY 4.0
Wikimedia CommonsVessel and satellite images, and community photo sites for aircraft, each credited to its photographer.Per-image licence

mlat.uk is privately owned and independently operated. The data on the map comes from a network of volunteer contributors, augmented with the public sources above. It is for personal, non-commercial situational awareness only. See the privacy policy.

Add a receiver to the network.

Every antenna extends the picture, and three more receivers in an area is what turns on multilateration there. It takes a few minutes with Docker.

Visit the contributor guide Read the story