Dr. Henri Wilson skrev:
On Thu, 21 Feb 2008 22:37:43 +0100, "Paul B. Andersen"
wrote:

Dr. Henri Wilson wrote:
Paul, let's try a little harder.

Let's say that after launch, an OC is found to emit 100000000000001 ticks for
every 100000000000000 ticks of the GC.

How would a Norwegian go about software synching the OC with the GC?

I eagerly await your answer.
Still don't know after all these years, Henri? :-)

1. The SV-clock is never adjusted while a satellite is in service,
the "clock data" are transmitted with no correction.
2. The "clock offset" tells what the error in the "clock data" is,
and is transmitted together with the "clock data".
3. The correction is done in the receiver, it will find the correct
time reported by the satellite by subtracting these two times.
4. The "clock offset" is updated (uploaded from the ground) typically
once per day.

No, wrong answer.
The correct one is that one tick is dropped for every 10000000000000 that
arrive....which makes the maximum error 1/10000000000000.
If the OC emitted 10000000000025 ticks for every 10000000000000 of the GC and
25 were dropped for avery 10000000000000 of the GC, then the maximum error
would be 25/10000000000000....so it is clear why it is advantageous to built-in
the approximate free fall error.

If there is anything else you still don't know, just ask.

Yes, If you wanted to send a vertical rod into orbit as a standard 1 metre
reference, what vertical length would you make it before launch?

Remember to include GR....
Done prior to launch.
That's why the rate of the orbiting clock is correct to one part in 10^14.
Had you forgotten that the GPS wouldn't work without the GR correction?

The GR prediction happens to be around the right order, purely by coincidence.
The fine tuning of the secondary clock is carried out after launch by altering
its relationship with the primary atomic oscillator by adding or dropping
'ticks' as explained above..

Sure Henri.
Whatever you say. :-)

--
Paul

http://home.c2i.net/pb_andersen/

Dr. Henri Wilson skrev:
Of course the bloody rate is changed after launch.

Each clock is software adjusted so that its rate is as close as possible to the
GC...after that, only very small corrections are required.

Actual GPS clock data measured by the ground stations can be found at:
http://tycho.usno.navy.mil/gps_datafiles.html

Below is a tiny excerpt of the data for the last 30 days.
I have shown the first and the last entry for each SV.
The table shows what the clock error is, and how much
it has changed during 30 days.

PRN Julian day clock error
1 54490.06701 -181263.7
1 54519.98368 -187755.1
2 54490.64201 -169105.0
2 54519.79479 -176782.5
3 54490.30035 -177788.4
3 54519.38646 -191137.3
4 54490.58646 57227.6
4 54519.72813 14049.3
5 54490.07813 -661179.4
5 54519.98368 -699917.9
8 54490.42257 138330.7
8 54519.51701 142174.2
9 54490.01146 -107278.9
9 54519.98368 -111959.0
10 54490.73090 222933.3
10 54519.85035 251627.2
11 54490.45590 -27039.0
11 54519.53924 -26982.6
12 54490.07813 354993.0
12 54519.98368 357044.3
13 54490.31146 -236284.6
12 54519.98368 357044.3
13 54490.31146 -236284.6
13 54519.70590 -241797.6
14 54490.01146 302989.6
14 54519.98368 294474.3
15 54490.01146 72735.4
15 54519.93924 79184.7
16 54490.21146 -132329.8
16 54519.33090 -132703.7
17 54490.50868 -43758.3
17 54519.65035 -42076.6
18 54490.01146 209686.4
18 54519.98368 201917.5
19 54490.33368 -18148.0
19 54519.43924 -21843.8
20 54490.20035 -121917.9
20 54519.59479 -119999.1
21 54490.01146 -73032.8
21 54519.98368 -71052.4
22 54490.01146 -207495.1
22 54519.98368 -208856.2
23 54490.25590 -328993.3
23 54519.33090 -336150.2
24 54490.01146 -65090.9
24 54519.93924 -72906.5
25 54490.36701 -503963.0
25 54519.45035 -516635.8
26 54490.83090 -165569.7
26 54519.89479 -191070.1
27 54490.37813 -163211.5
27 54519.48368 -169772.7
28 54490.47813 14182.0
28 54519.59479 15544.0
29 54490.79757 71673.8
29 54519.87257 56322.2
30 54490.14479 -61209.3
30 54519.71701 -65013.3
31 54490.10035 6616.5
31 54519.25313 10205.2


