search

nasa / fprime

F´ - A flight software and embedded systems framework
https://fprime.jpl.nasa.gov
Apache License 2.0
10k stars 1.29k forks source link

FPrime GDS time conversions lose accuracy #2375

Closed rrieber closed 5 months ago

rrieber commented 9 months ago
F´ Version
Affected Component

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:

2023-11-15 00:15:31  (2(0)-1700007331:105410)
2023-11-15 00:15:31  (2(0)-1700007331:116909)
2023-11-15 00:15:31  (2(0)-1700007331:117097)
2023-11-15 00:15:31  (2(0)-1700007331:117104)
2023-11-15 00:15:31  (2(0)-1700007331:117115)
2023-11-15 00:15:31  (2(0)-1700007331:117118)
2023-11-15 00:15:31  (2(0)-1700007331:117122)
2023-11-15 00:15:31  (2(0)-1700007331:130901)
2023-11-15 00:15:31  (2(0)-1700007331:217087)
2023-11-15 00:15:31  (2(0)-1700007331:217156)
2023-11-15 00:15:31  (2(0)-1700007331:217172)
2023-11-15 00:15:31  (2(0)-1700007331:217175)
2023-11-15 00:15:31  (2(0)-1700007331:217176)

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.

LeStarch commented 9 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.

Ahmad-Bamba commented 5 months ago

Is this still relevant/wanted? I am interested in a first issue.

thomas-bc commented 5 months ago

@Ahmad-Bamba yes this is relevant! Feel free to open a PR any time and we'll make sure to review it