Global Positioning System and Relativity

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Thomas</i>
<br />Does anybody know why the relativistic corrections in the Global Positioning System (GPS) are, as far as I am aware, actually physically applied to the satellite-clocks pre-launch?<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Which is easier to use to get the local time now in Tokyo:
(1) your own local time now, together with the correction to change that to Tokyo time, which might or might not change the calendar date?
or
(2) the local date and time now in Tokyo?

It is likewise much simpler for the receivers to get the time they need directly from the satellite rather than to have to apply corrections.

Moreover, the satellites send out coded range information in a repeating pattern that recycles several times each minute. If their clocks were allowed to drift by such large amounts, then the different satellites would be sending their signals at slightly different times. So the ground receiver would be using range information from satellite A at one time, and information from satellite B at a slightly different time. That would lead to error in the calculations of position on the ground. -|Tom|-

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by tvanflandern</i>
Which is easier to use to get the local time now in Tokyo:
(1) your own local time now, together with the correction to change that to Tokyo time, which might or might not change the calendar date?
or
(2) the local date and time now in Tokyo?<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Shouldn't the comparison be like this?: if your digital watch is running fast or slow, would it be easier to 1) trying to fix it so that it is running at the correct rate or 2) add on the known difference in your mind?
I know what I would choose to do.

The point is that, as far as I am aware, some of the relativistic corrections (i.e. the variable parts due to the eccentricity of the orbit etc.) are indeed done in the receiver. This raises the question why the (easier) correction of the constant amount isn't being done in the same way. Why go to all the troubles with modifying the hardware when the same thing can be achieved by adding a couple of lines of code to the software.

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">Moreover, the satellites send our coded range information in a repeating pattern that recycles several times each minute. If their clocks were allowed to drift by such large amounts, then the different satellites would be sending their signals at slightly different times. So the ground receiver would be using range information from satellite A at one time, and information from satellite B at a slightly different time. That would lead to error in the calculations of position on the ground.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">This could all be automatically taken into account if each satellite transmits the relevant bits of information.

---

www.physicsmyths.org.uk
www.plasmaphysics.org.uk

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Thomas</i>
<br />Shouldn't the comparison be like this?: if your digital watch is running fast or slow, would it be easier to 1) trying to fix it so that it is running at the correct rate or 2) add on the known difference in your mind? I know what I would choose to do.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">That is a good analogy. The "known difference" is always increasing, so you would have to do an elaborate calculation in your mind to figure out the present difference whenever you needed it. And if you are part of a group (as GPS satellites are), and someone says "let's synchronize watches so we can coordinate events exactly" over an extended period of time, you would have to remember a complex set of watch differences, a different one for each event where synchronized actions was required.

By contrast, if you set the rate correctly and synchronize once with all the others, your life just got much simpler. That is what GPS does.

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">Why go to all the troubles with modifying the hardware when the same thing can be achieved by adding a couple of lines of code to the software.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">The "modification" is not in the hardware as such. Atomic clocks count atomic cycles, such as transitions of the cesium atom, which occur at a very constant rate of roughly 10 billion per second. A cycle counter then determines the number of seconds elapsed. In GPS, one simply uses a different fixed number of cycles for the length of the second. Nothing could be easier.

To revert to your watch analogy, if resetting the rate were that easy, why would you even consider letting your watch continue to run at the wrong rate? There is no need to know what the wrong time reading would have been if the rate had not been set for synchronization with a master clock. So why go there when no one cares to know that information?

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">[tvf]: So the ground receiver would be using range information from satellite A at one time, and information from satellite B at a slightly different time. That would lead to error in the calculations of position on the ground.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">This could all be automatically taken into account if each satellite transmits the relevant bits of information.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">It could, but it would require an iterative process and quite complex calculations because the changes that occur during the synchronization offset period depend on the satellite orbit and on the reveiver location, the latter being initially unknown. So the receiver would need to have a fast microprocessor and an elaborate program instead of just taking a few simultaneous time differences and triangulating.

Again, why would anyone wish the system to be that complicated when it doesn't need to be? What possible virtue would there be in <i>not</i> changing that constant for the number of cycles comprising one second so that all GPS clocks are synchronized? -|Tom|-

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by tvanflandern</i>
<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">[tvf]: So the ground receiver would be using range information from satellite A at one time, and information from satellite B at a slightly different time. That would lead to error in the calculations of position on the ground.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">This could all be automatically taken into account if each satellite transmits the relevant bits of information.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">It could, but it would require an iterative process and quite complex calculations because the changes that occur during the synchronization offset period depend on the satellite orbit and on the reveiver location, the latter being initially unknown. So the receiver would need to have a fast microprocessor<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">The point is that these more complicated corrections are apparently already applied in the receiver, whereas the constant one corresponding to the pre-launch adjustment of the clocks isn't. Since the latter is just a constant factor applied to all the times, it is hence also just a constant factor applied to all the triangulation distances (x=ct). The amount of code that needs to be added to the already existing one should therefore be completely negligible.

---

www.physicsmyths.org.uk
www.plasmaphysics.org.uk

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Thomas</i>
The point is that these more complicated corrections are apparently already applied in the receiver, whereas the constant one corresponding to the pre-launch adjustment of the clocks isn't. Since the latter is just a constant factor applied to all the times, it is hence also just a constant factor applied to all the triangulation distances (x=ct). The amount of code that needs to be added to the already existing one should therefore be completely negligible.

<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Consider an example:

Four rockets with clocks start moving at constant speeds N, S, W and E. Each clock will tick at a different rate depending on the speed. Each person has a receiver and can transmit the time passed to a base to calculate the position of that receiver simply by using S = Vt. Then:

A. If the corrections are made in the clocks then you need only 4 multiplications to get the distance of each receiver.

B. If the corrections are made in base receiver, then you need to make an addition first. Now you have 4 additions + four multiplications.

If you increase the number of receivers and you need to perform real-time calculations for trajectory tracking (for military and other purposes, like for instance missile tracking) then in case B you are subject to additional calculation burden. Add to that sampling errors and alias, you now need as Tom argued a fast processor, instead of the simple calculator in case A.

The answer is that practical engineering considerations (like simplicity of receivers, cost etc.) call for A but theoretically, either A or B can be used.

Do not forget another issue, that of the liability of manufacturers of receivers that malfunction and calculate the wrong position. Limiting the calculations limits the possibility of error or even interference with the receiver electronics.

Makis

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by makis</i>
Consider an example:
Four rockets with clocks start moving at constant speeds N, S, W and E. Each clock will tick at a different rate depending on the speed<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">The point is that the heights as well as the speeds of all GPS-satellites are essentially identical and hence also the corrections required by General and Special Relativity respectively. This is the notorious amount of 38 microseconds per day for which the clocks have been corrected, but as I said above, it would be a trivial thing to take account of this in the receiver software instead.

<blockquote id="quote"><font size="2" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">Do not forget another issue, that of the liability of manufacturers of receivers that malfunction and calculate the wrong position. Limiting the calculations limits the possibility of error or even interference with the receiver electronics.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote"> As I said, the addition to the already existing program code by incorporating the 38 microseconds per day offset would be completely insignificant. Anyway, why would a program malfunction if it has no bugs and is thouroughly tested? It is much more likely that a hardware component on the satellite malfunctions and changes the time signal in an unpredictable and uncorrectable way.

---

www.physicsmyths.org.uk
www.plasmaphysics.org.uk