![]()
TIME-TAG SYNCHRONISATION |
There are in fact two effects (section 6.3.8):
The former condition must be satisfied at the microsecond level, while
the latter only at the millisecond level. With today's code-correlating
receivers this is easily accomplished. As data is collected by the receiver,
an internal "navigation solution" is performed that solves for
the receiver clock offset to GPS Time (
rcj ) using pseudo-range
data. Even under conditions of Selective Availability, such a calculation
ensures that the receiver clock can be synchronised to GPST to the level
of a few microseconds. The problem is, however, that the time-tag interval
must be correctly initialised in all receivers, for example collect data
on each minute, or even minute only, etc. Mixing receivers of different
types may therefore be a problem unless it is absolutely clear that the
time-tags (although individually accurate) correspond to the same epoch.
This synchronisation is therefore a task of the field procedures.
It does not mean that the observations at the receivers
must be made within a microsecond of each other!
If time-tag synchronisation is not carried out within the receiver, the pseudo-range data can be processed at a pre-processing step. Unlike the standard navigation solution in which the receiver is assumed to be in motion, and a separate clock offset parameter is estimated each epoch, the pseudo-range solution has the following characteristics (section 7.2.2):
| (7.3-1) |
The time-tags are then corrected for this offset, that is:
| (7.3-2) |
However, the data at this epoch to all the satellites are not corrected
for clock error as the estimates of
rcj are not accurate
enough to perform the following transformation to the sub-nanosecond accuracy
level:
| for pseudo-ranges to all satellites i | (7.3-3a) |
and
| for carrier phase to all satellites i | (7.3-3b) |
Back To Chapter 7 Contents
/ Next Topic / Previous Topic
© Chris Rizos, SNAP-UNSW, 1999