So there's quite a few posts on here about the now infamous YT video about how the speed of light can only be measured as a round trip. I think I understand the issues with the proposed experiments I've read on here, but I don't see the flaws in an experiment I'd conduct to confirm the speed of light is the same in both directions.
The most likely explanation for my being under the impression that my experiment would work is a lack of knowledge/understanding. I'm all for learning, so I thought I'd post it here, and see what I'm not getting.
So a lot of proposed experiments are about trying to measure the speed of light itself. I think that's what us software engineers call an X-Y problem (solving problem Y, which is actually caused by a wrong approach for the earlier problem X). We cannot possibly rely on 2 independent clocks, because of the synchronisation issue, so we only use 1. We're not actually trying to measure the speed of light, but rather find out if its speed is constant in both directions of travel, so we're looking for a predictable interval. A pattern. That's what I believe this setup would do.
For simplicity, we'll say that geostationary orbit is 30,000 km, and light travels at a nice, round 300,000km/s. I'm also omitting things we're already accounting for in actual satellites we have in orbit like time dilation.
If we were to put a satellite in geostationary orbit, 30,000km above our clock. The satellite itself is incredibly simple: it receives ticks from our clock. If our hypothesis is correct, any communication at the speed of light ($c$ henceforth) should take 0.1s to travel from sender to received. The problem with $c$ being that we know the round trip will take 0.2s in total, we need a way to verify that each leg of the journey takes an even 0.1s.
Our clock continuously sends ticks, at set intervals. Let's say we do so every 1/100th of a second. The ticks we send are integer values. Simple increments (1, 2, 3, ...). At some point, the satellite will send back a message of its own: simply the last tick it received.
From that point, once the satellite has sent its message, it will simply count how many more ticks it receives, by adding the tick numbers to a counter. Just to be clear, say the satellite sent its message at tick 100, the counter value will be 101 (0 + next tick), 203 (0 + 101 + 102), 306 (0+ 101 + 102 + 103), and so on.
Once the clock receives this message from the satellite, it sends the next tick with an additional "acknowledgement" payload. From this point on, the clock will also keep a running total of ticks it sends until it receives the next message from the satellite in the same way (aggregating tick numbers).
When the satellite receives this acknowledgement message, it knows on which tick the clock received the initial message, has the total tally since it sent the original message, and we have enough information to work things out. We sent our message at tick 100, and we received confirmation that the clock received that message at tick 110, ergo, our message took 10 ticks, or 0.1s to be received. We do not know what tick the clock is on currently, however, so we send back our findings (the tally, confirming no ticks were dropped), the start/end time, and the satellite resets. We can either have the satellite re-initiate the experiment at random times, or on command. That's all quite trivial to implement. What I'd do in addition is that the satellite adds a prediction: based on the knowledge that the message takes 0.1s to reach the clock, it can predict what tick the clock will be on once it receives this termination message, as it should be able to predict the total round trip time, as well as the clock tally value.
Once the clock receives the second message from the satellite, we check all the predictions and values. The satellite should send us an expected sum value of all ticks (the ticks started on the satellite side at 101), and the ticks on the side of the clock (starting at 111 counting to 120). The sum value the satellite predicts should be correct, and total 2210. The satellite should've accurately predicted the receiving of the message on tick 120, etc...
We can repeat this exchange any number of times, and have it initated from both sides. The way I've described it here, mainly focuses on time taken from the perspective of the satellite. I've mentioned that we can implement the same mechanism, but have the clock initiate the process, but what I'm really curious about is this: What did I miss? We have a single source of truth in terms of time passing, and we can work out how long each leg of the journey took (as far as I can tell). Do keep in mind that I'm writing this just as I'm having my morning cup of tea (shower thoughts, I know...). I like simplicity, and in essence, this setup is incredibly simple, so simple that I can't imagine that nobody has thought to do this before, without there being a good reason for them not to. I'd just really like to know that good reason.
c
is in fact constant in both directions. The question I have is what reasons could there be for this method not working? So far, I've not seen any... – Elias Van Ootegem Jan 18 '22 at 10:00c
over a single distance. If I actually measured the speed itself, I should be able to do that, but with this setup, shouldc
not be constant, I wouldn't know where speed is gained/lost – Elias Van Ootegem Jan 19 '22 at 14:55