Open ryanpdx opened 1 year ago
Correct, each "instance" is supposed to be a separate mission that a mission operator can switch between.
Right now (Per Issue #58) some things are hard-coded to store things in the _global
namespace for configs, buckets, and other variables, which needs to be undone and always assign storage to its own instance.
As for the TLM/CMD ports, I don't think anything networking-wise needs to change, the ingress/egress just needs to get smarter.
IIRC the satellite already sufficiently identifies itself via a (required) callsign field, packet-version id's, etc. The pre/post processor classes can check the identifiers and then delegate to the appropriate handler.
I think we'd only ever have one pair of ports for Yamcs since it correlates to the one-and-only (for now) UniClOGS station we have anyhow.
Are there specific action items, (other than the new set of XTCE files), that this can be broken up into? Or do we want to consider this an Epic issue?
I would thing of this as more a proof of concept and/or implementing the minimum functionality, basically just get a multi-instance demo to work that can be built upon or used as a reference later.
We can properly defined the OreSat0.5 beacon and EDL command list in other issue(s).
Yamcs will now need to support both OreSat0 and OreSat0.5. If I remember right Yamcs has "instances" for this?
This will probably require new XTCE file(s) for OreSat0.5, as the beacon and EDL commands will differ from OreSat0. The OreSat0.5 beacon will gain data for 2 more solar cards and CFC card and lose some other data to fit the new data. The OreSat0.5 EDL commands will change due to some of the command not being relevant to a Octavo A8-based C3 with Linux.
This issue can probably be worked on now with fake beacons / EDL commands.
Don't know how this will effect the TC/TM ports.