Skip to main content
← Back to homepage

For developers

Jetmapper for developers

A note for the people who own an ADS-B receiver, read raw feeds for fun, and want to know what happens to a connected object when the years pass. Written plainly, with the parts we have decided kept separate from the parts we are still working out.

The promise

The map is built to outlive the company that made it.

There is no subscription to lapse and no account to close. The frame updates itself over the air, so it gets better while it hangs on the wall. And we are committed to publishing the payload data schema, so a frame can be pointed at a self-hosted source and keep running on its own terms.

That schema is the promise. It is the single commitment on this page. Everything further down is either how the data moves today, or a direction we are still exploring, and we have kept those clearly apart.

How the data flows

Live flight data comes from Flightradar24 on a standard commercial plan. Our servers turn it into simple LED states and hold nothing raw beyond short retention windows. The frame polls for those states every 60 seconds, a few kilobytes at a time, and lights its 190 LEDs. Four steps, straight through.

Flightradar24 APILive flight data provided by Flightradar24commercial ADS-B feedJetmapper serversTransform to LED states · short TTLs onlypoll every 60s · ~3 KB / minYour frameESP32-S3 · polls on a timerone lead LED per route190 LEDsPrecision or Journey mode

Live flight data provided by Flightradar24.

The payload, in draft

A rough shape of the 60-second LED-state payload. Each tracked flight names its route, a display mode, the one lead LED that is lit with its brightness, and the LEDs that are on or off along the route. Read it as a sketch of intent, not a spec.

Draft v0illustrative, subject to change before publication
{
  "schema": "jetmapper.led-state/draft-v0",
  "generatedAt": "2026-07-16T13:32:00Z",
  "intervalSeconds": 60,
  "flights": [
    {
      "route": "LHR-JFK",
      "mode": "proximity",
      "leadLed": { "id": 47, "brightness": 82 },
      "activeLeds": [42, 43, 44, 45, 46, 47],
      "inactiveLeds": [48, 49, 50, 51, 52]
    },
    {
      "route": "DXB-SIN",
      "mode": "journey",
      "leadLed": { "id": 118, "brightness": 100 },
      "activeLeds": [110, 111, 112, 113, 114, 115, 116, 117, 118],
      "inactiveLeds": [119, 120, 121]
    }
  ]
}

The production API is authenticated; a documented local interface is part of the published-schema commitment. This page documents no endpoints, headers or tokens.

Committed, and still exploring

Three of these are commitments, standing alongside the published schema. One is still exploration, listed so the difference stays honest.

  • Committed

    An owner-configurable upstream

    A setting that points the frame at a data source you choose - any server that speaks the published schema, including your own.

  • Committed

    A native local ADS-B receiver mode

    Run your own receiver and the frame reads from it directly on your network, no server in the loop. We do not supply the receiver; the frame listens to yours.

  • Committed

    A server fund in escrow

    When the Kickstarter campaign funds, five years of server running costs are banked with an official independent body, out of our reach. The goal we are building toward is ten.

  • Exploring

    Publishing the LED index map

    A documented map of every LED index and the node spacing, so the physical layout is legible to anyone building against it.

Talk to us

Building something with ADS-B data, or want to be told when the schema is published? Write to contact@jetmapper.co.uk and say what you are working on. We read every one.