`CLTU._prepare_cltu_pdu` incorrectly modifies earliest and latest transmission times

[davidmayo]

Problem description

ait.dsn.sle.cltu.CLTU._prepare_cltu_pdu takes parameters earliest_time and latest_time, which are eventually added to the CLTU-TRANSFER-DATA-INVOCATION PDU to define the earliest and latest acceptable TC data radiation times. However, when they are packed into the CCSDS Time format, all time information ends up lost, with only the number of days actually being set:

t = struct.pack('!HIH', (earliest_time - common.CCSDS_EPOCH).days, 0, 0)
pdu['cltuTransferDataInvocation']['earliestTransmissionTime']['known']['ccsdsFormat'] = t

The net result of this is that timestamps get "rounded down" to midnight. So when a user requests transmission no earlier than 2027-01-01 12:34:56.789+00:00, a PDU is generated that requests a transfer no earlier than 2027-01-01 00:00:00.000+00:00.

The same error is repeated for latest_time. The practical outcome is that missions do not have any way to precisely schedule radiation of TC frames to their spacecraft.

Proposed solution

The struct should pack (days_since_ccsds_epoch, milliseconds_since_midnight, microseconds_since_millisecond). So replacing the above snippet with code like this works:

def get_ccsds_time_struct(timestamp):
    """Create a `TimeCCSDS`-formatted struct of the given timestamp
    
    See CCSDS 912.1-B-5 section A2.1
    """
    delta = timestamp - common.CCSDS_EPOCH
    struct_days = delta.days
    day_microseconds = delta.seconds * 1_000_000 + delta.microseconds
    struct_milliseconds, struct_microseconds = divmod(day_microseconds, 1_000)
    return struct.pack('!HIH', struct_days, struct_milliseconds, struct_microseconds)

pdu['cltuTransferDataInvocation']['earliestTransmissionTime']['known']['ccsdsFormat'] = get_ccsds_time_struct(earliest_time)

with an identical change for the latest_time parameter

Implementation/testing

I have verified by testing this with a DSN node (DSS-17 at Morehead State University) that my proposed solution is accepted by a DSN UPL rack, which responds as expected and radiates frames at the expected time.

I will happily create a PR with this solution, if desired.