Link Parameters

What depends on the ICD of a target stays in the code of its driver. What depends on the link (a spacecraft identifier, a CSP address, a virtual channel, a frame length) is a parameter of the link, declared in the topology. The same driver and transport then serve a flatsat and a flight model, or a bench in AIT and in IVV, with different values.

targets:
  obc-flatsat-1:
    platform: obc-v1@1.0.0
    environments: [AIT, IVV]
    links:
      rf:
        driver: obc-csp@1
        transport: csp1-kiss@1
        gateway: bench-rf-1
        default: true
        params: {csp_address: 10}
        environments:
          IVV: {params: {csp_address: 12}}
  sat1-fm:
    platform: platform-v3@1.4.0
    environments: [AIT, IVV, in_orbit]
    links:
      nominal:
        driver: platform-v3-ccsds@4
        transport: ccsds-tc@1
        gateway: "any(tag: sband)"
        default: true
        params: {scid: 0x2C5, tm_length: 256}

Declaring parameters#

• params maps names to booleans, numbers or text: {scid: 0x2C5, tm_ocf: true, t1: 2.5}. Names are identifiers (topology::invalid-param).
• environments overrides them key by key for some environments of the target: IVV: {params: {csp_address: 12}}. Keys not overridden keep their base value. The environments must be environments of the target (topology::unknown-link-environment).
• Parameters belong to the link: they go to its driver and to its transport, each reading the keys it knows.

The link context#

With every telecommand to encode and every frame received, the driver and the transport receive a context: target, link, environment, and the parameters resolved for that environment. Each reads what concerns it. The obc-csp driver takes the ground CSP address from csp_address; the ccsds-tc transport takes its COP-1 and frame settings from scid, vcid, window…

The environment of a telecommand#

A telecommand carries the environment of its run. A direct telecommand may declare one (the environment field of POST /v1/tc, stellar send --environment, the environment field of the web form):

stellar send obc-flatsat-1 obc.housekeeping --environment IVV

A telecommand without environment, such as those the transfer manager sends, takes the environment of the last telecommand of its link. On reception, a frame is decoded in the context of the last telecommand of its link, or with the base parameters before any; the decoded values then carry the header Stellar-Environment.

Parameter schemas#

At registration, a driver and a transport may declare the JSON Schema of the parameters they read (params_schema, an object schema with properties). When binding a link, the reconciler checks the resolved parameters of every environment of the link, the base one included:

• each schema validates the keys it declares;
• a key that no component of the chain declares is refused, when all of them declare a schema;
• a component without schema is not checked.

A refusal leaves the link unbound, with the reason in the readiness of the target:

link `rf`: parameters of link in `IVV` refused by driver `obc-csp-1`: `csp_address`: 40 is greater than the maximum of 31

Parameters of the example components#

ccsds-tc (transport of space packets in CCSDS TC frames under COP-1, and back from TM frames):

csp1-kiss, csp2-kiss (CSP packets in KISS frames):

csp1-can, csp2-can (CSP packets on a CAN bus, CFP of libcsp):

obc-csp (driver of the obc-v1 on-board computer):

See COP-1 and the Link Component for what the ccsds-tc settings do, and Writing a Driver to read parameters from a driver or a transport.