Soluciones Avanzadas Canarias S.L.

It has been reported over the last few days of 2010 that satellite PRN22 (G22, SVN 47) has had issues.

Essentially the satellite had an issue with its navigation signal in that the Differential Code bias had changed a whole lot! this meant that the P1C1 biases we were all applying to be able to mix the ‘C1′ and ‘P1′ measurements from the satellites Read more about the differential code bias issue.

After some investigation we finally found that indeed the P1C1 bias for SVN47 has changed from 0.05 ns to -2.6 ns, so from ~1.5 cm to about -80 cm. This huge change made all the G22 clock comparisons and combinations across the IGS contributing solutions very inconsistent for a few weeks until the situation was finally properly analyzed, studied and corrected.

G22 code bias change in Oct 2010 (A. Hauschild)

In the end there had been an unreported issue in the satellite on 30 Oct 2010, the satellite was set unhealthy via the navigation message, and later unsuable via NANU 2010133 for a 37 hour period and after reactivation the P1C1 bias was ~2.7 ns off!! This appears to have been caused by the switch on-board the spacecraft to a backup signal generator unit since at the anomaly start a significant signal power reduction was observed of more than 10 dB-Hz , which after the outage was fine.

Our wonderful colleague in the IGS A. Hauschild (DLR) produced the following technical note with all the details of this event. Happy reading!

PRN22SignalAnomalyTN1006

All the best!
Nacho

The IGS Reprocessing is a fantastic activity which I have highlighted before in this blog.

The IGS reprocessing involves recalculating all the GPS products (Station coordinate files, Satellite orbits, Station and Satellite clocks and Earth Rotation Parameters). Most of the IGS Analysis Centers are participating in this effort to take all the IGS GPS data from 1994 to 2008 and recalculating everything with the current state-of-the-art programs and techniques. This will produce more precise and continuous GPS products for the lifetime of the IGS. All the details can be found at the IGS Analysis Center Coordinator Website on Reprocessing.

At ESA/ESOC/OPS-GN (Navigation Support Office) we are one of the original IGS Analysis Centers so we wanted to participate in the Reprocessing. Unfortunately we had no spare processing capacity, and it was not clear what new machines should be bought to take on this challenge.

To help resolve this situation our company, SAC s.l., provided access to the ESA/ESOC Navigation support engineers an Intel Quad Core PC with Ubuntu 64bit, named SAC01. On this new machine we could start doing compilation tests, short runs, speed tests, data handling tests, etc. The machine was bought and configured by SAC s.l. in February 2008 and located in Las Palmas, Spain, at the professional housing services of a local Internet Service Provider (ISP). The machine was accessible via ssh and via FreeNX which allows for graphical display export easily to any other internet-able computer. The machine, SAC01, has installed the ESA/ESOC software Napeos POD software:

SAC01: Ubuntu QuadCore PC for POD

By the end of 2008 we will have reprocessed and delivered to the IGS all the days from year 2000 to 2007, using 150 stations per day. This has involved downloading and checking about 200Gb of GNSS data from the CDDIS. The processing was executed in parallel, leaving one core free for Operating System processes, so that 3 days are run at once. This raises the temperature of the PC considerably but there is enough cooling power at the ISP to handle it!!

The reprocessing has involved 150 stations per day (green crosses), it has generally taken 50 minutes per day (red crosses) using 30/31 satellites (blue stars), summaries of four of the years are shown below:

2000-2003 reprocessing statistics

Also noted are the total number of GNSS stations downloaded from the IGS (blue squares), and the stations rejected from the processing (pink squares).

At the start of 2009 the ESOC reprocessing results from SAC for 2000 to 2007 will have been checked, submitted and validated at the IGS making them the official ESA/ESOC contribution for those 8 years. The excellent results obtained finally convinced ESA/ESOC to buy two similar machines which will be used to produce the 1994-1999 reprocessing internally.

We are very happy at SAC s.l. to have supported ESA/ESOC in this innovative and successful way,

Ignacio Romero
Director

The C/A code and the P code encoded in the L1 “should” be coincident so that a pseudo-range derived with the C/A code; “C1″ should be equivalent to one derived with the P code; “P1″ so that we could use them interchangeably, in the IGS we agreed years ago to use P1,P2 & L1,L2 to create the iono-free observables to estimate GPS orbits, clock biases, etc.

The problem is that some receivers do not generate a P1 so we just use C1 in its place. Therefore we end up mixing in one epoch of data measurements for the satellites from many receivers and we have to mix C1 and P1 measurements from the same satellite and this is the problem, that the satellite clock estimated with this “mixture” will not be correct and our whole estimation of clock biases will be affected since therte is now way to separate the P1-C1 bias at this point.

