[Css-csts] Clarification of CSTSWG Action #08-1107
Wolfgang.Hell at esa.int
Wolfgang.Hell at esa.int
Fri Dec 14 07:55:17 EST 2007
John,
Your understanding is fully correct. The intent is not to impose on any SLE
return service provider to support the pico-seconds resolution, let alone an
accuracy in that order of magnitude. However, we do have providers that
guarantee an accuracy that is better than the resolution that the presently
defined ERT annotation format supports and we have mission requiring such
accuracy and therefore also a finer resolution. We expect the number of such
providers and such missions to grow and therefore we should offer an
appropriate 'home' for a finer resolution time tag. Luckily enough, the
present ASN.1 specification enables the introduction of such time tag that is
backward compatible.
Taking the RCF book as example, we will have to change the ASN.1 as discussed
at the meeting. In addition, clause 3.1.7.2 will have to be updated as to
cover both ERT formats that in future shall be supported. We propose to leave
clauses 3.1.7.3 and 3.1.7.4 unchanged. We may want to think about extending
Annex D such that we make clear that support of the presently specified ERT
format is mandatory, while support of the extended format is optional.
Best regards,
Wolfgang
"John Pietras"
<john.pietras at gst.
com> To
Sent by: <css-csts at mailman.ccsds.org>
css-csts-bounces at m cc
ailman.ccsds.org
Subject
[Css-csts] Clarification of CSTSWG
13/12/2007 20:11 Action #08-1107
Members of the CSTSWG ---
Action #08-1007, "Return services: Time accuracy down to pico-second
(ASN.1 backward compatible update)", was assigned to Tim Ray and me to
determine if such a change is acceptable from the NASA perspective. This
Action resulted from the Heppeneheim discussion of SLE Services Issue
#4, Return Services - Time Accuracy, which states:
"The current Recommendation covers the time accuracy to the
micro-seconds. The possibility of using a time accuracy down to the
nano-second is required (GAIA).
The choice (micro- or nano-) could be covered by configuration (it's not
a service instance issue) and be backward compatible (ASN.1 choice would
not impact existing implementation).
Time ::=
CHOICE
{ ccsdsFormat [0] TimeCCSDS
, picoFormat [1] TimeCCSDSpico -- New line to
support
pico second.
}
ESA supports the change.
Impact: Return book update required, SLE API book update required.
Conclusion: Technical error (as book forgot to include the additional
time accuracy of CCSDS)."
(See section 9.2 of the Minutes of Meeting (MoM) from Heppenheim).
My question is this - is the proposed change to require *accuracy* to
the picosecond, or merely to support *resolution* to the picosecond?
The current return SLE transfer service earth-receive-time parameters
have a one-microsecond resolution, but only a one-millisecond accuracy
requirement (the statement of Issue #4 erroneously states "The current
Recommendation covers the time accuracy to the micro-seconds").
Individual return SLE implementations *may* provide
greater-than-microsecond accuracy, but all SLE return implementations
are required to provide at least microsecond accuracy.
Supporting a resolution to the picosecond deals with whether
implementations can be made to support the extended time code format,
and is not technically difficult given that it would be simply added to
the existing ASN.1 CHOICE structure for Time. However, requiring that
the accuracy be to the picosecond is likely to impose a much heavier
burden.
I wasn't present for the discussion in Heppenheim, but the emphasis on
the MoM on the ASN.1 aspect makes me believe that this is really just
about the ability to use a picosecond resolution, but the minimum
required accuracy would still be only to the millisecond. Would someone
(Wolfgang?) please confirm or correct this interpretation? Thank you.
Best regards,
John
John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct: +1-240-542-1155
GST Main: +1-301-474-9696
Fax: +1-301-474-5970
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list