Closed rrieber closed 5 months ago
The offending line is here: https://github.com/fprime-community/fprime-tools/blob/bcfba3ee3a1d1dac354990e535fc254402208e35/src/fprime/common/models/serialize/time_type.py#L292C50-L292C52
The format should end with .%f
to add microseconds. Although it is probably cleaner to just use dt.isoformat(timespec="microseconds") as that is a standard implementation.
Is this still relevant/wanted? I am interested in a first issue.
@Ahmad-Bamba yes this is relevant! Feel free to open a PR any time and we'll make sure to review it
Feature Description
fprime-gds creates the file,
channel.log
. This log shows a list of channels and the corresponding time-stamp in two different time systems: UTC and spacecraft clock (referring to as SCLK from henceforth).Working on the CADRE mission, the SCLK is telemetered as a U32 for integer seconds and a U32 for microseconds. This combined time is then converted to UTC, which is displayed in
YYYY-MM-DD HH:MM:SS
.I probably can't publicly share channel data, here are just the timestamps from this file:
Note how the sub-seconds are increasing, yet the UTC is static. This means that a user needing fine-resolution on time is precluded from working in UTC. This also means that a user trying to sort data by UTC will never get data in the correct order.
The fundamental philosophy that must be applied to the ground system is that any conversion (time, DN->EU, units, etc.) should never decrease the resolution of the source data.
The request here is to update the time conversion routine to at minimum carry forward the resolution of the core SCLK. A simplification could be made such that UTC is converted to microsecond-resolution and mission-specific implementations could update the routine for higher accuracy if required.
Rationale
Make it more operable.