<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 15 (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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
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:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:Courier;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1588806801;
mso-list-type:hybrid;
mso-list-template-ids:-661906072 -1122203048 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Thanks for your inputs, David.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What do others think?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Have a great weekend, all …<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Dan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Daniel L. Oltrogge<o:p></o:p></p>
<p class="MsoNormal">Director, Center for Space Standards and Innovation<o:p></o:p></p>
<p class="MsoNormal">Analytical Graphics, Incorporated<o:p></o:p></p>
<p class="MsoNormal">Voice: 719-482-4552 <span style="font-size:13.5pt">҉</span> E-mail:
<a href="mailto:oltrogge@agi.com">oltrogge@agi.com</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> 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></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:Courier">Dan:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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 style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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 style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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 style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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 style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:Courier">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:Courier">David<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:Courier"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span 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"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Colleagues – <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Looking forward to your comments and feedback - - and thanks very much for your patience in waiting for it !<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Dan<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Daniel L. Oltrogge<o:p></o:p></p>
<p class="MsoNormal">Director, Center for Space Standards and Innovation<o:p></o:p></p>
<p class="MsoNormal">Analytical Graphics, Incorporated<o:p></o:p></p>
<p class="MsoNormal">Voice: 719-482-4552 <span style="font-size:13.5pt">҉</span> E-mail:
<a href="mailto:oltrogge@agi.com">oltrogge@agi.com</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</body>
</html>