CPDLC: Difference between revisions

2,239 bytes added ,  17 October 2020
Added section with available scheme
(Added section with available scheme)
Line 5: Line 5:
== Recent efforts ==
== Recent efforts ==
This would not start from scratch. Recent efforts have already taken place towards making it possible:
This would not start from scratch. Recent efforts have already taken place towards making it possible:
* [[ATC-pie]] already integrates CPDLC: it is working for other session types (e.g. solo), and an IRC-based (simple text) infrastructure for FG sessions is already in place, including transfers between data authorities, etc. (all it needs now is to be contacted by aircraft!);
* [[ATC-pie]] already integrates CPDLC: it is working for other session types (e.g. solo), and an IRC-based (simple text) infrastructure for FG sessions is already in place, including transfers between data authorities, etc. (all it needs now is to be contacted by aircraft!)---see [[#Available ATC-pie IRC scheme]] further down;
* work is currently in progress on a cockpit CPDLC panel;
* work is currently in progress on a cockpit CPDLC panel;
* a CPDLC middleware is under dev, required at this point because FG models cannot open their own TCP connections.
* a CPDLC middleware is under dev, required at this point because FG models cannot open their own TCP connections.
Line 14: Line 14:
* involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)?
* involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)?
* can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan
* can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan
== Available ATC-pie IRC scheme ==
When connected to an IRC server, e.g. <code>irc.flightgear.org</code>, ATC-pie features an integrated text chat system for ATCs to coordinate off the (public) FG text chat. The choice of IRC and plain text lines was in part motivated by the possibility for users of other clients (e.g. OpenRadar) still to take part via their own IRC client.
The connection is also used to embed special commands, in the form of escaped text lines, starting with <code>___ATC-pie___ </code>, e.g. for strip exchange (handovers) or "who-has" requests. Commands were later added to support CPDLC, which is ready for ACFT to connect. What follows is a description of those CPDLC-related commands.
Note that the IRC nicknames are assumed to match the FGMS network callsigns, so the first line sent after connection is always:
:<code>NICK <callsign>\r\n</code>
Then, from an ACFT point of view, every CPDLC command is sent to the current (or requested) data authority (ATC) via an escaped chat message line:
:<code>PRIVMSG <atc> :___ATC-pie___ <command_line>\r\n</code>
Command lines that an aircraft can send to an ATC are:
* <code>CPDLC_CONNECT</code>: attempt log-on
* <code>CPDLC_MSG <msg_contents></code>: connected CPDLC dialogue message (see below)
* <code>CPDLC_DISCONNECT</code>: connection shut down
Command lines that an aircraft can receive from an ATC are:
* <code>CPDLC_CONNECT</code>: accepted log-on, or new data authority (link has been transferred)
* <code>CPDLC_MSG <msg_contents></code>: connected CPDLC dialogue msg (see below)
* <code>CPDLC_DISCONNECT</code>: connection voluntarily dropped by ATC, or refused log-on
The contents of connected dialogue messages (contained in CPDLC_MSG lines) can be discussed as part of the interface between aircraft and ATC-pie, but for the moment they are of either format below:
* <code>REQUEST <display_text>(<sep_char><encoded_instruction>)*</code>: likely answered with an INSTR msg
* <code>INSTR <display_text>(<sep_char><encoded_instruction>)*</code>: never sent by ACFT, only received
* <code>ACK</code>: acknowledgement/"WILCO"
* <code>REJECT <optional_reason></code>
* <code>TEXT <free_text></code>


[[Category:Hackathon 2020 Ideas]]
[[Category:Hackathon 2020 Ideas]]
265

edits