[Isocops] Partial Approval: IBEX Orbit# 154 v001 ATS (25 Jan - 4 Feb 12)
Ryan Tyler
Tyler.Ryan at orbital.com
Mon Jan 16 10:39:38 EST 2012
Sorry, wasn't looking at my email over the weekend.
I agree with the oef, the eclipse on 1/25 is very short and benign, and
that's the last eclipse until another benign (lunar) eclipse in April. The
ATS for orbit 154 should be just fine.
As to the CCVR issue, It appears that MPS has thought that the battery has
been at zero state of charge for a long time now so we need to convince MPS
that we have recharged the battery and get it back to normal working order.
Until we do that, we'll probably get the exact same message in the CCVR
every orbit, learn to ignore it, and find ourselves in trouble later on
because we ignored it.
So I've gone through a bunch of oef files and here's what I've found. In
the past, PowerModeInputChange never showed up on in the oef files. My best
guess is that this is because they are based on the history from the
previous orbit, so they started showing up when we started using the MPS
history correctly when we upgraded to the latest version of MPS. I only
mention this because it means that I can't go back and look at if something
similar happened on earlier cases of setting the long eclipse flag to ride
through an eclipse (such as the lunar eclipse on 6/10/10). Anyway, the
eclipse on 1/7/12 was the first of this season where we set the long
eclipse flag. Here is the oef for that period, with my notes interspersed
(in blue):
-----
2012-01-07T03:32:00.000Z,PowerModelInputChange,extendedProperty
(5nthruster):off,extendedProperty(payload):hvstandby,extendedProperty
(5nheater):off,extendedProperty
(spinpulseprotection):enabled,extendedProperty
(scstate):sci,orbit:151,extendedProperty(transmitter):off
>> Note that this PowerModelInputChange line, like every one that comes
before it, does NOT include extendedProperty(prewarmheater) or
extendedProperty(longeclipsemode). Those do not appear anywhere before the
following lines, even cases where we set the long eclipse flag for routine
cell balancing.
2012-01-07T07:24:00.000Z,ComponentModeChange,orbit:151
2012-01-07T07:24:00.000Z,ComponentModeChange,orbit:151
2012-01-07T07:24:00.000Z,PowerModelInputChange,extendedProperty
(5nthruster):off,extendedProperty(payload):hvstandby,extendedProperty
(5nheater):off,extendedProperty(prewarmheater):on,extendedProperty
(spinpulseprotection):enabled,extendedProperty
(scstate):sci,orbit:151,extendedProperty
(longeclipsemode):on,extendedProperty(transmitter):off
>> So here those two extendedProperty fields show up for the first time,
corresponding exactly to the command to set the long eclipse flag. I don't
know if MPS checks to see if an eclipse happens close to the setting of the
long eclipse flag or something like that, but somehow MPS decided that in
this case we were going through the full long eclipse activities, including
pre-warming of all components prior to the start of the eclipse. So at
this point, an additional load is turned on in the model corresponding to
all those heaters turning on to pre-warm components.
2012-01-07T08:03:13.000Z,ComponentModeChange,orbit:151
2012-01-07T08:03:13.000Z,PowerModelInputChange,extendedProperty
(5nthruster):off,extendedProperty(payload):hvstandby,extendedProperty
(5nheater):off,extendedProperty(prewarmheater):on,extendedProperty
(spinpulseprotection):enabled,extendedProperty
(scstate):hk,orbit:151,extendedProperty
(longeclipsemode):on,extendedProperty(transmitter):off
2012-01-07T08:03:43.996Z,10RECrossing,direction:desc,orbit:151,oMode:0
2012-01-07T08:53:10.068Z,PowerModelInputChange,extendedProperty
(5nthruster):off,extendedProperty(payload):hvstandby,extendedProperty
(5nheater):off,extendedProperty(prewarmheater):on,extendedProperty
(spinpulseprotection):enabled,extendedProperty
(scstate):hk,orbit:151,extendedProperty
(longeclipsemode):on,extendedProperty(transmitter):off
2012-01-07T08:53:36.812Z,PenumbraEntry,orbit:151
2012-01-07T08:53:36.812Z,EclipseEntry,orbit:151,moderate:false,long:false
2012-01-07T08:57:06.791Z,PenumbraExit,orbit:151
2012-01-07T08:57:06.791Z,UmbraEntry,orbit:151
2012-01-07T10:03:32.048Z,PenumbraEntry,orbit:151
2012-01-07T10:03:32.048Z,UmbraExit,orbit:151
2012-01-07T10:06:21.415Z,PowerModelInputChange,extendedProperty
(5nthruster):off,extendedProperty(payload):hvstandby,extendedProperty
(5nheater):off,extendedProperty(prewarmheater):on,extendedProperty
(spinpulseprotection):enabled,extendedProperty
(scstate):hk,orbit:151,extendedProperty
(longeclipsemode):on,extendedProperty(transmitter):off
2012-01-07T10:06:48.427Z,PenumbraExit,orbit:151
2012-01-07T10:06:48.427Z,EclipseExit,orbit:151,moderate:false,long:false
2012-01-07T12:00:00.000Z,ComponentModeChange,orbit:151
2012-01-07T12:00:00.000Z,PowerModelInputChange,extendedProperty
(5nthruster):off,extendedProperty(payload):hvstandby,extendedProperty
(5nheater):off,extendedProperty(prewarmheater):on,extendedProperty
(spinpulseprotection):enabled,extendedProperty
(scstate):hk,orbit:151,extendedProperty
(longeclipsemode):off,extendedProperty(transmitter):off
>> And here, at 12:00. is where the command to turn off the long eclipse
flag is sent. What you see is that even though extendedProperty
(longeclipsemode) changes from "on" to "off", extendedProperty
(prewarmheater) remains "on". From here on out, every single
PowerModelInputChange line in this and any subsequent oef files includes
both of these extendedProperty lines, and the prewarmheater on is always
on.
-----
So... For some reason, the prewarmheater in the model has been on
indefinitely, and my hypothesis is that the load the model uses for those
has put the spacecraft power negative, fully discharging the battery and
keeping it fully discharged (or at least preventing it from recharging such
that it goes back to zero when the transmitter or catbed heaters also get
turned on). I don't really have any idea what caused this to happen, or if
we should expect it to happen again in similar circumstances (such as the
upcoming eclipse in June when we'll need to set the long eclipse flag
again). But I have two suggestions on how we might be able to fix it:
1. In the most recent oef, manually change all the PowerModelInputChange
lines by changing the extendedProperty(prewarmheater) from "on" to "off".
I'm hoping that the power model will take this oef and alter the model
accordingly to turn off that heater load, and then pick up from there,
keeping that load off.
If that works, then, great, we're done. If it doesn't work, then:
2. Go into the text file that gives the parameters for the power model and
change the prewarmheater power value to 0W. This doesn't really solve the
problem, in that MPS will continue to think that the prewarmheater should
be on through eternity, but that will be transparent to the model since it
would have no effect. The reason that this option could be ok is that when
we do (eventually, perhaps for the eclipse on 10/2/14) the full hibernation
thing with the pre-warm, it will be a one-time thing where we analyze it
using the eclipse tool rather than through MPS, so we won't be using the
MPS power model results for that orbit anyway, and that's the only time
that the prewarmheater component should come on.
Anyway, that's the best I can figure out for this anomaly. It certainly
wouldn't be a bad idea to get an MPS software engineer on the case, but
failing that, one or both of my ideas above should hopefully get the power
model constraint checker functioning more-or-less normally again.
-Ryan
From: "Reno, Michelle" <mreno 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/ORB"
<IBEXops at orbital.com>, "ISOC at New Hampshire"
<isocops at lists.sr.unh.edu>, "John Cavallo"
<cavallo.john at orbital.com>, "Tapley, Mark" <mtapley at swri.edu>,
"Robert Lockwood" <Lockwood.Robert at orbital.com>, "Roland
Vanderspek" <roland at space.mit.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>
Date: 01/15/2012 12:34 PM
Subject: Partial Approval: [Isocops] IBEX Orbit# 154 v001 ATS (25 Jan -
4 Feb 12)
My approval is contingent upon CCVR violation being explained as not an
issue by Ryan Tyler.
Everything else looks good for IBEX_2012_025_o0154a_v001.scr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chelle Reno
Austin Mission Consulting
(210) 478-7337 (c)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: isocops-bounces at lists.sr.unh.edu on behalf of Ibex Mission Operations
Sent: Thu 1/12/2012 5:04 PM
To: Bret Hautamaki; IBEX-FDG; IBEXOPS/ORB; ISOC at New Hampshire; John
Cavallo; Tapley, Mark; Robert Lockwood; Roland Vanderspek; Ryan Tyler;
Sheral Wesley; Thomas Regiec; Tim Perry; Walker Cross
Subject: [Isocops] IBEX Orbit# 154 v001 ATS (25 Jan - 4 Feb 12)
Guys,
Here are the planning files and ATS for Orbit# 154.
Please respond to this thread for your approvals/comments.
All approvals/comments are required by 1900 UTC on 14 Jan 12.
Orbit# 152 Perigee activities start on 16 Jan 12 @ 1045 UTC
--
Sheral R. Wesley
SPVR., Satellite Operations
IBEX Mission OPS
(304) 279-6678[attachment "IBEX-Command-Approval-Checklist-Rev7a-o0154.pdf"
deleted by Ryan Tyler/ORBVA] [attachment
"IBEX-Command-Approval-Checklist-Rev7d-Omode-o0154.pdf" 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