The table below show what the average rate error is
for each satellite clock during the last 30 days.

PRN Rate error
x10^-12
1 -2.51
2 -3.05
3 -5.31
4 -17.15
5 -14.99
8 1.53
9 -1.81
10 11.40
11 0.02
12 0.79
13 -2.17
14 -3.29
15 2.49
16 -0.15
17 0.67
18 -3.00
19 -1.47
20 0.76
21 0.76
22 -0.53
23 -2.85
24 -3.02
25 -5.04
26 -10.15
27 -2.61
28 0.54
29 -6.11
30 -1.49
31 1.42

I leave it to the reader to draw his conclusions.


--
Paul

http://home.c2i.net/pb_andersen/

On Sun, 24 Feb 2008 20:56:33 +0100, "Paul B. Andersen"
wrote:

Dr. Henri Wilson skrev:
Of course the bloody rate is changed after launch.

Each clock is software adjusted so that its rate is as close as possible to the
GC...after that, only very small corrections are required.

Actual GPS clock data measured by the ground stations can be found at:
http://tycho.usno.navy.mil/gps_datafiles.html

Below is a tiny excerpt of the data for the last 30 days.
I have shown the first and the last entry for each SV.
The table shows what the clock error is, and how much
it has changed during 30 days.

PRN Julian day clock error
1 54490.06701 -181263.7
1 54519.98368 -187755.1
2 54490.64201 -169105.0
2 54519.79479 -176782.5
3 54490.30035 -177788.4
3 54519.38646 -191137.3
4 54490.58646 57227.6
4 54519.72813 14049.3
5 54490.07813 -661179.4
5 54519.98368 -699917.9
8 54490.42257 138330.7
8 54519.51701 142174.2
9 54490.01146 -107278.9
9 54519.98368 -111959.0
10 54490.73090 222933.3
10 54519.85035 251627.2
11 54490.45590 -27039.0
11 54519.53924 -26982.6
12 54490.07813 354993.0
12 54519.98368 357044.3
13 54490.31146 -236284.6
12 54519.98368 357044.3
13 54490.31146 -236284.6
13 54519.70590 -241797.6
14 54490.01146 302989.6
14 54519.98368 294474.3
15 54490.01146 72735.4
15 54519.93924 79184.7
16 54490.21146 -132329.8
16 54519.33090 -132703.7
17 54490.50868 -43758.3
17 54519.65035 -42076.6
18 54490.01146 209686.4
18 54519.98368 201917.5
19 54490.33368 -18148.0
19 54519.43924 -21843.8
20 54490.20035 -121917.9
20 54519.59479 -119999.1
21 54490.01146 -73032.8
21 54519.98368 -71052.4
22 54490.01146 -207495.1
22 54519.98368 -208856.2
23 54490.25590 -328993.3
23 54519.33090 -336150.2
24 54490.01146 -65090.9
24 54519.93924 -72906.5
25 54490.36701 -503963.0
25 54519.45035 -516635.8
26 54490.83090 -165569.7
26 54519.89479 -191070.1
27 54490.37813 -163211.5
27 54519.48368 -169772.7
28 54490.47813 14182.0
28 54519.59479 15544.0
29 54490.79757 71673.8
29 54519.87257 56322.2
30 54490.14479 -61209.3
30 54519.71701 -65013.3
31 54490.10035 6616.5
31 54519.25313 10205.2


The table below show what the average rate error is
for each satellite clock during the last 30 days.

PRN Rate error
x10^-12
1 -2.51
2 -3.05
3 -5.31
4 -17.15
5 -14.99
8 1.53
9 -1.81
10 11.40
11 0.02
12 0.79
13 -2.17
14 -3.29
15 2.49
16 -0.15
17 0.67
18 -3.00
19 -1.47
20 0.76
21 0.76
22 -0.53
23 -2.85
24 -3.02
25 -5.04
26 -10.15
27 -2.61
28 0.54
29 -6.11
30 -1.49
31 1.42

I leave it to the reader to draw his conclusions.

These are merely recordings of typical clock drift.



