[Isocops] Fwd: Re: [Ibex-soc] IBEX Orbit# 87 ATS (27 July - 4 Aug 10)

Ryan Tyler Tyler.Ryan at orbital.com
Fri Jul 16 15:55:02 EDT 2010


One thing I will note is that the short oef begins at a very round number,
which means that the outage didn't start normally because when the scenario
started the outage was already underway (this is explained by the fact that
the oef is for orbit 87 but the outage happens during orbit 86). I don't
know if this explains what you're seeing, but some things come out weird
when things start artificially rather than in their normal context.

If that's not it, I don't know when the long oef was generated, but maybe
it was generated before we changed the outage threshold in MPS a few weeks
ago.


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Mark Tapley <mtapley at swri.edu>                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Ibex Mission Operations <ibexops at gmail.com>, Bret Hautamaki <hautamaki.bret at orbital.com>, IBEX-FDG <IBEX.fdg at applieddefense.com>, IBEXOPS/BU      |
  |<ibexops at bu.edu>, IBEXOPS/ORB <IBEXops at orbital.com>, ISOC at New Hampshire <isocops at lists.sr.unh.edu>, John Cavallo <cavallo.john at orbital.com>,   |
  |Robert Lockwood <Lockwood.Robert at orbital.com>, Roland Vanderspek <rvdspek at bu.edu>, Ryan Tyler <tyler.ryan at orbital.com>, Sheral Wesley             |
  |<wesley.sheral at orbital.com>, Thomas Regiec <regiec.thomas at orbital.com>, Tim Perry <perry.tim at orbital.com>, Walker Cross                           |
  |<Cross.Walker at orbital.com>, Mark Tapley <2103794635 at messaging.sprintpcs.com>                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |07/16/2010 03:50 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Fwd: Re: [Ibex-soc] IBEX Orbit# 87 ATS (27 July - 4 Aug 10)                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





All,
             Ok, I looked over the plots Ryan sent in the attached word
doc, and based on that I think we are OK. In any case, the question I
had doesn't directly affect the content of
IBEX_2010_208_00_00_v001.scr, so I approve that.

             There is a contact on the 27th, running from 11:33 to 12:12
(transmitter on times). That contact is the one wherein we will learn
that the inertial maneuver did in fact work like we thought it
should, i.e. it was not affected by star tracker outage. I'm becoming
a bit more focused on the importance of that contact.

             I think we should definitely have a contingent CAR in place
to prevent the ASCENDING macros from executing starting around 16:52
on the 27th if the maneuver did *not* go as planned (and I think Tim
has already written that(?)).

             In addition, we should be pretty prepared to quickly schedule
another contact if we have station problems or other issues with that
contact. Ideally it would be within the next 5 hours or so, although
we don't have pointing issues for about 20 hours after the scheduled
contact even if the maneuver does nothing at all. I note that the
contact in question is with Australia - is there another station
available for the next 5 hours? If not, what about the next 18 or so
hours?

             I'm also still curious why the short .oef and the forecast
.oef disagree; I guess we can continue to check both, but it would be
nice if they said the same thing!

