C2MS13 — Consider if we should add Ground Telemetry to our set of Messages

This is to consider if we should add the ability for MVAL REQ/RESP/MSG messages to support Ground Telemetry.

Perhaps Processed Telemetry could do this to, though since it is a hybrid between the unprocessed (raw) Telemetry Message and the Mnemonic Value Data Message, perhaps this doesn't make sense (is there ever a raw frame or sample for Ground TLM?).

Of note, all C2MS Messages have the following REQUIRED fields in the header:

• MISSION-ID
• CONSTELLATION-ID
• SAT-ID-PHYSICAL
• SAT-ID-LOGICAL

And in the Subject, all TLM messages have

MISSION, CONST, and SAT as required elements.

A current work-around is to use Mission, Constellation, and Satellite String values to represent something on the ground, such as an antenna, modem, gateway, etc. The question at hand is if we should make this a little more formal.

Options might be to rename the fields to something more generic than Mission, Constellation and Satellite. At issue, though, is how to capture this in a backward-compatible way.

For now, just capturing this for future discussion.

Notes on what we already say in the document:

6.2.3.2: If an element is defined as being required but is not applicable for that mission or to that specific message, "FILL" (no quotes) is placed in that element's position, meaning that it is not known or specified. For example, most but not all messages are satellite-related, so a “Satellite ID” is part of all message’s subjects. If a message is not satellite specific, "FILL" can be used in place of the "Satellite ID".

8.7 Real-time Telemetry Data Messages
Telemetry Messages are data packages that contain metrics from remote devices such as spacecraft.

In Reston, 2026, we felt it was best not to provide "ground" Telemetry for now, because we would have to 'fake-out' the system by using values other than Mission/Constellation/satellite designators in the header. Furthermore, it's unclear why we would supply ground telemetry, when GEMS performs that function already. Decision was to revisit in 2.0, when we might make the header for messages less-specifically for satellites, and more to do with Satellite Contacts.