Henri Wilson. ASTC,BSc,DSc(T)
www.users.bigpond.com/hewn/index.htm

Einstein's Relativity is easy to understand if one has the IQ of a parrot and a gullibility index 0.95.

On Sun, 24 Feb 2008 17:49:28 +0100, "Paul B. Andersen"
wrote:

Dr. Henri Wilson skrev:
On Thu, 21 Feb 2008 22:37:43 +0100, "Paul B. Andersen"
wrote:

Dr. Henri Wilson wrote:
Paul, let's try a little harder.

Let's say that after launch, an OC is found to emit 100000000000001 ticks for
every 100000000000000 ticks of the GC.

How would a Norwegian go about software synching the OC with the GC?

I eagerly await your answer.
Still don't know after all these years, Henri? :-)

1. The SV-clock is never adjusted while a satellite is in service,
the "clock data" are transmitted with no correction.
2. The "clock offset" tells what the error in the "clock data" is,
and is transmitted together with the "clock data".
3. The correction is done in the receiver, it will find the correct
time reported by the satellite by subtracting these two times.
4. The "clock offset" is updated (uploaded from the ground) typically
once per day.

No, wrong answer.
The correct one is that one tick is dropped for every 10000000000000 that
arrive....which makes the maximum error 1/10000000000000.
If the OC emitted 10000000000025 ticks for every 10000000000000 of the GC and
25 were dropped for avery 10000000000000 of the GC, then the maximum error
would be 25/10000000000000....so it is clear why it is advantageous to built-in
the approximate free fall error.

If there is anything else you still don't know, just ask.

Yes, If you wanted to send a vertical rod into orbit as a standard 1 metre
reference, what vertical length would you make it before launch?

Remember to include GR....
Done prior to launch.
That's why the rate of the orbiting clock is correct to one part in 10^14.
Had you forgotten that the GPS wouldn't work without the GR correction?

The GR prediction happens to be around the right order, purely by coincidence.
The fine tuning of the secondary clock is carried out after launch by altering
its relationship with the primary atomic oscillator by adding or dropping
'ticks' as explained above..

Sure Henri.
Whatever you say. :-)

Actually, it is quite possible that the increase in wavelength (but not
frequency) due to light's acceleration as it falls, causes a phase difference
error of the same magnitude.



Henri Wilson. ASTC,BSc,DSc(T)
www.users.bigpond.com/hewn/index.htm

Einstein's Relativity is easy to understand if one has the IQ of a parrot and a gullibility index 0.95.

On Feb 23, 1:51 pm, HW@....(Dr. Henri Wilson) wrote:
On Fri, 22 Feb 2008 13:16:54 -0800 (PST), Randy Poe
wrote:



On Feb 22, 4:08 pm, HW@....(Dr. Henri Wilson) wrote:
On Thu, 21 Feb 2008 22:37:43 +0100, "Paul B. Andersen"

wrote:
Dr. Henri Wilson wrote:
Paul, let's try a little harder.

Let's say that after launch, an OC is found to emit 100000000000001 ticks for
every 100000000000000 ticks of the GC.

How would a Norwegian go about software synching the OC with the GC?

I eagerly await your answer.

Still don't know after all these years, Henri? :-)

1. The SV-clock is never adjusted while a satellite is in service,
the "clock data" are transmitted with no correction.
2. The "clock offset" tells what the error in the "clock data" is,
and is transmitted together with the "clock data".
3. The correction is done in the receiver, it will find the correct
time reported by the satellite by subtracting these two times.
4. The "clock offset" is updated (uploaded from the ground) typically
once per day.

No, wrong answer.
The correct one is that one tick is dropped for every 10000000000000 that
arrive....which makes the maximum error 1/10000000000000.
If the OC emitted 10000000000025 ticks for every 10000000000000 of the GC and
25 were dropped for avery 10000000000000 of the GC, then the maximum error
would be 25/10000000000000....so it is clear why it is advantageous to built-in
the approximate free fall error.

If there is anything else you still don't know, just ask.

Yes, If you wanted to send a vertical rod into orbit as a standard 1 metre
reference, what vertical length would you make it before launch?

Remember to include GR....

Done prior to launch.
That's why the rate of the orbiting clock is correct to one part in 10^14.
Had you forgotten that the GPS wouldn't work without the GR correction?

