Number of decimal digits in OEM file

Hello everyone,
I’d like to know if it is possible to force 3 decimal digits for seconds in the date/time record when writing OEM files. I.e. I’d like to force format:
yyyy-mm-ddTHH:MM:SS.sss (3 decimal digits for seconds)
But the default configuration seems to produce format:
yyyy-mm-ddTHH:MM:SS.s (1 decimal digit for seconds)
And this last format is rejected by
A workaround to produce always 3 decimal digits would be appreciated.
Thank you.
Kind Regards,

The number of decimals in all CCSDS output data depends on the input.
We use Ulf Adam’s Ryū algorithm for this, which generates “the shortest decimal representation of a floating point number that maintains round-trip safety. That is, a correct parser can recover the exact original number.”

This choice was made to avoid truncation problems as CCSDS is a text-based format. I have encountered several times in my carrier accuracy problems linked to intermediate files with too few digits in entries. The worst case is when attempting to recover derivatives using polynomial fitting across several entries in an ephemeris: a lot of numerical noise is introduced by the truncation.

The point is “shortest decimal representation” may be very short if the number to be represented happens to be close to a decimal number with a small number of digits.

CCSDS does not mandates any number of digits for data, regardless it is a date or something else. In the case of dates, the standard reads:

In value fields that represent an absolute time tag or epoch, times shall
be given in one of the following two formats:
where ‘YYYY’ is the year; ‘MM’ is the two-digit month; ‘DD’ is the two-digit
day; ‘DDD’ is the three-digit day of year; ‘T’ is constant; ‘hh:mm:ss[.d→d]’
is the time in hours, minutes, seconds, and optional fractional seconds;
and ‘Z’ is an optional time code terminator (the only permitted value is ‘Z’
for Zulu, i.e., UTC). As many ‘d’ characters to the right of the period as
required may be used to obtain the required precision, up to the maximum
allowed for a fixed-point number. All fields shall have leading zeros. (See
reference [2], ASCII Time Code A or B.)
NOTE – During a leap second introduction, the value of the two-digit integer
seconds (ss) field shall be ‘60’ as specified in reference [2].

So the dates generated by OemWriter are fully compliant with CCSDS standard. We do however truncate one date to whole seconds only: the mandatory CREATION_DATE entry in the header (and there is probably no good reason for this truncation here).

However, there is a workaround because all dates (except CREATION_DATE) are formatted by a single method in the Generator used (which is either KvnGenerator or XmlGenerator). So you can override this method when building the generator. Here is how to do that for KVN, but the exact same feature can be used for XML:

// override dateToString to enforce 3 decimal digits exactly
// beware it is less accurate than the default behavior
// that uses Ryū algorithm
Generator generator = new KvnGenerator(output, paddingWidth,
                                       outputName, unitsColumn) {
            /** {@inheritDoc} */
            public String dateToString(int year, int month, int day,
                                       int hour, int minute, double seconds) {
                return String.format(Locale.US,
                                     year, month, day, hour, minute, seconds);

You can then use the generator as before when building your OEM writer.

I guess you should ask space-track to allow any number of digits in dates as per CCSDS standard.

1 Like

Dear Luc,
this is very helpful to me.
I’m not sure how to implement it and where.
This is my Python code:

        # OrekitEphemerisFile
        self.ephemerisFile = OrekitEphemerisFile()
        self.OrekitEphemerisSatellite = self.ephemerisFile.addSatellite(self.objId)
        oemFile = File(filepath)
        output = PrintStream(oemFile)
        # Header
        oem_header = Header(CCSDS_VERSION)
        oem_header.setCreationDate(AbsoluteDate(datetime.utcnow().isoformat(), UTC))
        # template
        template = OemMetadata(2)
        template.setObjectName(self.satelliteName.replace('_',' '))
        template.setCenter(BodyFacade("EARTH", CelestialBodyFactory.getCelestialBodies().getEarth()))
        template.setReferenceFrame( # ALERT: M2K frame hardcoded! Set the reference frame in which data are given: used for state vector and Keplerian elements data (and for the covariance reference frame if none is given)
        # writer
        writer = EphemerisWriter(WriterBuilder().buildOemWriter(), oem_header, template, FileFormat.KVN, "dummy", 60)
        writer.write(output, self.ephemerisFile)

Should I define a custom method, e.g. myKvnGenerator?
How should I call it from my code? maybe in line

EphemerisWriter(WriterBuilder().buildOemWriter(), oem_header, template, FileFormat.KVN, "dummy", 60)

but how?

Thank you very much.
Kind Regards,

Hi Alfredo,

Since you’re using Python, you can always read the file once written by Orekit to rewrite it and change the format of the dates using the datetime builtin library for example.


Dear Serrof,
Thanks for the suggestion, I’ll do that post-processing if I cannot find a way to implement Luc’s solution.