"Can you give us ACARS data?" arrives in our inbox often enough to be worth a proper answer, and the honest one is no — with an explanation of why, what we do provide instead, and where the thing you actually want comes from.
ADS-B, ACARS and CPDLC get used almost interchangeably in requirements documents. They are three unrelated systems with different purposes, different owners, and very different availability to anyone outside an airline. Getting them straight before you scope an ops dashboard saves a lot of time.
ADS-B: broadcast surveillance
The aircraft works out its own position from satellite navigation and broadcasts it, roughly twice a second, to anyone in radio range. No addressing, no encryption, no request. It's a shout.
It carries position, altitude, velocity, track, vertical rate, the aircraft's 24-bit address, and the callsign the crew entered. That's close to the complete list — the detail is in the anatomy of an ADS-B message.
Because it's an open broadcast, anyone with a receiver can decode it, which is why an entire industry of flight tracking exists. This is what we sell, and it's what every consumer tracker runs on.
Availability: open. Anyone can receive it. Providers compete on coverage, enrichment, latency and reliability rather than on access.
ACARS: the airline's own message bus
Aircraft Communications Addressing and Reporting System dates to the 1970s and is, in modern terms, a messaging system between an aircraft and its operator. Point to point and addressed, not broadcast — over VHF near ground stations, HF or satcom elsewhere.
What it carries is operational, and it's the part people actually want:
- OOOI events — Out of the gate, Off the ground, On the ground, In the gate. Generated automatically from door and weight-on-wheels sensors.
- Engine and systems data, feeding maintenance and health monitoring.
- Load sheets, fuel figures, crew messages, free text between the flight deck and dispatch.
- Position reports, particularly where surveillance coverage is thin.
OOOI is the crown jewel and the reason this question keeps coming up. Those four timestamps are the authoritative record of when a flight actually left and arrived, because they come from the aircraft's own sensors rather than from anyone's inference. Airline on-time performance, contractual delay calculations and settlement all rest on them.
Availability: private. ACARS traffic belongs to the operator. It's addressed to and from a specific airline, and it routinely carries commercially sensitive and personal information — crew details, passenger issues, fuel and load figures. Some VHF ACARS is technically receivable with a radio, and a hobbyist community does exactly that, but receiving something is not the same as having the right to redistribute it. Airline operational messages are not open data in the way ADS-B is, and a commercial product built on intercepted ACARS is standing on ground we wouldn't want to stand on.
If you need OOOI, the route is an agreement with the airline, or a provider that has one. There is no shortcut.
CPDLC: air traffic control by text message
Controller-Pilot Data Link Communications replaces voice radio with text for routine ATC exchanges — clearances, level changes, route amendments, frequency handoffs. It reduces radio congestion and eliminates the misheard readback, which is a genuine safety benefit.
It's used heavily in oceanic and remote airspace where voice is poor or impossible, and increasingly in domestic airspace.
Availability: closed, and not ambiguously so. CPDLC is a controlled communication between an air navigation service provider and a specific aircraft, carrying instructions the crew is required to follow. It is not published, not licensable by third parties, and not something a data vendor can offer you. If a supplier claims to sell CPDLC content, ask very precise questions.
Side by side
| ADS-B | ACARS | CPDLC | |
|---|---|---|---|
| Purpose | Surveillance | Airline operations messaging | ATC instructions |
| Direction | Broadcast to all | Addressed, aircraft ↔ operator | Addressed, ATC ↔ aircraft |
| Key content | Position, altitude, velocity | OOOI, engine data, load, free text | Clearances, level and route changes |
| Who owns it | Nobody — open broadcast | The operator | The ANSP |
| Third-party access | Open | Only by agreement | None |
So what goes in the dashboard
Depends on which questions it has to answer, and the useful move is to sort your requirements by which system they belong to before you go shopping.
Where is the aircraft right now, what is it doing, is it airborne, when will it arrive. ADS-B answers all of these. Position, altitude, speed, vertical rate, and a derived arrival estimate. This is available, affordable, and the backbone of any operational picture.
When exactly did it leave the gate and arrive on stand. ACARS OOOI. If you can't get OOOI, you can approximate: wheels-up and wheels-down are derivable from position data with reasonable accuracy, since the transition between ground and airborne is visible. Gate events are much harder, because an aircraft pushing back and an aircraft taxiing look similar from position data, and low-altitude coverage near terminals is often poor.
This distinction is explicit in our own archive. Historical flight records carry off_block_time and on_block_time for gate events alongside takeoff_time and landing_time for wheels-up and wheels-down, and a duration_source field which reads estimated when block time was inferred from positions rather than recorded from gate events. That flag exists precisely because the two are not interchangeable, and anyone using block time in a contractual or reporting context needs to know which one they have. More on that in replaying a flight track.
What did ATC instruct. CPDLC, and you're not getting it. Design around it.
Why is the flight delayed. None of the three, really. Ground stops and delay programmes are published separately by the air navigation service provider — for US airspace that's the FAA delays endpoint, covered in ground stops and GDPs explained.
The honest positioning
Since this is our blog, the self-interested summary would be that ADS-B is all you need. It isn't, and pretending otherwise wastes your time and ours.
If you are an airline building your own ops dashboard, you already have ACARS — it's your data, it arrives on your own message bus, and you should absolutely use OOOI rather than inferring gate times from positions. What you may not have is good visibility of other operators' traffic, other airports, and system-wide conditions, and that's where an external position feed earns its place.
If you are not an airline — a ground handler, an airport, an OTA, a logistics operator, a fleet department — you cannot get ACARS for aircraft you don't operate, and no amount of budget changes that. Your operational picture is going to be built on ADS-B plus published sources, and the right approach is to build it well and be explicit in the interface about which timestamps are observed and which are inferred.
The failure mode we see is a dashboard that presents an ADS-B-derived block time in a column labelled the same as an airline's OOOI-derived one, and then someone reconciles the two and finds a systematic several-minute discrepancy. Nothing is broken. They're different measurements of different events, and the interface implied they were the same thing.
Label the columns honestly and the discrepancy becomes a footnote rather than an incident.
Getting started
For the ADS-B side, the live positions endpoint and flight status cover the operational picture, FAA delays covers system conditions, and the Historical ADS-B group covers retrospective analysis with the block-time provenance flags described above. The free trial is enough to prototype the whole thing.
For ACARS, talk to the operator. For CPDLC, don't.