Relativity - Synchronization and slow transport

[Pete]

Err no, it is 5ns in 60 ns because the clock desynchronization is off by 5ns.

It takes 10,000s to move 3000km at 300m/s, so a synchronization error of 5ns in 10000s.

CERN used clock transport to check a transit delay over a distance of 8.3km, and got a result of 40996+/-1 ns.
So the low velocity approximation would work fine for them.

So what's the problem?
Why are you still insisting on perfect accuracy?
Are you going to rework the analysis to include quantum effects and curved spacetime, or are you happy with the macroscopic flat spacetime approximation?


And there's an issue you haven't yet tackled in post 52.

 

[Pete]

Keep the OP in mind, Tach. What are you actually arguing about?

If two synchronized clocks are slowly separated, they will not stay synchronized unless they were initially at rest.

Your challenge seems to be on two fronts.

You challenge the implication that clocks initially at rest will always stay synchronized under slow separation, because taking the low velocity limit is unphysical.

I agree - it is true that they won't maintain perfect synchronization.
However, I'm sure you'll agree that low velocity approximations are useful in practice.


More seriously,
You also challenge the implication that moving clocks can not stay synchronized under slow separation, by showing that the right choice of separation speed will maintain synchronization.

It is true that the right choice of separation speed can maintain synchronization.
But the claim still holds - the right choice of separation speed is not going to be the slow separation specified in the claim.

 

[Tach]

It takes 10,000s to move 3000km at 300m/s, so a synchronization error of 5ns in 10000s.

Simple, because by insisting in using your approach you insert an error of 5 ns in the measurement, which is 60 ns.

Why are you still insisting on perfect accuracy?

Because you have been shown an exact method, yet you insist in using a hack. Because you have been shown a general method, yet you insist on using a hack.

More seriously,
You also challenge the implication that moving clocks can not stay synchronized under slow separation, by showing that the right choice of separation speed will maintain synchronization

Math don't lie, you have to deal with the facts. $$v-dv+du=0$$ says that the clocks stay synchronized.

It is true that the right choice of separation speed can maintain synchronization.

Good, so you accept the math.

But the claim still holds - the right choice of separation speed is not going to be the slow separation specified in the claim.

Why are you so fixated on the impractical when I showed you how it's done in practice?

 

[Pete]

Tach, if you're going to ignore questions you don't like, why bother posting at all?

Simple, because by insisting in using your approach you insert an error of 5 ns in the measurement, which is 60 ns.

Where did this 60ns come from?

Because you have been shown an exact method, yet you insist in using a hack. Because you have been shown a general method, yet you insist on using a hack.

It's a low-velocity approximation, which is what this thread was about right from the beginning. That's why it says slow transport.

Yes, I know it's an approximation.

 

[Pete]

Good, so you accept the math.

Always have.

Why are you so fixated on the impractical when I showed you how it's done in practice?

Why are you so fixated on not addressing the claim you challenged?

This part of your challenge isn't even about taking the limit.

 

[Tach]

From the link:

Agreed.

So what happens if we consider the actual claim you challenged?
That is, can the clocks still be synchronized if we keep the notion of "slow" in the clock transport?
The answer is "No".

I missed this one. How on earth did you arrive at this conclusion? The writeup I gave you is general, it works for any speed. You only need to apply to the "destination" clock B, the correction derived in the file.

If two synchronized clocks are slowly separated, they will not stay synchronized unless they were initially at rest.

There is no "slowly" in practice. Therefore there is no restriction as in "unless they were initially at rest".

 

[Pete]

I missed this one. How on earth did you arrive at this conclusion? The writeup I gave you is general, it works for any speed. You only need to apply to the "destination" clock B, the correction derived in the file.

Yes, It does indeed work for any speed.

So, what about the claim you're challenging?
Can you keep the clocks synchronized if they are separated at a speed that is low compared to v?

Easy question. No limit-taking required.

There is no "slowly" in practice. Therefore there is no restriction as in "unless they were initially at rest".

:bugeye:
So the only defence you have left is that there's no such thing as "slowly".

I think we're done.

 

[Tach]

Yes, It does indeed work for any speed.

Good, you are starting to accept the general method.

So, what about the claim you're challenging?
Can you keep the clocks synchronized if they are separated at a speed that is low compared to v?

There is no reason to separate them at "low speeds compared to v". The writeup gives you the details of the historical fixation with "slow" speeds, did you read that chapter? Why are you so fixated on "low speeds"? What good does it do to the approach (other than introducing potentially serious imprecision)?

