Difference between revisions of "CPDLC"

From FlightGear wiki
Jump to: navigation, search
(Proposing CPDLC for the 2020 Hackathon)
 
(Issues/ideas)
Line 13: Line 13:
 
* write the Nasal to exchange the right data with the outside system;
 
* write the Nasal to exchange the right data with the outside system;
 
* 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
  
 
[[Category:Hackathon 2020 Ideas]]
 
[[Category:Hackathon 2020 Ideas]]

Revision as of 15:13, 16 October 2020

Controller-pilot data link communication (CPDLC) is a direct connection between ATC and aircraft through which controllers can communicate with pilots based on text, thereby relieving radio traffic. Its use is increasing everywhere in real life, while no aircraft is equipped in FlightGear yet.

If taken up in the 2020 Hackathon, this feature missing today could become available quite soon, as no serious core change seems necessary, at least for first versions to start working.

Recent efforts

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!);
  • 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.

Issues/ideas

The following could be done in the hackathon:

  • write the Nasal to exchange the right data with the outside system;
  • 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