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.
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.
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 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.
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.
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.
AS_AFLIGHT, AS_AAIRLINE, AS_ATYPE and AS_AAIRPORT allowed clients to submit missing reference data to the server database.
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 */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.

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.
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.
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.
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.
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.
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
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.
One ACARSd network, multiple client implementations and multiple operating systems.
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.
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.
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 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.
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 / ATLASAcross the preserved releases, the client experience expanded from message display into maps, routes, aircraft images, databases, news, server lists, chat and reporting.
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.
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.
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.