Mission database: TC as command parameter

[José Manuel Díez]

Hi all,

I'm using YAMCS to command an application that implements (parts of) the ESA Packet Utilisation Standard (ECSS-E-ST-70-41C). One of the services specified there is the "time based scheduling" (ST[11]). It basically lets the operator send telecommands that shall be released by the service at a later time. The command arguments look like this:

As you can see, the "request" field is a whole TC packet in itself, which in theory could be any TC in the MDB.

The way ACubeSAT worked around this is to create new commands whose arguments include the sub-command's arguments. See for example: https://gitlab.com/acubesat/ops/yamcs-instance/-/blob/main/src/main/yamcs/mdb/services/ST%5B11%5D.xml?ref_type=heads#L206-228

The downside with this approach is that you need to specify all the commands that could be time scheduled twice. So my question is: is there a clever way to specify this in the MDB, so that one could configure the sub-command within the command configuration wizard, as any other command?

Cheers,

José

P.S.: yamcs is awesome

[Nicolae Mihalache]

For the moment no clever way is available.

But the way I'm going to solve this in the near future is by adding some command options and implementing the embedding of the inner command into the schedule command in the PUS postprocessor.

Basically this call:

https://docs.yamcs.org/yamcs-http-api/server/get-server-info/

allows the PUS postprocessor to patch through some random command options that will be available in the Yamcs web when sending a command.

It will also work in the python client  (and any other client) using the "extra" argument:

https://docs.yamcs.org/python-yamcs-client/tmtc/client/#yamcs.tmtc.client.ProcessorClient.issue_command

The options will be received by the PUS postprocessor:

https://github.com/yamcs/yamcs/blob/master/yamcs-core/src/main/java/org/yamcs/tctm/pus/PusCommandPostprocessor.java

that will use them to embed the command inside the scheduled command.

At least this is the plan I have now - it should not be too difficult to implement. I will see if it works when implementing it.

It will be restricted to one command scheduled at a time (so N=1 in your diagram).

It would be nice to have a general on-board scheduler model inside Yamcs, supported by a corresponding user interface (so one can see and manage on-board scheduled commands) but so far we have not been able to get funding to implement one.

nicolae

P.S: thanks!

--
You received this message because you are subscribed to the Google Groups "yamcs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yamcs+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/yamcs/f2a6b6b4-1d0d-4e2b-93e2-461a958d0b94n%40googlegroups.com.

[José Manuel Díez]

Hi, thanks for the response. 

So if I understand correctly, one of these "additional options available to commands" (`extra` in the Python client API) would be something like "embedded_command" - a byte string of the command that should be scheduled. And the PUS Postprocessor can simply append it to the end of the application data buffer. Is that right?

N=1 is quite ok.

What I'm not sure is how this would work on the web UI side. Ideally, I would create a new "insert activity into the time-based schedule" command, set the release time, and select the embedded command that I want to include. Then I configure that command, and yamcs/yamcs-web converts it to a byte string that can be appended. Ideally I can go back later and change the embedded command options as well.

The IssueCommand API already returns the byte string for a command, so in theory it would be possible for an UI to issue a command to a blackhole queue (so it doesn't get transmitted to the space segment), and pass that binary as the extra argument to the "insert activity" command.

I don't think I am able to make these changes to yamcs-web but if what I wrote here makes sense maybe I could make a prototype UI to control PUS ST 11 (once the extra command option is implemented).

I'm not in a rush regarding this, though.

Thanks again!

Cheers,

José

You received this message because you are subscribed to a topic in the Google Groups "yamcs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/yamcs/7Qv3WUSedlQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to yamcs+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/yamcs/CANGODGCYqgfrxSCZORATsi_ODcKdnvShoU2E-h2v9m%2B-n8jDcw%40mail.gmail.com.

[Nicolae Mihalache]

No, so the command options will contain the time, sub-schedule id and group id. The postprocessor will verify if those options are set: if no the command will be sent as direct command, if yes then the command will be embedded into a PUS insert into schedule tc.

If you run the yamcs ccsds-frame example you will see commands get an extra option to use or not COP1. This will work the same way.

To view this discussion on the web visit https://groups.google.com/d/msgid/yamcs/CAB6bkwDq5UZ%2By%3De3esdxFhz72Gt7W8ZQ5yeDK9nYPtxvBfj90Q%40mail.gmail.com.

[José Manuel Díez]

Oh I see, that is much smarter and simpler. Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/yamcs/CANGODGBb0NE8%3DQchEFnLoh2UDN85Ne0FvDNaRLt7ckBOMVbqqA%40mail.gmail.com.