TM packets, field "absolute time", size is 2 bytes - is it correct?

[kmarinushkin]

Hello, my name is Kirill! I work with TUDSaT team on a PUS implementation for our CubeSat. You might remember me from OSCSW 2020.
We start using Prust as a reference for our testing. Our test-cases revealed a contradiction between our implementation and Prust. We want to share with you our observations in a series of Github "issues". These are not bug-reports, but rather proposals for discussions, to figure out, what it the right way to do PUS.

---

In our test-case, we try to decode the example TM[1,7] packet from Prust wiki.

The issue we faced is in PUS TM packet field "absolute time" (ref. PUS document ECSS-E-ST-70-41C from 15 April 2016, Chapter 7.4.3.1). We did not yet decide, which format we want to use - PUS supports several (ref. Chapter 7.3.10). However, none of them is 2-byte long, as used by Prust, according to the example packet.

Did you find a way to decode absolute time in 2 bytes, or is it a overlook? I would be glad to reduce packet size in this field, so, if you found a way - I would be interested to know, how to achieve it

[feiteira]

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

[kmarinushkin]

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

[selmanozleyen]

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 ?

[kmarinushkin]

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.

[selmanozleyen]

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.