TM packets, field "absolute time", size is 2 bytes - is it correct? about prust HOT 5 CLOSED

@selmanozleyen please consider using CUC 4,2 (4 bytes seconds, 2 bytes fractions 1/65536)

from prust.

Thanks @selmanozleyen for your reply!

Nice, then we also allocate 6-bytes for time for now. I also looked into CCSDS 301.0-B-4, and i see, that it describes several formats, so, there is still a variety of stadard time formats, to choose from.
When we or you come to time implementation - let's sync again. I think it will help, if our libraries stay compatible to each other.

That pretty much answers my question, you may now close this "issue" whenever it's convenient for you.

from prust.

Hello @feiteira! CUC 4,2 seems very well-packed, nice :) Are you aware of any format, which could be even more size-efficient? 6 bytes per packet just on timestamp still seems a lot to me

from prust.

Hi, It was a temporary dummy field. I checked out CCSDS 301.0-B-4, I think it is important for us to use a standard here.
I will be changing the field from primitive to a struct and reserve 6 bytes for that place but since we don't use time in the software it will stay empty for now.
Edit From ECSS-E-ST-70-41C page 440 :

NOTE 2 For the possible values of the spacecraft time
reference status, refer to requirement 6.9.4.1c. If the
reporting of the spacecraft time reference status is
not supported, the spacecraft time reference status
field value is set to 0.

Also saw I this on page 40.

For each application process, whether that application process provides
the capability to report the status of the on-board time reference used
when time tagging reports shall be declared when specifying that
application process.

Currently, we don't have a concrete application process, but we are planning to adapt to FreeRTOS as we said in the OSCW.
If we had such things as processes, maybe where to refer for some specific fields would be more clear (there is also APID field for example where it is always 42 :D ). @feiteira what do you think ?

from prust.

Ok, I will close this issue. Might open a new one later concerning the values in that field. Thank you for reminding since it is important to be in sync with other softwares.

from prust.