file TORUS1:[GLL_RAW.INFO]HOW_TO_CALC_MUB_DELAY.DOC
						June 15,1996 - kes
						June 17,1996 - update Keith

	Joe Ajello related an easy method to understand how long it 
would take UVS and/or EUV RTS packets to get out of the MUB and to the
ground.  The MUB holds about 110 VCDUs (Virtual ?Channel Data Units, these
are groups of "frames" which in turn are groups of [any of the] instruments'
packets.)  A VCDU contains 446 bytes.

    110 VCDUs  *  446 bytes  *  8  bits  /  downlink rate in bits 
                      -----        ----                      ---- = seconds
                      VCDU         byte                      sec     delayed


The AMMOS display of the MUB status shows the number of VCDUs in the MUB.
If one is looking when the flush occurs you can see how many VCDUs are ahead
of the desired packets.  

Subtract from the downlink rate "a few bps" for the Reed-Solomon overhead.

========================================================================
From:   GLLSVC::KNAVIAUX     "Keith @ JPL/Pasadena,CA"
To:     PISCES::SIMMONS,PISCES::STEWART,PISCES::PRYOR
CC:     @[KNAVIAUX.DIS]JPLUVS.DIS
Subj:   RE: how to tell how long it will take for RTS data to get to 
	the ground

Hi Karen,

Just a quick reply on the algorithm below.  I believe it will give you a good
estimate of when to expect the data, however there are a lot of other factors
which could additionally delay the return of the data.  For example, if the
downlink is set to FILL instead of NORM, then fill data will be downlinked
in place of real data and this will delay the downlink.  FILL is interspersed
throughout the sequences.  Also, estimating the number of VCDUs in the MUB
at the time of the observation could be somewhat difficult as this is an
engineering value which isn't downlinked tothe ground very often (ie. there
is some cycle time on how often the MUB level is reported, but I'm not sure
how often this is in the Phase 2A system).  There are also s/c and ground
processing delays in creating and decommutating the telemetry frames which
will slightly delay the time when the data is available.  However, these
delays should be in the noise as compared to the wait caused by the "first-
in-first-out" downlink process.

Also, the MUB actually holds more than 110 VCDUs - the real number is closer
to 156.  During a cruise sequence, the upper portion of this is used for PB
processing space, so it is likely the MUB won't report higher than 110 during
PB, but if a lot of RTS is going into the buffer it could go above 110.  During
the encounter sequences, it could reach ~156 VCDUs before it overflows.  We
have designed the sequences to avoid overflows, so we don't plan to ever see
the MUB get above ~120-130 VCDUs.

Please let me know if you have any questions on anything I've said above.  But
I do think John's algorithm is a good estimate of the downlink time.

Keith.....

PS - Oh yeah, also remember the 38-40 minute OWLT for the transmission to 
	reach the ground from the s/c.