[MOIMS-NAV-EXEC] ODM P2.38 Comments (Part I)

Wed Apr 3 14:19:39 UTC 2019

Hi All,

Just a brief comment from me, I like the idea of having *_EPOCH_TZERO instead of a single EPOCH_TZERO as it means each of the type blocks  can have their own relative time linked to an event specific to the type block, it somehow feels complete to me too and makes blocks portable.  I do not see that there is any significant processing overhead as in my world any time read from the file would be immediately converted to an MJD for internal processing so referring a relative time to *_EPOCH_TZERO instead of EPOCH_TZERO makes little difference.

Best Regards

Brian

From: MOIMS-NAV-EXEC [mailto:moims-nav-exec-bounces at mailman.ccsds.org] On Behalf Of Oltrogge, Daniel
Sent: 30 March 2019 01:01
To: Berry, David S (3920)
Cc: moims-nav-exec at mailman.ccsds.org
Subject: Re: [MOIMS-NAV-EXEC] ODM P2.38 Comments (Part I)

Thanks for your inputs, David.

I would typically just respond to the CRM submitter, but since you’ve addressed the whole group on the relative time question, recall that there are several reasons that we’d discussed back in 2015 when we started down this path.  Those have not changed:

  *   Relative time allows for smaller message sizes by reducing the # of characters required to get the same precision.  When sharing an entire space catalog (currently ~20K objects, perhaps soon to expand to ~100K), space and network transfer time really do matter.  We currently receive 2.5 GB ephemeris files on a daily basis, and that is in a compressed state.
  *   Relative time circumvents any chance of 7 km positional errors when spanning leap seconds.  I know for fact that about 50% of the spacecraft user community fail to properly handle leap seconds when they share ephemerides, and that only occurs when they use absolute time formats.
  *   Most launch trajectories are specified in an Earth Fixed reference frame.  Relative times make more sense for a launch trajectory whose launch time slides from launch window open to launch window close.  If time were specified
  *   In your very nice flowchart it makes it look like a bunch of processing is required.  I believe this is a red herring.  In actuality, the recipient would create one time converter routine that would ingest the time string and an epoch_tzero_MJD0 in the event of DT= relative times, and then convert it to a time parameter of interest (for me, it’d be Modified Julian Day in its integer and fractional parts).  The expensive part of this ingestion process is actually to convert a yr/mo/dy/hr/mn/sc into MJD to make it internally useful for simulations etc; using absolute epoch on every single line means that much more CPU is required per line.  Whereas for relative time, you just divide seconds by 86400.0 and add to MJD0.  But even if I overlook that additional processing required to use absolute time references, all I’m needing to do for each time string is call a function, and once that function is created, the user would not be burdened by one format over the other.
  *   I absolutely know that one can operationally use both relative and absolute time formats in an ephemeris file because STK’s .e ephemeris and covariance files do exactly that:  they accommodate both absolute and relative time.  And I also know for fact that some users in the STK user community depend upon being able to specify time relative to an epoch, and others use absolute references.

Recall that only a few people requested absolute epoch time format.  I expended effort to accommodate their wishes.  But this does not detract from the reasons that drove my choice of relative time in the first place way back in 2015, and if you feel it’s too difficult having both, we can always take absolute time format back out to keep the message less complicated.  But personally I’d rather accommodate both user needs/perspectives where possible.

What do others think?

Have a great weekend, all …

Dan

Daniel L. Oltrogge
Director, Center for Space Standards and Innovation
Analytical Graphics, Incorporated
Voice: 719-482-4552   ҉   E-mail: oltrogge at agi.com<mailto:oltrogge at agi.com>

From: Berry, David S (3920) <david.s.berry at jpl.nasa.gov>
Sent: Friday, March 29, 2019 6:12 PM
To: Oltrogge, Daniel <doltrogge at agi.com>
Cc: moims-nav-exec at mailman.ccsds.org
Subject: ODM P2.38 Comments (Part I)

Dan:

I've been slowly working my way through the ODM P2.38... slower than I had hoped due to many other responsibilities, but I am making some progress.

Rather than make you wait forever to get comments from me, I've decided to send comments periodically. So attached you will find my CRM "Part 1" for P2.38. It covers from beginning of the book through the OPM, and from the beginning of Chapter 6 through 6.2.3 (yeah, I know... not very much... apologies). You will note there are a lot of things I think the group should discuss at Mountain View.

Also, I've been thinking quite a lot about the "relative time" topic, particularly since the use has expanded in P2.38 from merely EPOCH_TZERO to *_EPOCH_TZERO, where "*" = DEF, ORB, MAN, COV, STM. It occurs to me that I can see where an OCM producer might want to have the ability to use relative time calculations when they CREATE an OCM, but I think it makes for a lot of unnecessary processing for an OCM recipient. To illustrate what I mean, I've attached a rudimentary flowchart of the timetag processing a P2.38 OCM recipient would need to execute for EVERY timetag in the OCM. If a producer wants to write elaborate code for timetag processing, and use relative times in their OCM producing code, that's their business, but I don't see how all the relative time business really helps a consumer of the message. With an absolute timetag, the consumer would just have to read it and use it.

I'll continue my review of P2.38 and send you more (hopefully) soon.

Regards,
David

From: MOIMS-NAV-EXEC <moims-nav-exec-bounces at mailman.ccsds.org<mailto:moims-nav-exec-bounces at mailman.ccsds.org>> on behalf of "Oltrogge, Daniel" <doltrogge at agi.com<mailto:doltrogge at agi.com>>
Date: Saturday, November 24, 2018 at 11:58 AM
To: "moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>" <moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>>
Subject: [MOIMS-NAV-EXEC] Draft ODM v2.38 for your consideration/evaluation

Colleagues –

There is a whimsical children's fantasy movie called Mr. Magorium's Wonder Emporium (2007).  The movie isn’t all that noteworthy, except that Mr. Magorium repeatedly asserts “I’m going to die soon.”  When finally asked why he believes that, he says that as a young man he’d purchased “enough pairs of shoes to last a lifetime, and now I’m on my last pair.  Therefore I will die soon.”

In the same manner, I’ve been working on an update to the Orbit Data Message v.2.38 using version letters starting at “a” …  and I’ve now arrived at “z”.  Accordingly, I think it’s time to call v.2.38 finished.

Looking forward to your comments and feedback - - and thanks very much for your patience in waiting for it !

Cheers,

Dan

Daniel L. Oltrogge
Director, Center for Space Standards and Innovation
Analytical Graphics, Incorporated
Voice: 719-482-4552   ҉   E-mail: oltrogge at agi.com<mailto:oltrogge at agi.com>

**********************************************************************
This email is for the intended addressee only. The content of this email may be subject to UK Export Control Act (ECA) 2002 regulations. If you received it in error, or as an export, then you must not use, misuse, retain, disseminate or otherwise deal with it. Please notify the sender by return of e-mail. The views of the author may not necessarily constitute the views of Airbus Defence and Space. Nothing in this e-mail shall bind Airbus Defence and Space in any contract or obligation.

Airbus Defence and Space Limited, registered in England and Wales No. 02449259. Registered office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England.

**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20190403/52122441/attachment-0001.html>