[Isocops] [Isocdev] Orbit 82 STF questions

[Geoffrey B. Crew]

-- 

		Geoff (gbc at space.mit.edu)

On Tue, Jun 08, 2010 at 10:53:36PM -0400, Nathan Schwadron wrote:
> Note that isocops is the right list to use here .. 
> 
> On Jun 8, 2010, at 7:05 PM, Mark Tapley wrote:
> 
> > All,
> > 	OK, finally got time to look carefully over the Orbit 82 STF 
> > and .oef files, and I have a couple of questions. I'm looking at:
> > 
> > /home/gbc/IBEX/work/ops/hvscistf/IBEX_2010_170_05_02_v001.stf
> > 
> 
> That one is right .. 

Indeed.

You should find the filename listed as an input at the top of the ATS file.

As I also find the timestamp required for this file hard to parse, 

$ ibex_time -D 2010_170_05_02
Sat Jun 19 05:02:00.000000 UTC 2010
$ ibex_time -E 2010_170_05_02
2010/06:19:05:02:00
$ ibex_orbit -o -n 3 0
#orb year/ haso start      apogee    haso end     perigee A-Re P-Re Days
0080 2010/06:04:03:22 06:07:15:31 06:11:03:42 06:11:09:21 47.8 2.99 7.48
0081 2010/06:11:14:59 06:15:04:30 06:18:17:50 06:18:23:26 48.2 2.85 7.58
0082 2010/06:19:05:02 06:22:17:49 06:26:06:32 06:26:12:08 48.0 2.88 7.53

> > and
> > 
> > /home/gbc/IBEX/work/ops/hvscistf/IBEX_orbit_events.oef
> > 
> 
> I believe that is right .. Roland/Geoff?

One of the p/l ops work actions is to grab the most recent OEF
file and stuff it into the work area for convenience.  The full
set is of course in the archive

$ ls $IBEX_RAW/o007?/*oef

> 
> > 1) Are these the correct files to look at?
> > 
> > 
> > 	In the .stf file, I see:
> > 
> > ## 2010-06-20T12:12:48Z MOON+6.5-Entry(+6.499998)          78.88277954 (RE)
> > ## 2010-06-21T09:28:14Z MOON+0-Center(-0.000019)           82.78838326 (RE)
> > ## 2010-06-22T03:49:45Z MOON+6.5-Exit(+6.499976)           82.55686787 (RE)
> > 
> 
> I don't know what that is. Goeff?

The moon is a big thing, and it has phases, and I don't have a good model
of the star sensor blinding range in any case, so I stopped hacking the
code with leading and trailing edges 6.5 degrees away from the plane normal
to the IBEX spin axis. [* see below]

The underlying queries are available in spice_events.sh (and the underlying
executable below that) so if you want to tune this up you can.  ;-)

In any case, the Moon is 78 - 83 RE away which means the typical reduction
of the PMT voltage is called for.  If it's close, we have to lower the PMT
further.  I forget where the line is, but it's all in the script(s).

> > 2) What do those lines signify?
> > 
> > 
> > 	In the .oef file, I see:
> > 
> > 2010-06-25T21:13:26.190Z,StarTrackerOutageStart,orbit:82,dueTo:overlap
> > ...
> > 2010-06-27T10:53:04.828Z,RepointingTargetVector,vtsX:-0.09713517962079862,orbit:83,vtsZ:0.3961860371665777,vtsY:0.9130177330338543
> > 2010-06-28T05:16:46.190Z,StarTrackerOutageStop,orbit:83,dueTo:overlap
> > 
> > 	I think this implies a Repointing maneuver during a star 
> > tracker outage, and is in fact a symptom of the o83 Sun-Pointing 
> > problem we have been looking forward to.
> > 
> > 3) Is this correct?
> > 
> > 
> 
> Yes, that seems correct to me. 

Indeed.

> > 
> > 	In the .stf, I see:
> > 
> > 2010-06-20T12:12:48.000Z||CEU_LO_PMT_LVL       300
> > 2010-06-20T12:12:50.000Z||CEU_LO_IF_STAR_ADJ     0
> > #010-06-21T09:28:14.000Z centered; range 78.9 (Re)
> > 2010-06-22T03:49:43.000Z||CEU_LO_IF_STAR_ADJ   250
> > 2010-06-22T03:49:45.000Z||CEU_LO_PMT_LVL       800
> > 
> > 	But the .oef says:
> > 
> > 2010-06-20T06:32:23.102Z,MoonInLoFovStart,orbit:82
> > 2010-06-22T07:42:40.626Z,MoonInLoFovStop,orbit:82
> > 
> > 	I'm curious why the times don't correspond exactly. It looks 
> > like the PMT level goes down some 6 hours after the moon blanks it, 
> > and comes back up 4 hours before it can work.
> >
> > 4) Is this correct?

[*] I never did find out exactly what MPS/STK were using for their
calculations, and in any case what they were calculating didn't really
line up with the moon anyway, either.

A this point, we have 40 or more orbits with a sideways-V for the moon
and some student can go off and figure out what exact calculation gets
us the two edges exactly each time....

In any case, the design goal was to get a useful sideways-V with a bit
of margin, so we're close enough for government work.

> > 
> > 
> > 	When I put the vector from the repointing maneuver on 
> > 2010-06-18T18:20:08.616Z (per the .oef, this vector is: 
> > (0.031071571318898306,0.916920484258135,0.3978584962063797) ) into 
> > ibex-rotate, it gives the following sun angles on the following dates:
> > 
> > 2010-06-19T05:01:18.121Z	+0.529
> > 2010-06-26T06:31:05.880Z	+6.231
> > 
> > implying we are at good sun pointings at the beginning and end of the 
> > orbit, so I should not worry about that (even with a 1 degree margin 
> > for error).
> > 
> > 5) Did I do that correctly?

Well, yes, but you forgot that we CANNOT do THAT maneuver because the
star tracker is blinded.

Instead, we'll wait for the 14 Re ascending point (which is in the next
ATS as it's after the 10 Re ascending line in space) and aim at the SUN.

> > 
> > 
> > 	Pending resolution of these questions, I'll approve the .stf. 
> > If needed, I think I can approve immediately, since it does sot look 
> > like any of these pose a threat to the spacecraft, but I'd like to 
> > understand the above things first if I can.
> > 
> > 
> > -- 
> > 						- 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.
> > 
> > Please restrict discussions on this email list to non-ITAR sensitive topics.
> > _______________________________________________
> > Isocdev mailing list
> > Isocdev at lists.sr.unh.edu
> > http://lists.sr.unh.edu/mailman/listinfo/isocdev
> 
> 
> Please restrict discussions on this email list to non-ITAR sensitive topics.
> ______________________________________________
> Isocops mailing list
> Isocops at lists.sr.unh.edu
> http://lists.sr.unh.edu/mailman/listinfo/isocops