842
edits
CPDLC: Difference between revisions
Jump to navigation
Jump to search
no edit summary
Mickybadia (talk | contribs) (Added section with available scheme) |
Legoboyvdlp (talk | contribs) No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{WIP}} | |||
'''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. | '''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. | ||
| Line 8: | Line 10: | ||
* 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. | ||
At the moment we would be interested in users to take up this project in the Hackathon, any assistance whatsoever would be welcome. | |||
== Issues/ideas == | == Issues/ideas == | ||
The following could be done in the hackathon: | The following could be done in the hackathon: | ||
* write the Nasal to exchange the right data with the outside system; | * write the Nasal to exchange the right data with the outside system; | ||
* write the IRC hook to connect FlightGear to IRC (not least a generic capability, that other applications may use) | |||
* 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 Done -- J Redpath | ||
[[File:CPDLC Block.png|thumb|Block diagram for CPDLC subsystem]] | |||
The block diagram describes how such a system might operate. The crucial elements are the IRC Hook and the FlightGear API. These are what the aircraft / ATC talk to directly, and therefore where input and output occur. | |||
The IRC hook will require elements such as: | |||
* Connection | |||
* Respond to PING | |||
* Disconnection | |||
* Transmit and receive PRIVMSG to a specified UID | |||
* Error handling - if UID does not exist, if server disconnects, if ... | |||
The FlightGear API will require elements such as: | |||
* Connection | |||
* Disconnection | |||
* Transmit + receive message element (including message history as a vector) | |||
One option is to have a | |||
/sim/network/cpcdlc/received/ | |||
message | |||
sender | |||
status | |||
.. etc …. | |||
and then an additional | |||
/sim/network/cpcdlc/signals/message-received | |||
Then in C++ you fill in all the ‘received’ values from your socket callback, and fire value changed on the signal property. This will allow a Nasal listener to process the received data. | |||
For message history, you could either have multiple received nodes (e.g. received[0], [1], [2]) or else a Nasal hook that accesses a vector. | |||
For transmitted messages, a similar scheme would work; however, what would probably be better would be: | |||
<tt>fgcommand(‘cpcdlc-transmit’, props.Node.new({‘receient’:’blah’, ‘mesage’:’foobarzot’,<etc, etc>});</tt> | |||
We’d use the same to establish the connection: | |||
<tt>fgcommand(‘cpcdlc-connect’, props.Node.new({ | |||
’server’: “foo.bar.com’, | |||
‘port’ : 666, | |||
‘callsign’ : ‘wibble’, | |||
<etc, etc? | |||
‘recv-path’ : ‘/sim/network/cpcdlc/received’, | |||
‘recv-signal’ : /sim/network/cpcdlc/signals/received' | |||
});</tt> | |||
== Available ATC-pie IRC scheme == | == Available ATC-pie IRC scheme == | ||