>Date: Fri, 16 Jul 2010 13:55:43 -0400
>From: Ryan Lebois <rlebois at applieddefense.com>
>Subject: Re: [Ibex-soc] IBEX Orbit# 87 ATS (27 July - 4 Aug 10)
>To: Mark Tapley <mark.tapley at swri.org>
>Cc: Michelle Reno <michelle.reno at swri.org>,
>         Sheral Wesley <wesley.sheral at orbital.com>,
>         Lisa Policastri <lisa at applieddefense.com>
>
>Mark,
>
>While I cannot explain the difference in the outage times for the
>short oef and forecast oef, I feel like this outage has come up
>enough to warrant a little more explanation. I am attaching some
>brief notes on the outage and 2 plots that tell the story of what
>we're seeing. If you have any more questions about the actual outage
>feel free to let me know and I'll do my best to answer them.
>
>The only thing I can think of for the oef difference would be
>something to do with the start time selected for creating the short
>oef. The fact that the outage start time is an even minute is
>something I have seen before when the short oef starts in the middle
>of an outage. However, I don't think this explains the strange Moon
>outage times that it adds in... All I can conclude is that the FDG
>model shows two distinct outages as described in the attached notes
>and the latest Star Tracker Outage reports, and neither of these
>outages appear to be a problem.
>
>Ryan Lebois
>IBEX Flight Dynamics
>
>On Thu, Jul 15, 2010 at 5:58 PM, Mark Tapley
><<mailto:mtapley at swri.edu>mtapley at swri.edu> wrote:
>
>At 11:46 -0400 7/15/10, Ibex Mission Operations wrote:
>
>Please review the ATS for Orbit# 87
>I have included the battery balancing commands
>
>Approval/comments for the ATS are needed by COB Friday, 16 July 10
>The ATS will be uploaded during one of the Orbit# 85  perigee
>contacts listed below in UTC
>IBEX,USAK01,ADD,07/19/10,200,11:00:00,07/19/10,200,12:10:00,,LAHO
>160K IBEX Orbit# 85 SSR_Dump/Tracking
>IBEX,USHI01,ADD,07/20/10,201,07:30:00,07/20/10,201,08:05:00,,LAHO 2K
>IBEX Orbit# 85 Tracking Contact
>
>
>
>Sheral,
>        looked over the attached files. One interesting thing caught
>my eye. The  short .oef file, IBEX_2010_Orbit87_v001.oef, says:
>
>2010-07-27T02:00:00.000Z,StarTrackerOutageStart,orbit:86,dueTo:overlap
>2010-07-27T07:16:33.245Z,Perigee,orbit:86
>2010-07-27T07:31:48.185Z,StarTrackerOutageStart,orbit:86,dueTo:moon
>2010-07-27T07:41:44.932Z,StarTrackerOutageStop,orbit:86,dueTo:overlap
>2010-07-27T10:39:28.379Z,StarTrackerOutageStop,orbit:86,dueTo:moon
>
>
>but the Forecast .oef file,
>IBEX_2010_Forecast_15July10-23Oct10_v001.oef, says:
>
>2010-07-26T02:25:23.395Z,StarTrackerOutageStart,orbit:86,dueTo:overlap
>2010-07-26T21:40:10.652Z,15RECrossing,direction:desc,orbit:86
>2010-07-27T01:39:55.832Z,10RECrossing,direction:desc,orbit:86,oMode:0
>2010-07-27T07:16:33.245Z,Perigee,orbit:86
>2010-07-27T07:35:19.913Z,StarTrackerOutageStop,orbit:86,dueTo:overlap
>
>With the short file claiming the outage lasts a lot longer, up to
>10:39:28. This is interesting because according to the o0086 ATF,
>the repointing maneuver starts in between the two times (but not
>much, almost to the end of even the later prediction):
>
>  @ACT_SetThrustEnable ENABLE $TIME=2010/07:27:10:38:22
>  @ACT_SetThrustEnable DISABLE $TIME=2010/07:27:10:53:22
>
>******
>
>How are the star tracker outage times calculated differently between
>the two files?
>
>******
>
>Ken reports that the instrument commands match the STF, good.
>
>Ascending and Descending commands match up with 15 Re times, good.
>
>Ground contact times match the transmitter on times, good.
>
>According to ibex_rotate, sun angles at the time of the inertial
>maneuver, at the next Ascending 15 Re crossing, and at the next
>descending 15 Re crossing are all good (1.01, 0.435, and 6.228
>degrees respectively):
>
>[tapley at ena ~]$ ibex_rotate -o -u
>-0.6709580708861025,0.6801661773297624,0.2952782388348625 -w
>ibex-sun -t 2010/08:03:17:20:27
>Quaternion    +0.000000,+0.000000,+0.000000,+0.000000
>  points axis  +1.000000,+0.000000,+0.000000
>  towards ECI  -0.670958,+0.680166,+0.295278
>  which is     R.A. +134.610 Decl. +17.174
>  missing      R.A. +133.593 Decl. +17.418 (ibex-sun)
>  error is     R.A.   +1.017 Decl.  +0.244
>  for a total  1.001 deg
>[tapley at ena ~]$ ibex_rotate -o -u
>-0.6709580708861025,0.6801661773297624,0.2952782388348625 -w
>ibex-sun -t 2010-08-04T08:22:39.899Z
>Quaternion    +0.000000,+0.000000,+0.000000,+0.000000
>  points axis  +1.000000,+0.000000,+0.000000
>  towards ECI  -0.670958,+0.680166,+0.295278
>  which is     R.A. +134.610 Decl. +17.174
>  missing      R.A. +134.172 Decl. +17.292 (ibex-sun)
>  error is     R.A.   +0.438 Decl.  +0.118
>  for a total  0.435 deg
>[tapley at ena ~]$ ibex_rotate -o -u
>-0.6709580708861025,0.6801661773297624,0.2952782388348625 -w
>ibex-sun -t 2010-08-11T06:12:31.549Z
>Quaternion    +0.000000,+0.000000,+0.000000,+0.000000
>  points axis  +1.000000,+0.000000,+0.000000
>  towards ECI  -0.670958,+0.680166,+0.295278
>  which is     R.A. +134.610 Decl. +17.174
>  missing      R.A. +140.798 Decl. +15.307 (ibex-sun)
>  error is     R.A.   +6.189 Decl.  +1.867
>  for a total  6.228 deg
>[tapley at ena ~]$
>
>
>Pending being convinced that star tracker outage times are OK, I'll
approve.
>--
>                                                - Mark     210-379-4635
>-----------------------------------------------------------------------
>Large Asteroids headed toward planets
>inhabited by beings that don't have
>technology adequate to stop them:
>
>                                Think of it as Evolution in Fast-Forward.
>
>
>
>
>--
>Ryan Lebois
>
>Applied Defense Solutions
>
><mailto:rlebois at applieddefense.com>rlebois at applieddefense.com
>
>Office 301.483.4910
>
>Mobile 410.251.0954
>
>Content-type:
>  application/vnd.openxmlformats-officedocument.wordprocessingml.document;
>  name="Star Tracker Outage 7_26_2010.docx"
>Content-disposition: attachment; filename="Star Tracker Outage
7_26_2010.docx"
>X-Attachment-Id: f_gbpbn5yu0
>
>
>Content-type: application/msword; name="Star Tracker Outage 7_26_2010.doc"
>Content-disposition: attachment; filename="Star Tracker Outage
7_26_2010.doc"
>X-Attachment-Id: f_gbpbx66v1
>


--
                                                                         -
Mark     210-379-4635
-----------------------------------------------------------------------
Large Asteroids headed toward planets
inhabited by beings that don't have
technology adequate to stop them:

                                                 Think of it as Evolution
in Fast-Forward.[attachment "Star Tracker Outage 7_26_2010.doc" deleted by
Ryan Tyler/ORBVA]



-----------------------------------------
Notice:  This e-mail is intended solely for use of the individual
or entity to which it is addressed and may contain information that
is proprietary, privileged and exempt from disclosure under
applicable law.  If the reader is not the intended recipient or
agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly
prohibited.  This communication may also contain data subject to
U.S. export laws.  If so, that data subject to the International
Traffic in Arms Regulation cannot be disseminated, distributed or
copied to foreign nationals, residing in the U.S. or abroad, absent
the express prior approval of the U.S. Department of State.   If
you have received this communication in error, please notify the
sender by reply e-mail and destroy the e-mail message and any
physical copies made of the communication.  Thank you.


More information about the Isocops mailing list