2003 • beyond the decoder

It became a platform remarkably quickly.

The restored website archive shows that only months after the first public alpha, ACARSd already had remote clients, a formal developer protocol, a browser experiment, image enrichment and support for independent third-party software.

ACARS LIVE • 2003

A live ACARS client in a web browser.

The recovered acarsd-live.tar.gz is an early test system from the first ACARSd year. A small daemon named acarsdhttpd connected to an ACARSd server and exposed data to a PHP application on TCP port 82.

The chain was already recognisable as a web application architecture:

ACARSd → acarsdhttpd → TCP/82 → PHP → JavaScript → browser

The page warned visitors that ACARS LIVE was “ONLY A TESTVERSION AND NOT FULLY TESTED” and offered live traffic from central Hungary at N46.50 E17.54. The browser refreshed the traffic display repeatedly and updated up to four aircraft images as new registrations appeared.

ACARS LIVE
central Hungary
N46.50 E17.54

LIVEPORT = 82

www.fysb.de/icon/<REG>.jpg

ACARS LIVE IS ONLY A TESTVERSION
AND NOT FULLY TESTED!
FYSB • image & data enrichment

From a radio message to the actual aircraft.

FYSB was not merely a separate aircraft-photo site. Source and client material show it embedded in the ACARSd ecosystem. Registrations could be turned into aircraft icons or photographs, while database services helped resolve flights, aircraft, airlines, modes and airports.

Over time the clients also supported image sources such as planespotting.net, planepictures.net, airliners.net, jetphotos.net and myaviation.net. The important idea was the same: a cryptic radio frame should become something a human could immediately understand.

ACARS SIGNALREGISTRATIONDATABASEROUTE / TYPEPHOTO
Developer API • September 2003

A protocol for other clients.

The surviving api.h formalised ACARSd client/server communication only months after the first alpha. It was not just a stream of printable messages: operations covered live traffic, searches, reports, routes, aircraft metadata, compressed results, access control, heartbeat and binary data.

LIVE & CONTEXT

Messages became structured data

Operations included live ACARS records, route information, aircraft types, airlines, registrations and flight context. AS_FETCH explicitly told a client to fetch an icon for an aircraft.

COMMUNITY DATA

Clients could contribute back

AS_AFLIGHT, AS_AAIRLINE, AS_ATYPE and AS_AAIRPORT allowed clients to submit missing reference data to the server database.

ACCESS & TRANSPORT

More than a hobby socket

The API included password-gated full-message access, limited content for map entries, compressed search results, binary payloads and server status functions.

struct server_data {
    int operation;
    int length;
    unsigned long numvalue;
    char data[4096];
};

AS_FETCH     9   /* fetch aircraft icon */
AS_AFLIGHT  30   /* add flight data */
AS_AAIRLINE 31   /* add airline */
AS_ATYPE    32   /* add aircraft type */
AS_AAIRPORT 33   /* add airport */
AS_NEEDPWD  80   /* full message access requires password */
AS_CONTENT  98   /* limited message context */
AS_ROUTE    99   /* route for last contacted flight */
Before Google Maps • live positions

ACARSd already had its own aircraft map.

The recovered Tcl/Tk client source shows a live map system built from local static GIF maps. When an ACARS message contained usable latitude and longitude, the client converted those geographic coordinates directly into pixels on a Tk canvas and plotted the aircraft. Consecutive reports could be joined into a visible track.

The map was not dependent on a web mapping service. The map image had configurable geographic limits, and the client calculated its own pixels-per-degree scale. Airports, waypoints, server locations and the receiver's own position could be drawn on the same canvas.

x = (longitude - map_left) × pixels_per_degree_x
y = (map_top - latitude) × pixels_per_degree_y

ACARS message → position parser → LAT/LON → Tk canvas → aircraft + trail

The limitation was ACARS itself: usable position reports were comparatively rare. Later, SBS-1 changed that. libhomeradar read the BaseStation plain-text feed on TCP port 30003 and fed ADS-B/Mode-S information into the same ecosystem; in ACARSClient those records were deliberately marked *SBS-1* so users could distinguish them from ACARS traffic.

Preserved ACARSClient static map image
A preserved ACARSClient map asset. The client plotted live positions itself — no Google Maps API was involved.
The idea was already there

What was missing was a continuous source of aircraft positions.

ACARSd had identification, flight context, a distributed receiver network, searchable history and live map plotting. ACARS could provide positions, but only occasionally. SBS-1 and ADS-B later supplied the dense position stream that ACARS could not.

The database explosion

Then the data became the problem.

KjM began ACARSd with little practical SQL experience and moved from earlier Oracle familiarity into MySQL as the project grew. Every received contact could be stored and searched. By 2008, he remembers the central system holding more than 18 million flight movements.

GROWTH

Millions of searchable contacts

The public database could be searched by aircraft, flight and other context. The restored libhomeradar site contains a live “Database facts” page that counted records in sessiondata, airlines, airports, registrations, flights and search queries.

01 JUL 2008

30-second query limit

The surviving news archive says very long searches would be terminated after 30 seconds and that new fast indices had been created for flight-number and airport searches.

