# One-way speed of light confirmation, not measurement [duplicate]

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.

• While you're at it, try your hand at the Byzantine generals problem - you will find lots of your findings applicable ;) And coming from the IT, you should recognize its importance fairly well. More to the point - syncing is not trivial. Also I advise you to read on the barn pole paradox - we've found it the most eye-opening on SR way back in the freshman year. EDIT: misread the post. Jan 17 at 14:30
• Elias, I cannot understand how your proposed arrangement leads to the conclusion that the speed of light is the same in both directions. Perhaps you could explain. Jan 17 at 22:27
• When you ran through the standard argument about why what you want to do is impossible, and applied that argument to your specific proposal, at exactly what step did you get stuck? Jan 17 at 23:27
• Does this answer your question? Can One-Way Speed of Light be Instantaneous?
– Dale
Jan 17 at 23:31
• If you determine that it is constant in both directions then you have in fact measured it. There is only one value of c that is consistent with it being constant in both directions. Simply saying that you are not measuring something doesn’t mean that you actually aren’t. This is a standard one way speed measurement question
– Dale
Jan 18 at 12:18

I will write in general on how to approach the issue.

First:
The context is spacetime as described in terms of special relativity. In terms of special relativity it is assumed/granted that the Minkowski metric is the appropriate metric.

In order to meaningfully approach the issue of speed of light it is necessary to absorb the concept of Minkowski metric. The Minkowski metric describes the arena where physics is taking place.

In order to make a speed assessment it is necessary to disseminate time. One way or another, you have to disseminate time, otherwise you cannot even begin to make a speed assessment.

There are multiple distinct ways to disseminate time. The interesting thing is: in Minkowski spacetime there are subtleties such that simultaneity is to some extent underdetermined.

It's not a problem of randomness or ambiguity. The various ways to establish a plane of simultaneity arrive at mutually consistent results.

The following list of three different ways to disseminate time is not exhaustive, but it suffices for the purpose of this answer:

• Using transportable clocks
• A separate setup that implements Einstein synchronization procedure
• Using some modulation of the to-be-measured light itself to disseminate time.

What you describe falls in the third category.

For instance, the light pulses can be modulated such that packets of pulses are in, say, Morse code, each declaring the clock reading of the local clock of the pulse-packet emitter, giving each packet a time stamp of when it was emitted.

The general approach, when assessing a proposal for speed of light assessment is to look: in this proposal, how is the dissemination of time implemented?

If the Minkowski metric is granted then it follows logically that all forms of disseminating time will arrive at the same result.

(Its not effective to reason on a case-by-case basis. To get to the bottom of the issue one must think in terms of what all cases have in common: the time dissemination is taking place in Minkowski spacetime.)

In Minkowski spacetime any procedure will arrive at the same result as the result of the procedure that involves setting up a round trip of light.

I think it's worthwhile to make the following clear:
It's not literally the case that the speed of light can only be measured by way of performing a round trip of the light. Rather: any procedure that you invent (to disseminate time) will arrive at the same plane of simultaneity as the procedure that involves setting up a round trip of light.

Historically the first assessment of the speed of light was by inferring it from a difference. This is known as Rømer's determination of the speed of light

I propose the following thought experiment:
Assume that the Rømer procedure can be pushed to the same level of accuracy as the Michelson-Morley experiment.

The purpose of the Michelson-Morley experiment was to find the velocity of the Earth with respect to the Luminiferous Aether.

Jupiter takes a little under 12 years to orbit the Sun. So: over the span of that time period the Rømer procedure will assess the speed of light in all directions within the solar system's planetary plane.

If the Luminiferous Aether would exist in the form expected by Michelson & Morley then the thought-experiment-Rømer-procedure would give different values for the speed of light, depending on the direction of propagation of the light.

Here's the thing:
If it is granted that the physics is happening in Minkowski spacetime, then you expect that the thought-experiment-Rømer-procedure will find the same speed in all directions.

• Perhaps I was not clear enough (though the title alone says I'm not proposing to measure speed). SoL has been measured, and is therefore assumed to be known. The hypothesis is that c is constant in both directions of travel. The setup aims to verify this to be true. Measuring the speed itself has the issue that we need to measure speed over a round trip. The proposed setup has 1 clock, and 1 node that can verify/predict how long the message takes to travel in a single direction, not a round trip Jan 18 at 9:52