Re: GPS Tip: Why does a GPS need to know where it is before it can compute where it is?

Sam Wormley wrote:
GPS Tip: Why does a GPS need to know where it is before it can compute where it is?
http://www.mobilecrossing.com/support/tips.html

This does seem strange but for the quickest fix a GPS depends on knowing the approximate location and the current time. This is due to the fact that the satellites are all broadcasting on the same frequency and in order to lock on to a particular one it uses knowledge of the current satellite locations in the sky and orbit data to provide a lock. A lock is achieved by knowing which satellites to look for and by predicting the Doppler shift based on orbit knowledge to separate the satellite signals. Then it can track the satellite.

Doppler shift is why a train whistle changes pitch (frequency) when it goes past you. Predicting the change in frequency is used to align the special satellite carrier data with the actual satellite. This is done in a matter of a few seconds and then the download of ephemeris data and clock data can begin. Once the download is done it can be used to compute the fix. Without being able to predict the sky satellite locations the GPs will have to search the sky. This can take 5 minutes or more before it can even track the satellite.

Note that after the fix is calculated the GPS will use the Doppler data to calculate the current velocity.

See: http://www.mobilecrossing.com/support/tips.html


Almanac data is used by GPS receiver to assign PRN codes to
correlators (or correlator channels) when attempt to lock onto
satellites. If a receiver had 32 set of correlators instead of
8 or 12, almanac data would not be so important.

The almanac data allows the receiver to "search" for those
satellites which are likely to be "visible" for the date, time
and location on the earth. GPS receivers store almanac data
in volatile memory so that the receiver doesn't have to be
re-acquired that data each time it is turned on.

Ephemeris data is required for each satellite that will be used
in a position velocity time (PVT) calculation, for it contains
the Keplerian elements for precise location of each satellite.
Ephemeris data updated on the satellites every few hours.


SOME TECHNICAL BACKGROUND -- EPHEMERIS AND ALMANAC DATA

The GPS Navigation Message
o Each satellite transmits its own ephemeris data every 30 seconds
o Each satellite transmits the almanac for the whole constellation ever
12.5 minutes.

Interface Control Document ICD-GPS-200C
http://www.navcen.uscg.gov/pubs/gps/icd200/default.htm
http://edu-observatory.org/gps/ICD-GPS-200C_Fig20-1/

Also see: http://www.navcen.uscg.gov/pubs/gps/gpsuser/gpsuser.pdf



REFERENCES
1. GPS Interface Control Document ICD-GPS-200 - NAVSTAR GPS Space Segment and
Navigation User Interfaces
2. Wells D, Guide To GPS Positioning, 2nd ed, Canadian GPS Associates, Frederiction,
New Brunswick, Canada 1987
3. Email - Bill Straka


GPS MESSAGE CONTENT
see: http://edu-observatory.org/gps/Wells.et.al.6.06.gif
http://edu-observatory.org/gps/ICD-GPS-200C_Fig20-1/

SUBFRAME 1

