ACARS Network

Hoppie Home

Hoppie's ACARS

Buy Hoppie a coffee

My ACARS Account

Client Software

Network Details


Message Log

Stations Online

Send Message

Send CPDLC Message

This is a DEVELOPMENT TOOL. For operational use of the CPDLC interface, please use a real CPDLC client, that makes your work twenty times easier.

MIN (your new message ID)
MRN (the message ID you're replying to)
(see below)
RA Yes No    (Do you need a reply from ATC?)
Wilco/Unable    Affirm/Negative    Roger    Not required    (What reply do you need from plane?)
Logon Code

Brief CPDLC encoding rules

Unlike the real-world CPDLC system, where all messages are hardcoded as message template numbers with fill-in fields as parameters, this simulated CPDLC system is based on simple readable strings. The advantage of this is that there is no need to encode or decode much; the disadvantage is that deviations and errors are possible, but I consider this more a built-in growth enabler. :-)

If you want to get down to the details, this older FAA document is a very good start. Notice the manual UL and DL message templates, in appendix G, starting page 53.

The syntax conventions in the simulated message are the following.

  • Only uppercase letters and numbers.
  • Separate template text and variable fields by @ signs.
  • Pilot displays usually can simply replace @ signs by new lines.

For example, template UL25 reads: AT [position] DESCEND TO AND MAINTAIN [altitude]. It needs the variables to be filled in by the operator (here a controller) using their interface. The result is AT @BARKO@ DESCEND TO AND MAINTAIN @FL330@, which you can manually put in the message text box above. The interface now has sufficient information to render the message in any layout that is desired.

The same UL25 uplink message needs to be responded to, by the pilot, using the W/U format, therefore either with DL0 (WILCO) or with DL1 (UNABLE). These responses are also encoded as plain text, to keep the system easy to follow.

Each message has a unique message identifier (MIN) that is generated by the sender and allows the sender to recognize a response to this message. Response messages have their own message identifer (MRN) generated by the responder and copy the sender's ID for reference.

Note that the current simulated CPDLC system uses a simplified logon protocol. An aircraft sends REQUEST LOGON to the ATS station's four-letter ICAO address, and the station usually responds LOGON ACCEPTED. That's it.

To hand over to the next ATC station, the current station sends HANDOVER [ICAO]. The aircraft then may log off (this is not necessary) and simply logs on to the next station.

Interesting detail: the real-life whole-country KUSA identifier in the United States for domestic CPDLC is a fake. Underwater the system does really hand over from center to center, but this is not shown to the pilots. The ACARS system that I simulate, just as in the real world, has no clue about what messages it moves around and therefore cannot do this kind of callsign stunting. It's the FAA CPDLC system built on top of ACARS that has the smarts. If somebody wants to build such a KUSA server, be my guest!

You can follow how it is done on the log page.

© 2024 Jeroen Hoppenbrouwers For more information, mail to