CPDLC: Difference between revisions

1,734 bytes added ,  18 October 2020
(Added section with available scheme)
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
[[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 ==
842

edits