The GR prediction happens to be around the right order, purely by coincidence.

"About the right order". What was it and how far was
it off, Henri?

If I predicted the Dow Jones would be 11402.5 tomorrow
and it was 11402.5, would you say I got it "around the
right order"?

The fine tuning of the secondary clock is carried out after launch by altering
its relationship with the primary atomic oscillator by adding or dropping
'ticks' as explained above..

There is no change in rate after launch, and you know
it. Changing the offsets every 12 hours will do nothing
to affect the drift between satellite clock and ground
clock between updates. The only way to keep that drift
in spec is to get the rate correct.

Since the rate is never changed after launch, you have
to make the right adjustments on the ground to get it
right.

Of course the bloody rate is changed after launch.

Each clock is software adjusted so that its rate is as close as possible to the
GC...after that, only very small corrections are required.

No such rate change is part of the spec or listed in
any sort of operational data available. So how do you
come to know that this rate change "of course" occurs?
Do you have access to non-public sources of information?

Pray quote us some data on the tick rate before and
after one of these rate changes.

- Randy

"Randy Poe" wrote in message
...
| On Feb 23, 1:51 pm, HW@....(Dr. Henri Wilson) wrote:
| On Fri, 22 Feb 2008 13:16:54 -0800 (PST), Randy Poe

| wrote:
|
|
|
| On Feb 22, 4:08 pm, HW@....(Dr. Henri Wilson) wrote:
| On Thu, 21 Feb 2008 22:37:43 +0100, "Paul B. Andersen"
|
| wrote:
| Dr. Henri Wilson wrote:
| Paul, let's try a little harder.
|
| Let's say that after launch, an OC is found to emit
100000000000001 ticks for
| every 100000000000000 ticks of the GC.
|
| How would a Norwegian go about software synching the OC with the
GC?
|
| I eagerly await your answer.
|
| Still don't know after all these years, Henri? :-)
|
| 1. The SV-clock is never adjusted while a satellite is in service,
| the "clock data" are transmitted with no correction.
| 2. The "clock offset" tells what the error in the "clock data" is,
| and is transmitted together with the "clock data".
| 3. The correction is done in the receiver, it will find the correct
| time reported by the satellite by subtracting these two times.
| 4. The "clock offset" is updated (uploaded from the ground)
typically
| once per day.
|
| No, wrong answer.
| The correct one is that one tick is dropped for every 10000000000000
that
| arrive....which makes the maximum error 1/10000000000000.
| If the OC emitted 10000000000025 ticks for every 10000000000000 of
the GC and
| 25 were dropped for avery 10000000000000 of the GC, then the maximum
error
| would be 25/10000000000000....so it is clear why it is advantageous
to built-in
| the approximate free fall error.
|
| If there is anything else you still don't know, just ask.
|
| Yes, If you wanted to send a vertical rod into orbit as a standard 1
metre
| reference, what vertical length would you make it before launch?
|
| Remember to include GR....
|
| Done prior to launch.
| That's why the rate of the orbiting clock is correct to one part in
10^14.
| Had you forgotten that the GPS wouldn't work without the GR
correction?
|
| The GR prediction happens to be around the right order, purely by
coincidence.
|
| "About the right order". What was it and how far was
| it off, Henri?
|
| If I predicted the Dow Jones would be 11402.5 tomorrow
| and it was 11402.5, would you say I got it "around the
| right order"?
|
| The fine tuning of the secondary clock is carried out after launch by
altering
| its relationship with the primary atomic oscillator by adding or
dropping
| 'ticks' as explained above..
|
| There is no change in rate after launch, and you know
| it. Changing the offsets every 12 hours will do nothing
| to affect the drift between satellite clock and ground
| clock between updates. The only way to keep that drift
| in spec is to get the rate correct.
|
| Since the rate is never changed after launch, you have
| to make the right adjustments on the ground to get it
| right.
|
| Of course the bloody rate is changed after launch.
|
| Each clock is software adjusted so that its rate is as close as possible
to the
| GC...after that, only very small corrections are required.
|
| No such rate change is part of the spec or listed in
| any sort of operational data available. So how do you
| come to know that this rate change "of course" occurs?
| Do you have access to non-public sources of information?
|
| Pray quote us some data on the tick rate before and
| after one of these rate changes.
|
Wilson was foolish enough to heed a crank (=relativist).
Like you, he doesn't think.
Here is some data on tick rate that you requested.
http://physics.nist.gov/cuu/Units/second.html

