ACARS is based on store-and-forward. Stations sending a message will contact
the ACARS Network (in real life a network of "cellular" VHF
stations, simulated one single Web site using HTTP) and put their message in
a queue. The queue is maintained for 24 hours (or less, if the traffic
volume increases). Within this time, the addressed station (callsign) may
pick up the message. Everything is based on polling, not on permanently open
connections that get asynchronous notifications.
The Connection ProtocolConnect to the Web server with the following URL (subject to change):
You need to supply a few data items with each request. You may use either the GET or the POST protocol, or both intermixed.
For the syntax of some packets, such as ADS-C, CPDLC, progress, etc. please see the message log (link on the left). I'll put examples here eventually.
Progress MessagesNot yet processed by any machine, just treated as plain text. Contains out/off/on/in times and ETA. Airborne ACARS stations may send progress messages automatically to the dispatch station when flight events occur. See the ACARS manual (or the SB747 manual) for an exact description of these events.
CPDLC MessagesData traffic meant for processing by airborne or ground equipment used for ATC (Controller-Pilot Data Link Communications). Contains machine-readable data which should not end up directly in an interface, but is processed and workflowed via dedicated software.
Telex MessagesThese contain the bulk of all non-identified traffic. Anything can be sent as a telex. Note that in most cases, you will want to use POST protocol to avoid having to URL-encode the packet and/or run into maximum URL length limits. Good practice is to always keep URLs under 256 characters.
Ping MessagesJust echoes OK, to test the connection with the communication station. This is the equivalent of an ACARS Link Test to the media layer.
In case the packet is not empty, each word of the packet is considered to be an ACARS call sign. The message returns a packet with the call signs of the list that are actually online. This is not a real-time ping request all the way to the remote station and back.
A special fake call sign is ALL-CALLSIGNS (case-sensitive) which will return a list of all recently seen call signs.
Position MessagesTechnically identical to Progress and Telex, but with a different payload. These can be parsed by a machine, for example to make a graphical position plot.
PosReq MessagesRequest the return of a Position Message. Payload is ignored.
Poll MessagesA special one. This message polls the communication server for pending messages directed to your callsign. You receive a list of pending messages back. Meant for message retrieval by true ACARS stations, airborne or ground-based.
Peek MessagesAnother special one. Comparable to POLL, but returns all messages directed to the callsign that are still in the queue. No 'relayed' time is recorded, and the peeking station is not shown as being on line. Meant for message retrieval by automated processing devices, such as event time loggers for virtual airlines.
DataReq messagesThe packet payload is considered to be a file name, and the corresponding file out of the upload store is returned to the requestor. Contact the author for more information about how to set up your own upload store on the Web (it's very simple).
InfoReq messagesThe packet payload is considered to be an information request, of the form "request icao". Request can be one of "metar", "taf", "shorttaf", or "vatatis". The requested weather information is fetched live from the NOAA servers and returned in the reply packet straight away. VATSIM ATIS information comes from their live servers. The system tries to match the given ICAO to a VATSIM ATC callsign, if needed by dropping a leading "K". Only ATIS and TWR stations are polled.
Web Site Embeddable StuffIf you are building a web site, you can have a peek at all stuff that is already available to you for embedding.
|© 2014 Jeroen Hoppenbrouwers||For more information, mail to email@example.com|