An additional problem is that old receivers that do not generate P2 in the modern sense of an independent observation of the L2 code. The P2 pseudorange observable from this reduced list of receiver types (mainly older ones) are actually formed by a process which tracks the cross-correlated (P2-P1) pseudorange to produce a P2 which also needs to be corrected by the P1C1 bias!:

P2 = C1 + (P2-P1)

The corrections f(i) are applied as follows to C1 and the P2 if it needs correcting:

C1 –> C1 + f(i)
P2 –> P2 + f(i)

Since the signals encoded on L1 in the satellites are NOT coincident, it is easy to see that C1 and P1 are delayed one with respect to the other, so we cannot simply mix them in the processing without correcting one of them, in this case the agreement is to bring C1 to P1 by adding the P1-C1 bias to the original measurement.

Since we agreed to use P1 for all the receivers if the P1 is not available we take the C1 and add this correction factor which is very stable for each satellite but it is satellite specific and can be quite large:

biases f(i) are always in units of ns and are listed in PRN order from PNR01 thru PRN40:

data bias / -0.233d0, -0.033d0, -0.163d0, 1.234d0, -0.944d0,
+ 0.444d0, -1.132d0, -0.416d0, 0.366d0, -1.651d0,
+ 0.591d0, -9.999d9, 1.529d0, 0.108d0, -1.326d0,
+ -0.525d0, 1.391d0, -0.012d0, -2.026d0, -1.228d0,
+ -0.392d0, 0.532d0, 0.130d0, -0.069d0, 0.575d0,
+ 1.083d0, -0.189d0, -0.232d0, 0.643d0, 2.016d0,
+ -0.073d0, -9.999d9, -9.999d9, -9.999d9, -9.999d9,
+ -9.999d9, -9.999d9, -9.999d9, -9.999d9, -9.999d9 /

The biases are an output of the Ionospheric processing which characterise the Ionosphere state from the delay due to the effect the free electrons have on each frequency (L1,L2) as they enter the atmosphere, therefore since many receivers have both C1 and P1 the IGS Ionospheric Analysis Centers can see the “code bias” and they report it regularly to the IGS and everywhere else.

There is another bias from P1-P2 which the Iono people calculate since the P code should be encoded in L1 and L2 at exactly the same time but this is not so, therefore a bias between the P codes exist as well.

Yet another code bias between P2 and C2 (the new GPS L2C signal) but not much work has been done of this since it is new and few satellites have L2C.

In the beginning we corrected new modern receivers to mix them with the older ones (pre-2000 era):
Handling mixed receiver types

Later we started correcting the older receivers to make them consistent with the modern receiver measurements (from April, 2000 onwards):
New pseudorange bias convention

We now have the biases published officially by CODE for everyone to use:
Monitoring (P1-C1) code biases

The latest updated set of values:
Updated p1c1bias.hist

I was a recent arrival to the GNSS field in the year 2000 when president Clinton turned off by surprise, to us at ESA at least, the SA degradation to the GPS satellite clocks. At that time at the IGS we were only estimating orbits and clocks and for our work this SA-off had no immediate effect. It did have a longer term effect in the IGS as we started to plan for a clock prediction product latter materialized in the ultra-rapid product updated 4 times a day with 24 hours of predicted orbits and clocks. This product can now substitute the broadcast navigation message for real-time users to provide improved real-time positioning results.

Now president Bush has cleared the air and declared SA dead, by not adding the capabilty in the design of the new GPS satellites, as had been recommended by the DoD. I believe that this reflects the fact that a re-introduction of SA would harm the economic fabric that has been built of single frequency users which rely on stable satellite clocks for increased positioning performance.

SA was artificially “moving the satellite clock” so that the timing measurement which underlie the navigation system could not be as precised as it should be. The GPS satellites have 4 very precise atomic clocks on-board which are used to generate the timing messages, if you purposefully degrade the atomic clock output superposing a signal the timing messages are affected and the position cannot be calculated as precisely. The degradation was based on a function which only authorised military users could effectively remove from the timing message to recover the inherent accuracy of the system. Since SA has been off for almost 8 years and with the improvements in the quality of the GPS navigation message the GPS currently delivers accuracies much higher than originally specified for the civilian single frequency users.

The clock bias values calculated for that day for PRN10 easily show the jump from SA to no-SA on May 4, 2000 at 04:00 UTC indicating the recovery of the stable satellite clock bias :