P1-C1 bias … and other Code biases

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

Leave a Reply