[ldd-msn_surface] MSL/M20 keywords for msn_surface

[rgdeen]

Suggest the following for TELEMETRY keywords, add to msn_surface:

TELEMETRY_SOURCE_HOST_NAME Telemetry.telemetry_source_host_name : string Specifies the name of the host venue that provided the telemetry source data used in the creation of this data set. -- this is kind of odd in that it's a host name, but we try to capture everything... --

EXPECTED_TRANSMISSION_PATH Telemetry.expected_transmission_path: string Specifies the planned transmission path (route) for the telemetry data. See also transmission_path and communication_session_id. MSL nuance: Routing control at time of MPDU (Metadata PDU) generation. -- very poorly defined, but so is communication_session_id and it is what it is --

TRANSMISSION_PATH Telemetry.transmission_path: string Indicates the actual transmission path (route) for the telemetry data. See also expected_transmission_path and communication_session_id. MSL nuance: Routing status at time of MPDU (Metadata PDU) generation -- very poorly defined, but so is communication_session_id and it is what it is --

FLIGHT_SOFTWARE_MODE Command_Execution.flight_software_mode: int, no valid range Specifies the active flight software mode at the time of data product creation. Interpretation of specific modes is mission-dependent. MSL nuance: For MSL the values are interpreted as follows: “0” UNKNOWN “1” TEST “2” PRELAUNCH “3” LAUNCH “4” ECLIPSE “5” CRUISE “6” EDL_APPROAH “7” EDL_MAIN “8” SURFACE_NOMINAL “9” SURFACE_STANDBY “10” NONPRIME_TEST “11” NONPRIME_PRELAUNCH “12” NONPRIME_LAUNCH “13” NONPRIME_ECLIPSE “14” NONPRIME_CRUISE “15” NONPRIME_EDL_APPROACH “16” NONPRIME_EDL_MAIN “17” NONPRIME_SURFACE_NOMINAL "18” NONPRIME_SURFACE_STANDBY -- soooo... raises the question,should we convert this to strings? A string would be "better" from a pds standpoint as it is more likely to have values be shared across missions. But it is a HUGE mission specificity to put in the velocity templates... would need a macro just to do this translation. Is it worth it?

PRODUCT_TAG TBD... is it actually used for anything?

TELEMETRY_SOURCE_SIZE Telemetry.telemetry_source_size: int, valid 0-any Specifies the length in bytes of the telemetry stream from which this product was derived. MSL nuance: for MSL, it is the length of the user portion of the Data Product Object (DPO).

TELEMETRY_SOURCE_CHECKSUM Telemetry.telemetry_source_checksum, int, no valid range Specifies the checksum for the telemetry stream from which this product was derived. MSL nuance: for MSL, it is the sum of each (unsigned) byte in the data areas of all DPOs. It does not include the DPO headers.

AUTO_DELETE_FLAG Telemetry.auto_delete_flag: string, valid True/False Indicates if the product was to be automatically deleted onboard after it is transmitted. -- velocity convert int 0-1 to True/False

VIRTUAL_CHANNEL_ID Telemetry.virtual_channel_id: integer, no valid range Specifies the type of data flowing in the telemetry virtual channel. MSL nuance: The Virtual Channel Identifier is used by MSL to identify the RCE string generating the Transfer Frame, and to indicate the type of data flowing in the telemetry virtual channel. RCE String A is indicated by all Virtual Channel Identifier values having a ‘0’ as the high bit (e.g., virtual channels 0 to 31); RCE String B is indicated by all Virtual Channel Identifier values having a ‘1’ for the high bit (e.g., virtual channels 32 to 63). -- another poorly defined one

As always, comments welcome...

[rgdeen]

Update: flight_software_mode really should be a string. I don't think we should bother with valid values, although if you had to we could go with the above and just know we'll have to add more for other missions later.

[thareUSGS]

Note I did nothing with PRODUCT_TAG (as it was described as TBD above). via pull request: https://github.com/pds-data-dictionaries/ldd-msn_surface/pull/16

[rgdeen]

Turns out PRODUCT_TAG is not used so ignoring it is the right thing @thareUSGS . Thanks!