The expression $$\frac{L}{c^2} \frac{2v-\Delta v +\Delta u}{\sqrt{1 - ((v-\Delta v)/c)^2} +\sqrt{1 - ((v+\Delta u)/c)^2}$$ gives the exact desynchronization between clocks for transport at any speed, as viewed from an arbitrary frame. Why do you insist on nulling $$\Delta u$$ and $$\Delta v$$ when:

-they cannot be null
-nulling them adds imprecision
-you have already been given the exact answer?

 

[Pete]

Good, you are starting to accept the general method.

Always have.

There is no reason to separate them at "low speeds compared to v".

That's the claim you challenged, Tach.

We never disagreed on the general case - only on the slow separation case.

 

[Pete]

We done now?
There was never any disagreement over the general case, and I think you're now reduced to dodging the question.

Let's see...

Can you keep the clocks synchronized if they are separated at a speed that is low compared to v?

(Hint - the answer is either "yes" or "no", and "yes" is wrong.)

 

[Tach]

Let's see...

Can you keep the clocks synchronized if they are separated at a speed that is low compared to v?

YES. The "correction" method is general it works for any speed INCLUDING "slow" , NON-NULL speeds. You only need to apply the exact correction as specified in the writeup.

You are mixing up the correction, which works for all ranges of speeds (including "slow"), with the condition $$2v-dv+du=0$$ that can be used INSTEAD of the correction, if you freed yourself from the fixation that $$du$$ and $$dv$$ need to be "small". They are TWO different approaches to the problem, the first one always works, the second one requires freeing oneself from past fixations. So, you have TWO methods to choose from. Both refute your statement that got the debate started.

(Hint - the answer is either "yes" or "no", and "yes" is wrong.)

Actually, the answer is "yes" and it is the correct answer.See above.

 

[Pete]

Can you keep the clocks synchronized if they are separated at a speed that is low compared to v?

YES. The "correction" method is general it works for any speed INCLUDING "slow" , NON-NULL speeds.

Tach, when you're in a hole, stop digging.

If v = 0.8c, at what speeds (low compared to v) could you separate them to maintain synchronization?

du=?
dv=?

 

[Pete]

Tach, the "correction method" is pretty funny.
Of course you can keep the clocks synchronized if you artificially correct for the desynchronization!

The point we're discussing is whether there is any desynchronization to correct!

 

[billvon]

This is false. At launch, their clock frequency is SET SLOWER than the clocks on the ground in order to precompensate the GR effects.

You can't "set the frequency of a cesium clock slower." You can't turn a screw and change the emission spectra of cesium. Cesium clocks always run at exactly the same frequency, which is 9192631770 Hertz. They are an example of an "accurate clock," a term often used in GR and SR examples. Divide that frequency by 9192631770 and you get a one second reference, a useful period if you are measuring something in seconds.

This is a problem, of course, since for GPS you need a time reference accurate across different frames. This is accomplished by applying an offset. For example, to adjust for the SR/GR effects, you can divide the clock by 9192631774 instead and the resulting period will be just _over_ a second. Observed from a frame where time is running slower, it will appear to be closer to a 1 second tick, which is helpful for applications like GPS.

But again, this is not changing the clock frequency. You cannot do that. This is applying an offset by changing the divider ratio so that that same frequency gives you a different time base.

 

[OnlyMe]

You can't "set the frequency of a cesium clock slower." You can't turn a screw and change the emission spectra of cesium. Cesium clocks always run at exactly the same frequency, which is 9192631770 Hertz. They are an example of an "accurate clock," a term often used in GR and SR examples. Divide that frequency by 9192631770 and you get a one second reference, a useful period if you are measuring something in seconds.

This is a problem, of course, since for GPS you need a time reference accurate across different frames. This is accomplished by applying an offset. For example, to adjust for the SR/GR effects, you can divide the clock by 9192631774 instead and the resulting period will be just _over_ a second. Observed from a frame where time is running slower, it will appear to be closer to a 1 second tick, which is helpful for applications like GPS.

But again, this is not changing the clock frequency. You cannot do that. This is applying an offset by changing the divider ratio so that that same frequency gives you a different time base.

The frequency of a cesium clock is dependent on many factors including temperature, velocity in space and where in a gravitational field it is, among a few others. It has been my understanding that they are tuned with a tunable laser to maintain a constant frequency, but there may be other methods used to tune or synchronize them.

I believe this site mentions a harmonic synchronizer on one of the first GPS satellites, http://www.phys.lsu.edu/mog/mog9/node9.html.

The point is that atomic clocks do require tuning, even here on earth.

 

[Pete]

You can't "set the frequency of a cesium clock slower." You can't turn a screw and change the emission spectra of cesium. Cesium clocks always run at exactly the same frequency, which is 9192631770 Hertz. They are an example of an "accurate clock," a term often used in GR and SR examples. Divide that frequency by 9192631770 and you get a one second reference, a useful period if you are measuring something in seconds.

This is a problem, of course, since for GPS you need a time reference accurate across different frames. This is accomplished by applying an offset. For example, to adjust for the SR/GR effects, you can divide the clock by 9192631774 instead and the resulting period will be just _over_ a second. Observed from a frame where time is running slower, it will appear to be closer to a 1 second tick, which is helpful for applications like GPS.

But again, this is not changing the clock frequency. You cannot do that. This is applying an offset by changing the divider ratio so that that same frequency gives you a different time base.

Splitting hairs, I think.
The time signals transmitted from GPS satellites are correctly synchronized in the ECI frame. The clock as a whole (oscillator, counter, transmitter) is in fact precompensated for GR, as Tach said.

 

[Tach]

Tach, the "correction method" is pretty funny.

It isn't "funny" at all, it is pretty straightforward. As the writeup shows, at the end of transporting clock C from A to B there is a desynchronization in the amount of $$\frac{L}{\Delta u}(1-\sqrt{1 - (\Delta u)/c)^2})$$ between clock C and clock A, so, the time of clock C cannot be transferred to clock B because clock A shows the amount $$\frac{L}{\Delta u}$$ . The solution is to simply add the correction $$\frac{L}{\Delta u}(1-\sqrt{1 - (\Delta u)/c)^2})$$ to the time shown by C and to transfer the resulting amount to clock B.

Of course you can keep the clocks synchronized if you artificially correct for the desynchronization!

This is the whole point of the discussion, to show that your claim is false.

The point we're discussing is whether there is any desynchronization to correct!

No, the point is whether the desynchronization is present due to the claim that "if two synchronized clocks are slowly separated, they will not stay synchronized unless they were initially at rest." You are basing your claim on the incorrect amount of desynchronization, $$\frac{\gamma L v}{c^2}$$, when, in reality, the amount of desynchronization is given by $$\frac{L}{c^2} \frac{2v-\Delta v +\Delta u}{\sqrt{1 - ((v-\Delta v)/c)^2} +\sqrt{1 - ((v+\Delta u)/c)^2}$$. The separation speeds, by virtue of being non-null, make the condition in your claim (i.e.$$v=0$$) false.

 

[Tach]

Tach, when you're in a hole, stop digging.

If v = 0.8c, at what speeds (low compared to v) could you separate them to maintain synchronization?

du=?
dv=?

Like I said, you fail to understand that I described for you TWO DIFFERENT methods of resynchronization (read the post above yours). The first method DOES NOT require high separation speeds, can be executed at ANY separation speed.

Like I said, you also need to renounce your fixation with "slow" speeds. Out of curiosity, after I have shown you repeatedly that slow speeds are not germaine to clock synchronization via transport, that "slow" speeds are actually useless, why do you persist in asking me to jump through hoops to solve your synchronization at slow speeds? Is this because it is so difficult for you to admit that your claim is wrong?

 

[RJBeery]

Tach, is it really that interesting to you that we can adjust clocks to remain in synch with other, arbitrary frames? Do you think that this is profound knowledge or something? More importantly, do you think that Pete and others didn't know this?

The point of slow transport is that a synched, co-located and inertial clock can be moved away WITHOUT requiring any corrective adjustments. This also should not be that surprising because (as Pete mentioned) it's Newtonian mechanics as the transported clock is moved with relative v << c.

 

[Tach]

Tach, is it really that interesting to you that we can adjust clocks to remain in synch with other, arbitrary frames?

Yes, it is quite useful, it needs to be done in many fields of physics. Is this news to you?

Do you think that this is profound knowledge or something?

It appears to be since some people are under the severe misconception that the method only works under certain conditions. It might be news to you that the method works for very high transport speeds and that it is insensitive to huge accelerations, of the order of $$10^{16}g$$

More importantly, do you think that Pete and others didn't know this?

From the thread it became clear that many (including you) did not know a lot of things about how the synchronization is done, so, from this point, the thread is quite valuable.

The point of slow transport is that a synched, co-located and inertial clock can be moved away WITHOUT requiring any corrective adjustments.

Actually, mainstream physics shows exactly that :

-there is no need for "slow" transport, any speed would do

- a clock "co-located" with what?

-adjustments for what?

-clock synched to what?

-are you claiming that separating two clocks at slow speed would result in no loss of sychronization?

Because, if you do, this thread shows exactly the opposite.

This also should not be that surprising because (as Pete mentioned) it's Newtonian mechanics as the transported clock is moved with relative v << c.

Actually, if you read the thread, the fact that one has a fixation on v<<c doesn't help, the clocks still get desynchronized.