Changes

Jump to navigation Jump to search
1,734 bytes added ,  09:31, 18 October 2020
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 ==
810

edits

Navigation menu