Implementing Uplink Communications - nthallen/monarch GitHub Wiki

Uplink communications here refer specifically to transmitting commands over unreliable media to a remote instrument. For well-connected systems, the standard TCP configuration can be used, even over long distances. The approach outlined here has been used with line-of-sight radio transmissions and UDP encoding through a satellite link.

The steps involved in setting up remote command capability include:

• Annotate command definitions for transmission
• Create txsrvr in addition to srvr
• Create forwarding application for the GSE
• Create receiving application for the flight system
• Customize doit definition

%INTERFACE(Tx) <IFname>

Defines an interface, same as any other server interface, to which any transmitting commands are sent.

A transmitting command is any command that is derived from a non-terminal that starts with a carat (^).

On SCoPEx, this is implemented as:

&command
  : &^command
  ;

Commands are assigned to either &command or &^command, depending on whether or not they should be transmitted. Quit is an example of a command that probably should not be transmitted. Besides that, any command that specifically pertains to the user interface (i.e. on the ground), should not be transmitted.

There are two types of command servers: srvr and txsrvr, distinguished by the suffix of the executable's name. The srvr servers handle the actual execution of all commands they receive and run on the flight computer. The txsrvr servers execute non-transmitting commands locally and send all the transmitting commands to the Tx interface.

To complete the link, transmitting and receiving processes needed to be written. On the ground side, a transmitting process needs to use a Cmd_reader to read from the Tx interface on the txsrvr and then transmit by whatever means or media allows.

The receiving process receives commands from the matching media and then forwards them to the srvr via a Cmd_writer (or ci_sendcmd() et al.).

This functionality can be combined with the downlink transmission with a little finagling. The downlink trasmitter will be a tm_client subclass, which means main() is implemented by TMC's extmain.skel. That leaves limited options for adding the necessary initializations for the uplink receiver. The solution that has worked so far is:

• Define the tm_client subclass (e.g. my_tm_client) with overrides for process_quit() and adopted().
• Include #define TM_CLIENT_CLASS my_tm_client in header
• Add uplink receiver initializations to my_tm_client::adopted()

The doit definition can be customized to support direct or remote operations or both. There is explicit support for the concept of serial input, where it is assumed that the downlink data is identical to the direct link data. In that case, all the same display programs can be used, and the configuration only needs to decide how to configure the transmission and reception of commands.

If bandwidth limitations make transmitting the full data frame impossible, the GSE for remote operations will only be able to support a subset of the data. In this case, a new and separate telemetry frame must be defined for the data subset. In this case, it probably makes sense to move the reduced frame implementation into a separate subdirectory as a separate instrument.