16 AUG 2008

The server was overloaded

The site reported that many simultaneous search queries could make the server very slow, that database optimisation was underway and that stronger hardware would soon be needed.

From learning SQL to replicated infrastructure

KjM remembers the database tier eventually running as one MySQL master with three synchronised replicas. That topology is currently preserved as personal recollection; the recovered web code proves the heavy searchable database workload and the later index work, but not yet the four-server replication configuration. If the original master database server can be recovered, the museum will update this section from its surviving schema and replication metadata.

Sometimes a database query was a good opportunity to get a coffee.

2008 database reality

18,000,000+ flight movements
(author's recollection)

01 Jul:
long queries → killed after 30 sec
new fast indices → flight / airport

16 Aug:
many simultaneous searches
server sometimes very slow
hardware upgrade needed
JACARS

The network was open enough for somebody else to build a client.

The original ACARSd download page listed JACARS as a “Free JAVA client for the acarsd network”. The server HOWTO treated it as a normal alternative to ACARSdClient/clientNG and explained how users could connect it to public or private ACARSd servers.

The surviving ACARSd archive does not identify the programmer by name with enough certainty for this museum to do so. What it does prove is more important: the published network/API was usable by software outside KjM's own Tcl/Tk clients.

Third-party client
JAVA

One ACARSd network, multiple client implementations and multiple operating systems.

2009–2010 • modularisation

ACARSd became a reusable platform.

The recovered libacarsd2 CVS tree shows a decisive architectural change. Decoding, sound-card input, TwoOnOne stereo reception, duplicate handling, contact databases, the ACARS network server/client and public contribution logic were exposed through a reusable library instead of living only inside one application.

LIBACARSD2

The engine

Applications could initialise the decoder, add input devices, start a port-2202 server, connect as a client, import or simulate messages and send public contacts without reimplementing the core ACARS machinery.

mACARS

The small Windows decoder

The recovered source calls itself “mACARS - free mini ACARS decoder”. It is a native Windows front-end around libacarsd2.dll, with sound-card decoding, TwoOnOne, databases, logging and public contribution.

winsend2

Where ACARS and ADS-B met

winsend2 accepted SBS-1/BaseStation data on TCP 30003 and RadarBox data, while later versions also embedded the ACARS decoder. It grew into a broad Windows aircraft-data workstation with route tracking, reports, a web server and central contribution.

The native Windows generation: ACARSdClient had deliberately used Tcl/Tk for a portable GUI. By the time of winsend2 and FlightShare2, that layer was gone. Both recovered projects are essentially C applications with real Win32 user interfaces: WinMain, Windows message callbacks, dialogs, list views and .rc resource files. The resource paths and compatibility code also preserve the MinGW32 development environment. In other words, this later branch of the ecosystem had become a native Windows/C codebase rather than a Tcl/Tk application.
Source-level signature: the surviving libacarsd2 decoder defines the ACARS preamble as {'*',0x16,0x16,0x01} — visually, *<SYN><SYN><SOH>.
The live ingest bridge

dbadd_lhr fed both the database and the live ecosystem.

KjM remembers dbadd_lhr.c as an important real-time source for ATLAS and other displays. The recovered source supports that role: it continuously scans uploaded ACARSd contact files, writes operational records into MySQL and also normalises the same contacts for libhomeradar through homeradar_import_by_string().

It explicitly recognises SBS-derived position/callsign markers, allowing digital contacts to enter the same broader aircraft-data path. The surviving code also performs periodic cleanup on its operational tables; the exact long-term-history path is still being reconstructed and may become much clearer if the original MySQL master can be recovered.

receiver / feeder
      ↓
  uploads/
      ↓
  dbadd_lhr
   ↙      ↘
MySQL   libhomeradar
          ↓
    live consumers
    / displays / ATLAS
The clients kept growing

Decoder → information system.

Across the preserved releases, the client experience expanded from message display into maps, routes, aircraft images, databases, news, server lists, chat and reporting.

LIVE MESSAGEAIRCRAFTAIRLINEROUTEPHOTOMAP
The Easter egg • reconstructed from Tcl/Tk source

ACARSd had three hidden games.

No original screenshot of the secret menu has survived. But the source did: breakout.tcl, memory.tcl, game.tcl and the hidden binding that opened their launcher. The museum can therefore reconstruct the menu without inventing its contents.

ACARSdClient — Other features
Historic photo of KjMAuthor
Reveal the original hidden key sequence
ESCACARSDESC

The surviving Tcl/Tk binding is effectively ESC acarsd ESC. An older client revision also exposed BreakOut directly through Alt/Meta+F11 before the secret menu became more elaborate.

Visual reconstruction based on the surviving Tcl/Tk launcher and descriptions; it is not an original screenshot.

Built around real receivers, not a product roadmap

One contributor near Frankfurt illustrates how practical requirements shaped ACARSd. His station used three scanners, contributed contacts to the central database, but deliberately remained absent from the public live-server network. Supporting installations like this helped push ACARSd beyond the original stereo TWO IN ONE design toward multiple sound cards and, in later releases, as many as eight scanners.

Read the contributor story →