Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
Drexel University or The Math Forum.
|
|
|
|
Re: special relativity's second postulate is invalid
Posted:
Jan 13, 2013 5:36 PM
|
|
On Jan 13, 10:06 am, Tom Roberts wrote:
> On 1/13/13 1/13/13 3:33 AM, Helmut Wabnig wrote:
> > There is one thing to add to resolve a common misconception:
> > Ground based GPS users do not have atomic clocks in their
> > Garmins and GPS cell phones, therefore they need signals
> > from 4 satellites.
>
> > Only if a ground based receiver would use
> > an atomic clock and read the signals from 3 satellites only
> > then it would need a relativistic correction.
> > The GPS satellites clocks are synchronized with each other.
> > Therefore no correction whatever is needed to calculate the
> > position and height on ground. Regardless what clock rate
> > the satellites have, as long as they are synchronous,
> > there will be no geographical error from the calculations.
> > Any relativistic or other drift does not influence position accuracy.
>
> You make the same mistake as several idiots around here: geo-positioning is NOT
> the only requirement on the GPS. The GPS is a REAL SYSTEM, and not some figment
> of your imagination -- like those idiots, you are attempting to discuss a
> fantasy system you imagine you are competent to design yourself. You aren't.
>
> There are additional requirements on the GPS:
>
> [rest of useless SR/GR scripture snipped]
Let?s enjoy the following play between Tom and a GPS satellite.
Hopefully, the self-styled physicists would begin to understand why GR
is not necessary in designing the GPS. <shrug>
Satellite: Tom, every 24 hours, just send me your UTC time, and I
will adjust my calendar time to match the UTC time.
Tom: Don?t bother. You need GR for that.
Satellite: No, not really. Please just do what I have asked you.
Tom: OK, that would be a waste of time. How would you meet the
specification of setting your calendar to within 1 usec of the UTC
time?
Satellite: My clock is 100MHz. This gives me a resolution of 10
nsec. It should be a piece of cake.
Tom: OK, at the time of beep, the UTC time will be
2,000,000,000.000000 sec.
Satellite: Thank you. Please beep me again in exactly 24 hours from
that beep.
[24 hours passed in uncle Tom?s cabin]
Tom: OK, at the time of beep, the UTC time will be
2,000,086,400.000000 sec.
Satellite: Where the devil have you been? You are late, but that is
OK. Now, I have all the information I need to lock my calendar time
to the UTC time accurate to 1 usec. Now, that is an ideal situation.
Realistically, it will take several iterations to achieve that.
Tom: You need GR for that.
Satellite: Your 24 hours ago, when I first received that beep, my
calendar time showed 1,428,376,019.87725503 usec. 24 hours late, my
calendar time showed 1,428,465,254.68891273 sec at the time of beep.
Tom: You still need GR for that.
Satellite: No, I don?t. From the information I have gathered, I know
my 24 hours is (1,428,465,254.68891273 - 1,428,376,019.87725503 =
89,234.81165770) sec to yours (86,400.000000 sec) which means my clock
is ticking (89,234.81165770 / 86,400.000000 = 1.0328103201) times too
fast. I can easily compensate for that through software by
subtracting (89,234.81165770 - 86,400.000000 = 2,834. 81165770) sec
every 89,234.81165770 sec. Also from the last beep, I know I need to
add (2,000,086,400.000000 - 1,428,465,254.68891273 =
571,621,145.31108727) to my own calendar time to match with the UTC
time.
Tom: You are an idiot. You still need GR for that.
Satellite: I have just demonstrated that you do not need GR to match
my calendar time to within 1 usec of the UTC time, and my clock does
not even have to be the same as yours.
Tom: You are still an idiot. You will never learn. There is no need
for me to communicate with you any further.
Satellite: <shrug>
|
|
|
|