On Feb 24, 3:25*pm, HW@....(Dr. Henri Wilson) wrote:
On Sun, 24 Feb 2008 17:49:28 +0100, "Paul B. Andersen"





wrote:
Dr. Henri Wilson skrev:
On Thu, 21 Feb 2008 22:37:43 +0100, "Paul B. Andersen"
wrote:

Dr. Henri Wilson wrote:
Paul, let's try a little harder.

Let's say that after launch, an OC is found to emit 100000000000001 ticks for
every 100000000000000 ticks of the GC.

How would a Norwegian go about software synching the OC with the GC?

I eagerly await your answer.
Still don't know after all these years, Henri? :-)

1. The SV-clock is never adjusted while a satellite is in service,
* *the "clock data" are transmitted with no correction.
2. The "clock offset" tells what the error in the "clock data" is,
* *and is transmitted together with the "clock data".
3. The correction is done in the receiver, it will find the correct
* *time reported by the satellite by subtracting these two times.
4. The "clock offset" is updated (uploaded from the ground) typically
* *once per day.

No, wrong answer.
The correct one is that one tick is dropped for every 10000000000000 that
arrive....which makes the maximum error 1/10000000000000.
If the OC emitted 10000000000025 ticks for every 10000000000000 of the GC and
25 were dropped for avery 10000000000000 of the GC, then the maximum error
would be 25/10000000000000....so it is clear why it is advantageous to built-in
the approximate free fall error.

If there is anything else you still don't know, just ask.

Yes, If you wanted to send a vertical rod into orbit as a standard 1 metre
reference, what vertical length would you make it before launch?

Remember to include GR....
Done prior to launch.
That's why the rate of the orbiting clock is correct to one part in 10^14.
Had you forgotten that the GPS wouldn't work without the GR correction?

The GR prediction happens to be around the right order, purely by coincidence.
The fine tuning of the secondary clock is carried out after launch by altering
its relationship with the primary atomic oscillator by adding or dropping
'ticks' as explained above..

Sure Henri.
Whatever you say. :-)

Actually, it is quite possible that the increase in wavelength (but not
frequency) due to light's acceleration as it falls, causes a phase difference
error of the same magnitude.

Actually, it's quite possible that stratospheric ice monkeys intercept
the signals from the satellites and delay them by a small increment
before reradiating them downward. This is a *much* more plausible
explanation of the measured delays than the GR explanation, even if
the latter gets the number exactly right. I'm sure you can come up
with two dozen other candidates in a couple days' time, if you apply
yourself to the task.




Henri Wilson. ASTC,BSc,DSc(T)www.users.bigpond.com/hewn/index.htm

Einstein's *Relativity is easy to understand if one has the IQ of a parrot and a gullibility index 0.95.- Hide quoted text -

- Show quoted text -

Dr. Henri Wilson wrote:
On Sun, 24 Feb 2008 20:56:33 +0100, "Paul B. Andersen"
wrote:

Dr. Henri Wilson skrev:
Of course the bloody rate is changed after launch.

Each clock is software adjusted so that its rate is as close as possible to the
GC...after that, only very small corrections are required.
Actual GPS clock data measured by the ground stations can be found at:
http://tycho.usno.navy.mil/gps_datafiles.html

Below is a tiny excerpt of the data for the last 30 days.
I have shown the first and the last entry for each SV.
The table shows what the clock error is, and how much
it has changed during 30 days.

