<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:Courier;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:382873156;
mso-list-template-ids:1693581784;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Brian<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> MOIMS-NAV-EXEC [mailto:moims-nav-exec-bounces@mailman.ccsds.org]
<b>On Behalf Of </b>Oltrogge, Daniel<br>
<b>Sent:</b> 30 March 2019 01:01<br>
<b>To:</b> Berry, David S (3920)<br>
<b>Cc:</b> moims-nav-exec@mailman.ccsds.org<br>
<b>Subject:</b> Re: [MOIMS-NAV-EXEC] ODM P2.38 Comments (Part I)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Thanks for your inputs, David.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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:<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="mso-list:l0 level1 lfo1"><span lang="EN-US">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.<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1"><span lang="EN-US">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.<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1"><span lang="EN-US">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 <o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1"><span lang="EN-US">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.<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1"><span lang="EN-US">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.
<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">What do others think?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Have a great weekend, all …<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Dan<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Daniel L. Oltrogge<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Director, Center for Space Standards and Innovation<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Analytical Graphics, Incorporated<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Voice: 719-482-4552 </span><span lang="EN-US" style="font-size:13.5pt">҉</span><span lang="EN-US"> E-mail:
<a href="mailto:oltrogge@agi.com">oltrogge@agi.com</a><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Berry, David S (3920) <david.s.berry@jpl.nasa.gov>
<br>
<b>Sent:</b> Friday, March 29, 2019 6:12 PM<br>
<b>To:</b> Oltrogge, Daniel <doltrogge@agi.com><br>
<b>Cc:</b> moims-nav-exec@mailman.ccsds.org<br>
<b>Subject:</b> ODM P2.38 Comments (Part I)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier">Dan:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier">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<b> "</b>*"
= 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier">I'll continue my review of P2.38 and send you more (hopefully) soon.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier">David<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-US" style="font-size:12.0pt;color:black">MOIMS-NAV-EXEC <<a href="mailto:moims-nav-exec-bounces@mailman.ccsds.org">moims-nav-exec-bounces@mailman.ccsds.org</a>> on behalf of "Oltrogge, Daniel" <<a href="mailto:doltrogge@agi.com">doltrogge@agi.com</a>><br>
<b>Date: </b>Saturday, November 24, 2018 at 11:58 AM<br>
<b>To: </b>"<a href="mailto:moims-nav-exec@mailman.ccsds.org">moims-nav-exec@mailman.ccsds.org</a>" <<a href="mailto:moims-nav-exec@mailman.ccsds.org">moims-nav-exec@mailman.ccsds.org</a>><br>
<b>Subject: </b>[MOIMS-NAV-EXEC] Draft ODM v2.38 for your consideration/evaluation<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">Colleagues – <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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.”<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Looking forward to your comments and feedback - - and thanks very much for your patience in waiting for it !<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Dan<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Daniel L. Oltrogge<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Director, Center for Space Standards and Innovation<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Analytical Graphics, Incorporated<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Voice: 719-482-4552 </span><span lang="EN-US" style="font-size:13.5pt">҉</span><span lang="EN-US"> E-mail:
<a href="mailto:oltrogge@agi.com">oltrogge@agi.com</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<p>**********************************************************************</p><p> </p><p>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.<o:p /></p><p> </p><p>Airbus Defence and Space Limited, registered in England and Wales No.
02449259. Registered office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1
2AS, England.<o:p /></p><p> </p><p>**********************************************************************</p>
</body>
</html>