Flags (L2 code & data; week #; satellite accuracy and health)
Age of Data
Satellite clock correction coefficients

Telemetry Word (TLM) - Each TLM word is 30 bits long, occurs every six
seconds in the data frame, and is the first word in each subframe/page.
The format shall be as partially shown below. Bit 1 is transmitted
first. Each TLM word shall begin with a preamble (10001011) followed by
the TLM message, two reserved bits, and six parity bits. The TLM
message contains information needed by the authorized user.

Handover Word (HOW) - The HOW shall be 30 bits long and shall be the
second word in each subframe/page, immediately following the TML word.
A HOW occurs every 6 seconds in the data frame. The format and content
of the HOW shall be as partially shown below. The MSB is transmitted
first. The HOW begins with the 17 MSBs of the time-of-week (TOW) count.
(The full TOW count consists of the 19 LSBs of the 29-bit Z-count.
These 17 bits correspond to the TOW-count at the X1 epoch which occurs
at the start (leading edge of the next following subframe.

Word 3 in subframe 1 is the week number (WN), which gives you the date.
Combine the week number with the TOW, plus GPS origin date, and you
have GPS time. Actually, you need to look a little further on at the
SV's clock correction, drift rate and IODC (Issue of Data, Clock - in
other words, when the correction parameter was inserted into the
message), but this is pretty small.

In the present format of the message, there is no provision for giving
which 1024 week cycle you are in. There is some discussion of providing
a couple extra bits in the reserved parts of the message. For a receiver
built today, the way around the 1024 week cycle limitation is to have
the user's receiver provide that information (are you between 1980 and
1999? Are you between 1999 and .... etc, or simpler, are you in the
1980's, 1990's, 2000's, or whatever decade? or tie it closer to the
year.) It can be done as a user input, just like the time zone/daylight
time offset. Or, just use the ROM issue date or software version date.

This allows your GPS receiver to sync with GPS time.... Take a look
at subframe 4 page 18 for the relationship of GPS time with UTC.



|<--------- TLM Word -------->|<----------- HOW ----------->|
(word 1) (word 2) (word 3)

|1 |31 |61 |91 300
|---------------------|-|-----|----------------|-|--|-|-----|---------|-|---|-----|-|-----|----/ /---|
| | | | | | | | | | | | | | | |
| TLM |C| P | TOW | | |t| P | WN | | | | | P | |
| | | | MS 17-BITS | | | | | 10-BITS | | | | | | |
|10001011 | | |MSB LSB| | | | | | | | | | | |
|---------------------|-|-----|----------------|-|--|-|-----|---------|-|---|-----|-|-----|----/ /---|



SUBFRAMES 2 & 3
Orbit Parameters

|<--------- TLM Word -------->|<----------- HOW ----------->|
(word 1) (word 2) (word 3)

|1 |31 |61 |91 300
|---------------------|-|-----|---------------------|-|-----|-------|---------------|-----|----/ /---|
| | | | | | | | | | |
| TLM |C| P | HOW |t| P | IODE | C(rs) | P | |
| 22 BITS | | | 22 BITS | | |8 BITS | 16 BITS | | |
|10001011 | | | | | | | | | |
|---------------------|-|-----|---------------------|-|-----|-------|---------------|-----|----/ /---|
|1 |31 |61 |91 300
|---------------------|-|-----|---------------------|-|-----|---------------|-------|-----|----/ /---|
| | | | | | | | | | |
| TLM |C| P | HOW |t| P | C(ic) | | P | |
| 22 BITS | | | 22 BITS | | | 16 BITS |8 BITS | | |
|10001011 | | | | | | | | | |
|---------------------|-|-----|---------------------|-|-----|---------------|-------|-----|----/ /---|


SUBFRAME 4
Almanac for satellites 25-32 (pages 2-5, 7-10)
Ionospheric model, and UTC data (page 18) partially shown
Antispoof flag - 32 satellites (page 25)
Satellite configuration - 32 satellites (page 25)
Health of satellites 25-32 (page 25)

Reserved (pages 1,6,11,12,16,19,20-24)
Spares (pages 13-15)
Special messages (page 17)


|1 |211 219 227 |241 249 257 |271 279 300
|----/ /---|-------|-------|-------|-----|-------|-------|-------|-----|-------|-------------|-|-----|
| | | | | | | | | | | | | |
| | | t(ot) | WN(t) | P |dt(LS) |WN(LSF)| DN | P |dt(LSF)| SPARE |t| P |
| |8 BITS |8 BITS |8 BITS | |8 BITS |8 BITS |8 BITS | |8 BITS | 14 BITS | | |
| | | | | | | | | | | | | |
|----/ /---|-------|-------|-------|-----|-------|-------|-------|-----|-------|-------------|-|-----|
| | | |
(word 8) (word 9) (word 10)

Universal Coordinated Time (UTC) - Page 18 of subframe 4 includes (1)
the parameters needed to relate GPS time to UTC, and (2) notice to the
user regarding the scheduled future or recent past (relative to NAV
message upload) value of the delta time to to leap seconds dt(LSF),
together with the week number WN(LSF) and the day number (DN) at the end
of which the leap second become effective. "Day one" is the first day
relative to the end/start of week and the WN(LSF) value consists of
eight LSBs of the full week number. The user must account for the
truncated nature of this parameter as well as truncation of WN, WN(t),
and W(LSF) due to rollover of the full week number. The Command Segment
(CS) shall manage these parameters such that the absolute value of the
difference between the untruncated WN and WN(LSF) value shall not exceed
127. For more detail see section 20.3.3.5.2.4 of ICD-GPS-200.


SUBFRAME 5
Almanac for satellites 1-24 (pages 1-24)
Health of satellites 1-24 (page 25)

VELOCITY DETERMINATION

Keep in mind that most GPS receivers employ "smoothing filters" and so
instantaneous velocity reading during acceleration is not necessarily
accurate. However at constant velocity (and assuming no obstruction of
signals), the GPS receiver will likely measure velocity to an accuracy
of 0.2 m/s (0.7 kph or 0.4 mph) 2drms.

Ref: Misra & Enge "GPS: Signals, Measurements, and Performance" (2001)

Sec. 5.2.1 (pgs 196-197) Velocity Estimation

"The relative motion of a satellite and the user results in changes in
the observed frequency of the satellite signal. This Doppler shift is
measured routinely in the carrier tracking loop of a GPS receiver
[Section 9.6]. Given the satellite velocity, the Doppler shift can be
used to estimate the user velocity. The Doppler shift, or equivalently,
the range rate [Section 1.3.3], can be written as a projection of the
relative velocity vector on the satellite line-of-sight vector. The
measurement, however, is biased by the receiver clock bias rate (i.e.,
frequency offset), and what's actually measured is the pseudorange
rate.

"The delta pseudoranges obtained from carrier phase measurements are
proportional to the average pseudorange rates or the line-of-sight
velocity of the user relative to the satellite over the time interval.
The model for pseudorange rates can be obtained by differentiating
(5.1). It is left as an exercise to show that

[equation 5.28 is true]

where v_sup(k) [a vector quantity] is the satellite velocity vector,
known from the navigational message broadcast by the satellite; v is
the user velocity vector, to be estimated. Both v_sup(k) and v are
expressed in the ECEF coordinate frame. The user-to-satellite unit
vector 1_sup(k) is determined from an estimate of the user position;
b_dot is the bias of the receiver clock (m/s), and the
epsilon_sub_phi_sup(k) denotes the combined error doe to changes during
the measurement interval in the satellite clock, ionosphere and
troposphere. Note that the velocity of an object attached to the earth
is zero in the ECEF coordinate frame.

"The principal source of error in (5.28) throughout the 1990s was the
satellite clock frequency dithering due to SA. Now with SA gone, the
remaining errors arise from changes in the ionospheric and tropospheric
delays and in multipath, and are generally small. Problems, however,
can arise if the user dynamics are excessive. The delta ranges give
only average velocity over a time interval. High accelerations and
jerks would clearly be problematic. The PPS performance specifications
for velocity estimation (0.1 m/s rms in any direction; 0.2 m/s 2drms)
are based on a constant-velocity scenario [JPO(1991)].

"Equation (5.28) is linear in user velocity components, and can be
rewritten...

the combined set of measurements from K satellites can be written as a
set of equations compactly in matrix notation as

[equation 5.29]

where matrix G characterizes the user-satellite geometry, as defined
previously (5.10). It is interesting that the problem of estimation of
user velocity based on pseudorange rates is identical in structure to
that of estimation of user position from pseudoranges (5.9). A
least-squares solution and the DOP parameters can be defined, as
before, and related to the rms error in these estimates".
.

Relevant Pages

  • Re: NEW GPS with the best sensitivity of antenna!!!
    ... > I have head that under tree cover after rain GPS doesn't work. ... the geometry of the satellites being used with respect to receiver ... diffraction, ans scattering of the satellite signal by trees, utility ... Satellite clock--Errors in the transmitted clock, ...
    (sci.geo.satellite-nav)
  • Re: Evidences for the ether
    ... |> | How does a GPS receiver determine it's position? ... | A GPS satellite emits its time together with data that make ... | A receiver receives this signal. ... and the time of the satellite clocks when the signals were sent. ...
    (sci.physics.relativity)
  • Re: Evidences for the ether
    ... |> | how the GPS works. ... |> | A GPS satellite emits its time together with data that make ... |> | A receiver receives this signal. ...
    (sci.physics.relativity)
  • Re: Evidences for the ether
    ... |> | How does a GPS receiver determine it's position? ... | A GPS satellite emits its time together with data that make ... | A receiver receives this signal. ... Signals are recieved from a minimum of three satellites which ...
    (sci.physics.relativity)
  • Re: Speed accuracy ...
    ... My daughter asked me a question the other day about the accuracy of the speed readout from a car mounted GPS. ... However at constant velocity, the GPS receiver will likely measure velocity to an accuracy ... Given the satellite velocity, the Doppler shift can be used to estimate the user velocity. ... It is interesting that the problem of estimation of user velocity based on pseudorange rates is identical in structure to that of estimation of user position from pseudoranges. ...
    (sci.geo.satellite-nav)