From:	GLLSVC::KNAVIAUX     "Keith @ JPL/Pasadena,CA" 17-JUL-1996 18:21:31.08
To:	PISCES::SIMMONS
CC:	@[KNAVIAUX.DIS]JPLUVS.DIS,PISCES::GEBBEN
Subj:	RE(2): ending PBT too early in a few cases

Hi again Karen,

I just realized I left off one piece of info.  Several of the NIMS ride-along
observations ended on non-RIM boundaries (ie. mf 77, mf 84, etc.), so our PB
datasets also ended early.  The other choice we had was to deselect at the
previous RIM boundary, but I thought it would be much better to get most of
an additional RIM than to cut off those extra mf's.

Keith.......

*******************************************************************************

From:	GLLSVC::KNAVIAUX     "Keith @ JPL/Pasadena,CA" 17-JUL-1996 09:31:34.10
To:	@[KNAVIAUX.DIS]JPLUVS.DIS
CC:	PISCES::GEBBEN
Subj:	RE: ending PBT to early in a few cases

Hi Karen,

I believe I know why the PB stops a bit early.  The recording of collected data
usually lags by at least 1 or 2 mfs (ie. data collected in mf 0 isn't written
to the tape until mf 1 or 2).  During G1 we didn't understand this very well and
when we did our recording, we stopped recording at the same RIM boundary that the
HV was turned off.  This means that the last data recorded on the tape is mf 89
or 90 of the previous RIM.  The lag in recording varies depending on the rate at
which the recording occurs.

In addition, there are several PBT rules which may require us to miss the final
few mf of data.  They are very complex, so I won't go into them in this email.
However, depending on the record scenario (ie. which type of records surround
our recording) we may be required to deselect from PB 2 mf early so that the CDS
PB manager won't place the system in a "continous search mode".  This continuous
search mode would cause the tape to slew through 2 tracks at 7.68 looking for
data which isn't there and causing a significant loss of PB time.  It will
recover automatically, but the observation it screwed up on would be skipped
and PB downlink time would be lost.

We're starting to get smarter about how we record and PB data, so future orbits
should start to look better.  I think we'll still have some lost mf at the end
of our recording in G2 and potentially C3, but hopefully we can avoid most of
the losses by simply recording a few mf longer.

Let me know if you have any questions.

Keith.......

********************************************************************************

From:	PISCES::SIMMONS      "KAREN SIMMONS AT LASP/COLORADO" 17-JUL-1996 00:37:43.83
To:	GLLSVC::KNAVIAUX
CC:	@JPLUVS
Subj:	ending PBT too early in a few cases

Keith,
	Please check the data sunnary that Jeremy sent.  He reports there
are several cases where the data quits before the end of the Rim of HV-off.
Is there an error in the PBT or in how we're using it?  Maybe if there is a
truncated frame that gets left hanging, we'd be better to request PBT entry
just PAST the mf of turn off?

Karen