Well, how about this: I have a central facility. In that, I synchronize several clocks. I then slowly move them to satellite facilities in opposite directions. I don't move all the clocks by the same path - some go via triangular routes rather than directly.
If all the clocks agree at the satellite facilities, then I have established that space is isotropic for the slow transport of clocks (or at least, it is isotropic for the paths chosen - a skeptic can always device a "sufficiently smart anisotropy" that would appear to be isotropic for the paths chosen). Per the article, that was one of the assumptions that couldn't be trusted, but if we can experimentally establish it, we can trust it.
We now have synchronized clocks at the two satellite facilities. (We know they're synchronized because we established that space is anisotropic to the slow transport of clocks, and also because at least some of the clocks were transported with identical profiles in opposite directions.) We can now use time of receipt minus time of transmit to establish the one-way speed of light.
> If all the clocks agree at the satellite facilities
The idea is that you can't know this. You're somewhere in the middle receiving messages from all the clocks, and you can't tell if they're synchronized unless you've already defined the speed of light between you and each clock.
Perhaps I said that badly. "If all the clocks agree at satellite facility A, and all the clocks agree at satellite facility B". I'm not comparing clocks at A with clocks at B.
Second, I was thinking of labs perhaps tens of km apart. You can have people at the center, and at satellite facility A, and at satellite facility B.
Here's the problem: you can only observe a remote clock, or any remote object that light from your source reached, at the speed of the light that traveled back from it.
Put another way: the speed of any signal or causality coming back from your measuring device is always a factor with no way around that.
He is just logging timestamps of when the signal arrived. It shouldn't matter if the timestamp gets back to the central location by carrier pigeon. But maybe the catch is that it doesn't matter how slowly he moves the clocks into position, they'll always be skewed by time dilation.
> But maybe the catch is that it doesn't matter how slowly he moves the clocks into position, they'll always be skewed by time dilation.
I dealt with that by moving the clocks with identical velocity profiles, so time dilation should be the same...
Unless time dilation is anisotropic. I dealt with that by sending multiple clocks, with some sent on triangular routes and some direct. In more detail:
C
A B
D
If I send a clock from A to C to B, and a clock from A to D to B, and the two clocks arrive with the same time, then I have evidence that time dilation is anisotropic (for at least those two routes). I don't necessarily expect that they have the same time as a clock sent direct from A to B - they have an additional acceleration, from the change of direction at C or D, and they have more time at velocity, because of traveling the longer distance. I think I said that very badly in my first post.
But the point is, if I can show that time dilation is anisotropic, then the clocks that went direct from A to B, and the clocks that went the same distance in exactly the opposite direction, should have the same time on them.
> If I send a clock from A to C to B, and a clock from A to D to B, and the two clocks arrive with the same time, then I have evidence that time dilation is anisotropic (for at least those two routes).
You mean isotropic, and you don't really. D->B is the same as A->C and C->B is the same as A->D; whatever clever path you come up with, a clock going from A to B will end up having had vertical movements that sum up to 0. If moving up induces some extra time dilation and moving down reduces it, or vice versa, you'll never be able to detect it; ultimately you can only ever make measurements when you and your clocks (and/or signals) have moved in closed loops, however squiggly.
OK, so that diagram was intended to be horizontal, not vertical. Obviously you want to minimize vertical movement as much as possible.
But I see what you mean about the sides (as drawn) being parallel.
And, yes, I meant isotropic, not anisotropic. Embarrassing.
OK, how about this: I have an equilateral triangle, with vertices A, B, and C. I synchronize clocks four clocks at A. I send one clock to B directly, and one to C and then B. I send one clock to C directly, and one to B and then C. I do the same from points B and C. Then, I can look at the difference between clocks that came direct and clocks that came the long way. If all the differences are the same, then I can say that going A-to-B-to-C has the same effect as going A-to-C-to-B or B-to-A-to-C or any other route. Doesn't that show isotropy?
> Then, I can look at the difference between clocks that came direct and clocks that came the long way. If all the differences are the same, then I can say that going A-to-B-to-C has the same effect as going A-to-C-to-B or B-to-A-to-C or any other route. Doesn't that show isotropy?
Again, no, because you can only measure around the full loop. Any clock you can compare has gone just as far east as it has gone west, just as far north as south, and just as far up as down. You can rule out some particular kinds of anisotropy, but there are possible patterns that just wouldn't show up.
How do you measure if the clocks agree or not after you move them? You can try and synchronize all the moved ones at point B, but how do you measure their relative timing to A clocks without relying on the speed of light between A and B.
Synchronize A & B in one location. Move A & B apart in a careful manner. Send light pulse from A and record time-stamp on A's clock when pulse sent. When pulse is received at B, record time stamp on B's clock. Return clocks A & B together (in a careful manner) to confirm they are still in sync. Compare time stamp between A's transmission, and B's reception. Who knows, maybe when you bring them together, clocks A and B aren't in sync, due to some twin-paradox thing. Maybe you can't be careful enough.
> Synchronize A & B in one location. Move A & B apart in a careful manner.
Doesn’t matter how careful you are, SR tells us moving clock will become unsynched. The amount of “unsynching” depends on c (see Lorentz factor) so if c is different in forward vs reverse direction, bringing the clocks back will even it out
I also feel like there is a hidden assumption here, that people were interested in the one-way-speed to see if it is Newtonian additive, like it is "c +/- a tiny little bit from the earth's motion around the sun". It seems like with a sufficiently slow separation of the two clocks, you should be able to see if the you get "0.1c" in one orientation, and "1.9c" in the other. Especially since the Lorentz factor is non-linear [ √(1 - (v²/c²)) ]. Right? ???
> It seems like with a sufficiently slow separation of the two clocks, you should be able to see if the you get "0.1c" in one orientation, and "1.9c" in the other.
No you wouldn’t be able to “see” it. If your clocks are off you dont know that and by how much until you bring it back and compare. That's Special Relativity
If all the clocks agree at the satellite facilities, then I have established that space is isotropic for the slow transport of clocks (or at least, it is isotropic for the paths chosen - a skeptic can always device a "sufficiently smart anisotropy" that would appear to be isotropic for the paths chosen). Per the article, that was one of the assumptions that couldn't be trusted, but if we can experimentally establish it, we can trust it.
We now have synchronized clocks at the two satellite facilities. (We know they're synchronized because we established that space is anisotropic to the slow transport of clocks, and also because at least some of the clocks were transported with identical profiles in opposite directions.) We can now use time of receipt minus time of transmit to establish the one-way speed of light.