PRN Julian day clock error
1 54490.06701 -181263.7
1 54519.98368 -187755.1
2 54490.64201 -169105.0
2 54519.79479 -176782.5
3 54490.30035 -177788.4
3 54519.38646 -191137.3
4 54490.58646 57227.6
4 54519.72813 14049.3
5 54490.07813 -661179.4
5 54519.98368 -699917.9
8 54490.42257 138330.7
8 54519.51701 142174.2
9 54490.01146 -107278.9
9 54519.98368 -111959.0
10 54490.73090 222933.3
10 54519.85035 251627.2
11 54490.45590 -27039.0
11 54519.53924 -26982.6
12 54490.07813 354993.0
12 54519.98368 357044.3
13 54490.31146 -236284.6
12 54519.98368 357044.3
13 54490.31146 -236284.6
13 54519.70590 -241797.6
14 54490.01146 302989.6
14 54519.98368 294474.3
15 54490.01146 72735.4
15 54519.93924 79184.7
16 54490.21146 -132329.8
16 54519.33090 -132703.7
17 54490.50868 -43758.3
17 54519.65035 -42076.6
18 54490.01146 209686.4
18 54519.98368 201917.5
19 54490.33368 -18148.0
19 54519.43924 -21843.8
20 54490.20035 -121917.9
20 54519.59479 -119999.1
21 54490.01146 -73032.8
21 54519.98368 -71052.4
22 54490.01146 -207495.1
22 54519.98368 -208856.2
23 54490.25590 -328993.3
23 54519.33090 -336150.2
24 54490.01146 -65090.9
24 54519.93924 -72906.5
25 54490.36701 -503963.0
25 54519.45035 -516635.8
26 54490.83090 -165569.7
26 54519.89479 -191070.1
27 54490.37813 -163211.5
27 54519.48368 -169772.7
28 54490.47813 14182.0
28 54519.59479 15544.0
29 54490.79757 71673.8
29 54519.87257 56322.2
30 54490.14479 -61209.3
30 54519.71701 -65013.3
31 54490.10035 6616.5
31 54519.25313 10205.2


The table below show what the average rate error is
for each satellite clock during the last 30 days.

PRN Rate error
x10^-12
1 -2.51
2 -3.05
3 -5.31
4 -17.15
5 -14.99
8 1.53
9 -1.81
10 11.40
11 0.02
12 0.79
13 -2.17
14 -3.29
15 2.49
16 -0.15
17 0.67
18 -3.00
19 -1.47
20 0.76
21 0.76
22 -0.53
23 -2.85
24 -3.02
25 -5.04
26 -10.15
27 -2.61
28 0.54
29 -6.11
30 -1.49
31 1.42

I leave it to the reader to draw his conclusions.

These are merely recordings of typical clock drift.

Could you elaborate on that, please?

Let's take one concrete example.

The clock error of the SV with PRN 12
was on Julian day 54490.07813 354993.0 ns.
On Julian day 54519.98368 the error was 357044.3 ns.
So during 29.9 days the clock has drifted 2051.3 ns
more ahead of GPS-time. So the average rate error is
68.6 ns per day or 0.79*10^-12 too fast.

In what way is this 'merely recordings of typical clock drift'
as opposed to 'recordings of actual clock drifts'?

BTW, can you explain why the clocks drift in different
directions and by different amounts?

Don't forget that:
"Of course the bloody rate is changed after launch."
So why are the rates wrong?

--
Paul

http://home.c2i.net/pb_andersen/

On Feb 25, 1:50 am, "Paul B. Andersen"
wrote:

[...]

This'll be fun to watch. I did the same thing with Koobee Wublee - I
took actual spacecrat data and proved he was wrong by many orders of
magnitude, and it accomplished nothing. I wonder in what fun way will
Henri deny what is in front of his face.

On Feb 25, 7:34*am, Eric Gisse wrote:
On Feb 25, 1:50 am, "Paul B. Andersen"

wrote:

[...]

This'll be fun to watch. I did the same thing with Koobee Wublee - I
took actual spacecrat data and proved he was wrong by many orders of
magnitude, and it accomplished nothing. I wonder in what fun way will
Henri deny what is in front of his face.

I don't know why it will be fun. Henri is now like Androcles, where he
would rather say stuff he KNOWS is nonsense rather than back down.
Henri will surely have by morning six alternate theories for physical
explanations for why GPS satellites show a delay that exactly matches
GR. These theories may involve any of the following:
1. Undiscovered terrestrial fields
2. Refractive stratospheric ice monkeys
3. Albanian counter-espionage
4. Wilsonian Phase Delay Bubbles, for which he wants credit
5. Deliberately obstinate photons
6. A massive cover-up on the part of the GPS Commission, which
publishes data BY the commission FOR the commission.

He really doesn't care what he says anymore. It doesn't have to make
sense. All it has to do is pass the time.

PD