[IGSMAIL-0484] Rogue SNR-8, 800, 8C tracking problems during AS

[Ulf]

******************************************************************************
IGS Electronic Mail      Tue Feb  8 16:59:42 PST 1994      Message Number 0484
******************************************************************************

Author: Ulf J. Lindqwister/JPL
Subject: Rogue SNR-8, 800, 8C tracking problems during AS

The Rogues in the Network seem to have settled down from last week.
At least we are seeing fewer tracking problems while the GPS signal is
encrypted (AS on). It is not clear if the events of last week 
were transient (part of some special adjustments done by the Air Force) 
or mainly part of some Rogue firmware bug with a random behavior. 

We think we may have, however, found one cause of the tracking
problems for Rogues when AS is on. One of the features (in addition 
to several bug fixes) of the last firmware release (V7.5) was to make
the Rogue switch from P-codeless (x-correlation) to P-code tracking
as soon as the satellites stopped encrypting the signal. The idea was to
maximize the amount of P-code data collected, since in earlier versions
the Rogue would contionue to track in P-codeless mode until the satellite
set on the horizon (independent of when the satellite quit encrypting the
signal). This feature already exists on the TurboRogues (and are believed to
be working fine there). We suspect that the feature was incorrectly
implemented, possibly by reading the wrong data bit in the navigation message.
This could cause the Rogue to try to switch into P-code mode
at random times (while the satellite is still transmitting encrypted data).

At this point we are still evaluating the extent of the problem and we
are also trying to figure out a couple of workarounds, as described
below. For now I would suggest that we simply wait and observe for
another week before taking any action. A new software release would take
at minimum a month to accomplish, since this includes diagnostics & testing,
PROM re-programming for 30 sites, firmware shipping,
and installation at the sites. Hence, before embarking on a new release we
want to be reasonably sure that we have found the problem and that the
error is serious enough.

There are a few possible alternatives to simply observing for now:
1. P-codeless tracking
At the 'FIELD>' or 'ROGUE>' prompt on the Rogue receiver type:
    terminate  <CR>
    configure -x <CR>

(where <CR> is a carriage return)
The above commands will do the following: a) terminate the existing
tracks, and b) start up tracking on all satellites in P-codeless mode
(thereby bypassing the switch bug - thanks to Danny Van Loon/KOSG, for
noticing this - it was very helpful for our debugging efforts)
Note that this command will have to be re-issued every time power
is lost or the receiver reset. This also has the additional disadvantage
of tracking the Block I satellites (PRN 3, 12, 13) in P-codeless mode
(although they transmit P-code signals). To enable tracking in P-code
mode for the Block I satellites only (while the Block II track in P-codeless
mode), please contact me for further
details (it is a bit complicated). Also, remember that the Air Force
may at any time remove encryption on a Block II satellite. An advantage
of tracking in P-codeless mode for all satellites is that the existing
biases between the P-code and P-codeless pseudoranges will not be a
concern (could be troublesome when you are filtering mixed code data and
only solving for 1 clock). For carrier phase only solutions, however, 
the biases are not an issue.
2. Raising the horizon-mask to 15 degrees
At the Rogue prompt issue the commands:
    pps <CR>
    e
    15 <CR>
    <CR>      

This will set the horizon-mask to 15 degrees. Some of you have
noticed a reduction in loss-of-lock events after doing this - 
this could be related to the fact that the tracking switch to
P-code mode often seems to happen at the beginning of arcs
(although, this is still not well confirmed). 

Again, to reiterate, I think it is best at this point to wait
and observe, however, the suggestions above are not likely to
cause much harm as long as the constellation remains in AS mode.
I'll be in touch with more information in the near future - feel free
to contact me for questions/suggestions. Thanks for your patience.
    
 
- Ulf

=======================================================================
Ulf J. Lindqwister                 Telephone:   (818) 354 1734
GPS Networks & Operations Group    FAX:         (818) 393 4965
Jet Propulsion Laboratory          Email:       ujl at logos.jpl.nasa.gov
4800 Oak Grove Dr.
Pasadena, CA 91109
=======================================================================