More on a Method for objectively determining OWLS

[Aetherist]

Let there be two Clocks (A & B) situated some fixed distance (D)
apart and assuming that the procedure below properly accounts for
any lead/lag offset between the two clocks:

T_AB = D/c + O
T_BA = D/c - O

Then,

O = T_AB - D/c
O = D/c - T_BA

Thus,

2O = (T_AB - D/c) + (D/c - T_BA)

Simplifying,

2O = T_AB - T_BA

Finally,

O = (T_AB - T_BA) / 2

Next we set Clock B's time to clock A by defining Clock A
as the master and sending the setting to B. At this point
clock B should actually lag clock A by exactly D/c (if c is
isotropic) since this is the 'time lag' getting clock A's
signal to B. So not we advance B by exactly this amount.
The distance D is to be determined by military grade GPS.

Now starting every 30 minutes Clock A sends to B & B to
A and example results are given below:

Isotropic behavior...

Time T_AB T_BA Offset ()O)
-------- ------------ ------------ -----------
12:00 PM 0.01000004 0.00999996 4.0000E-08
12:30 PM 0.00999999 0.01000001 -1.0000E-08
01:00 AM 0.01000001 0.01000000 5.0000E-09
01:30 AM 0.00999999 0.01000000 -5.0000E-09
02:00 AM 0.01000000 0.01000000 0.0000E+00
02:30 AM 0.00999999 0.01000001 -1.0000E-08
03:00 AM 0.01000001 0.01000000 5.0000E-09
03:30 AM 0.01000000 0.01000000 0.0000E+00
04:00 AM 0.00999999 0.01000000 -5.0000E-09
04:30 AM 0.01000000 0.01000000 0.0000E+00
05:00 AM 0.00999999 0.01000001 -1.0000E-08
05:30 AM 0.01000000 0.01000000 0.0000E+00
06:00 AM 0.00999999 0.01000001 -1.0000E-08
06:30 AM 0.01000000 0.01000000 0.0000E+00
07:00 AM 0.01000000 0.01000000 0.0000E+00
-------- ------------ ------------ -----------
Means: 0.01000000 0.010000001 8.6736E-19

Case with a net speed (v) of 447 m/sec

Time T_AB T_BA Offset ()O)
-------- ------------ ------------ -----------
12:00 PM 0.01000150 0.00999850 1.5000E-06
12:30 PM 0.01000152 0.00999848 1.5200E-06
01:00 AM 0.01000150 0.00999849 1.5050E-06
01:30 AM 0.01000151 0.00999847 1.5200E-06
02:00 AM 0.01000152 0.00999850 1.5100E-06
02:30 AM 0.01000150 0.00999849 1.5050E-06
03:00 AM 0.01000150 0.00999852 1.4900E-06
03:30 AM 0.01000150 0.00999851 1.4950E-06
04:00 AM 0.01000150 0.00999849 1.5050E-06
04:30 AM 0.01000150 0.00999850 1.5000E-06
05:00 AM 0.01000150 0.00999848 1.5100E-06
05:30 AM 0.01000153 0.00999850 1.5150E-06
06:00 AM 0.01000150 0.00999855 1.4750E-06
06:30 AM 0.01000149 0.00999850 1.4950E-06
07:00 AM 0.01000150 0.00999845 1.5250E-06
-------- ------------ ------------ -----------
Means: 0.01000150 0.00999850 1.5047E-06

We note that if synchronized in this manner it would
appear the the net OWLS anisotropy is given by the net
offset:

v = Oc = 2.98E08(1.50E-06) = 447 m/sec

and can be consistently determined in this manner. No?

[PD]

On 11/24/2011 1:20 PM, Aetherist wrote:
> Let there be two Clocks (A& B) situated some fixed distance (D)

> apart and assuming that the procedure below properly accounts for
> any lead/lag offset between the two clocks:
>
> T_AB = D/c + O
> T_BA = D/c - O
>
> Then,
>
> O = T_AB - D/c
> O = D/c - T_BA
>
> Thus,
>
> 2O = (T_AB - D/c) + (D/c - T_BA)
>
> Simplifying,
>
> 2O = T_AB - T_BA
>
> Finally,
>
> O = (T_AB - T_BA) / 2

And then adjusting clock B to correct for this offset. This is
*precisely* the Einsteinian clock synchronization procedure.

[Aetherist]

Yeah, so. did you read the whole post?

[Aetherist]

On Thu, 24 Nov 2011 11:20:44 -0800, Aetherist <TheAet...@gmail.com> wrote:

>Let there be two Clocks (A & B) situated some fixed distance (D)
>apart and assuming that the procedure below properly accounts for
>any lead/lag offset between the two clocks:
>
>T_AB = D/c + O
>T_BA = D/c - O
>
>Then,
>
>O = T_AB - D/c
>O = D/c - T_BA
>
>Thus,
>
>2O = (T_AB - D/c) + (D/c - T_BA)
>
>Simplifying,
>
>2O = T_AB - T_BA
>
>Finally,
>
>O = (T_AB - T_BA) / 2
>
>Next we set Clock B's time to clock A by defining Clock A
>as the master and sending the setting to B. At this point
>clock B should actually lag clock A by exactly D/c (if c is
>isotropic) since this is the 'time lag' getting clock A's

>signal to B. So {deleted} we advance B by exactly this amount
>(D/c). The distance D is to be determined by military grade GPS.
Typo correction ^

[Aetherist]

On Thu, 24 Nov 2011 12:51:13 -0800, Aetherist <TheAet...@gmail.com> wrote:

>On Thu, 24 Nov 2011 11:20:44 -0800, Aetherist <TheAet...@gmail.com> wrote:
>
>>Let there be two Clocks (A & B) situated some fixed distance (D)
>>apart and assuming that the procedure below properly accounts for
>>any lead/lag offset between the two clocks:
>>
>>T_AB = D/c + O
>>T_BA = D/c - O
>>
>>Then,
>>
>>O = T_AB - D/c
>>O = D/c - T_BA
>>
>>Thus,
>>
>>2O = (T_AB - D/c) + (D/c - T_BA)
>>
>>Simplifying,
>>
>>2O = T_AB - T_BA
>>
>>Finally,
>>
>>O = (T_AB - T_BA) / 2
>>
>>Next we set Clock B's time to clock A by defining Clock A
>>as the master and sending the setting to B. At this point
>>clock B should actually lag clock A by exactly D/c (if c is
>>isotropic) since this is the 'time lag' getting clock A's
>>signal to B. So {deleted} we advance B by exactly this amount
>>(D/c). The distance D is to be determined by military grade GPS.
>Typo correction ^

Upon further thought Sending Clock A's time to B must involve
D/c{+/-} depending upon any preexisting motion. Since I have
been trying to figure a way of removing any such ingrained
affects just adding D/c does not account for this affect.

Damn!!!

This 'might' do it.

Clock A takes its current value subtracts D/c and sends this to
Clock B. Clock B then takes this value adds 2D/c to this and sets
itself. This should ensure that these clocks are offset from each
other by exactly 2D/c regardless of and OLWL anisotropy...
2D/c

[james thomas]

On Nov 24, 3:40 pm, Aetherist <TheAether...@gmail.com> wrote:
> On Thu, 24 Nov 2011 12:51:13 -0800, Aetherist <TheAether...@gmail.com> wrote:

> >>and can be consistently determined in this manner.  No?- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

What about two way or 2 light waves moving directly away or toward one
another in space?
Should that not be a comming together or apart at 2C when considering
both?
What about the slower motions of matter interacting for the two frame
system?

Mitch Raemsch; the prize

[Inertial]

"Aetherist" wrote in message
news:qektc75hurm80860c...@4ax.com...

>Upon further thought Sending Clock A's time to B must involve
>D/c{+/-} depending upon any preexisting motion. Since I have
>been trying to figure a way of removing any such ingrained
>affects just adding D/c does not account for this affect.
>
>Damn!!!
>
>This 'might' do it.
>
>Clock A takes its current value subtracts D/c and sends this to
>Clock B. Clock B then takes this value adds 2D/c to this and sets
>itself. This should ensure that these clocks are offset from each
>other by exactly 2D/c regardless of and OLWL anisotropy...
>2D/c

Nope .. doesn't work for an OWLS measurement .. as it depends on light being
isotropic c to correctly synchronise the clocks. You can't assume what it
is you are measuring. Regardless of whether OWLS was isotropic or not, you
would still measure it as isotropic with this setup. Basically. whenever
you have two separated clocks involved, there are assumptions about clock
sync to be made, and results will depend on how that sync is defined.

[Aetherist]

Take Einstein's first postulate as fact, that is, light always travels
at a speed c regardless of the speed of anything else. Now we have
the second postulate, the speed of light over and closed path will be
'measured' at that value for any system at rest or in constant motion
(an inertial state).

So, you have two objects approaching each other at speed v. Object A
flshes a light towards B at distance D. If B were not moving this pulse
would arrive at B in D/c seconds. Since B IS moving, approaching A and
that pulse approaching B will actually arrives at B at D/(c + v) but
this just means that the light traveled a shorter 'distance' at the
speed c. This issue that I'm trying to address when A & B are both
moving at v and thus D, as measured by either A or B is fixed. The
very same same thing applies though. If B flashes a pulse towards
A at some time t it will arrive at A in an interval dependent upon v.
But IF A & B do not know they are moving they don't realize that the
pulse didn't travel D but, instead, D - vt. Thus by their definition

v = D/t

and

t = D/(c + v) = D'/c

then

v = cD/D' > c

This is the closing speed of the light with A. This should
occur for any system in motion since the first postulate
defines a universal background reference frame.

>Mitch Raemsch; the prize

[Aetherist]

Ah, yes it does explicitly assume light IS isotropic c. That IS the
point, if it IS you get the results of example 1. If NOT then you
get something else, like example B. By assuming and explicitly
setting up for isotropic AND NOT! using OWLS signals you remove from
your problem any possible hidden biases...

[Inertial]

"Aetherist" wrote in message
news:87otc7hdq7pnbnibt...@4ax.com...

>
>On Fri, 25 Nov 2011 11:07:00 +1100, "Inertial" <relat...@rest.com> wrote:
>
>>"Aetherist" wrote in message
>>news:qektc75hurm80860c...@4ax.com...
>>>Upon further thought Sending Clock A's time to B must involve
>>>D/c{+/-} depending upon any preexisting motion. Since I have
>>>been trying to figure a way of removing any such ingrained
>>>affects just adding D/c does not account for this affect.
>>>
>>>Damn!!!
>>>
>>>This 'might' do it.
>>>
>>>Clock A takes its current value subtracts D/c and sends this to
>>>Clock B. Clock B then takes this value adds 2D/c to this and sets
>>>itself. This should ensure that these clocks are offset from each
>>>other by exactly 2D/c regardless of and OLWL anisotropy...
>>>2D/c
>>
>>Nope .. doesn't work for an OWLS measurement .. as it depends on light
>>being
>>isotropic c to correctly synchronise the clocks. You can't assume what it
>>is you are measuring. Regardless of whether OWLS was isotropic or not,
>>you
>>would still measure it as isotropic with this setup. Basically. whenever
>>you have two separated clocks involved, there are assumptions about clock
>>sync to be made, and results will depend on how that sync is defined.
>
> Ah, yes it does explicitly assume light IS isotropic c.

Indeed it does .. so it can't measure whether or not that is the case.

> That IS the
> point,

Yes .. which you don't seem to be getting

> if it IS you get the results of example 1. If NOT then you
> get something else, like example B.

No .. you get the same answers for timing regardless because you are
explicitly setting your clocks to show isotropic. All you can measure is if
TWLS is c or not. Not what OWLS is, as your clocks are set to always show
it as isotropic.

> By assuming and explicitly
>setting up for isotropic AND NOT! using OWLS signals you remove from
>your problem any possible hidden biases...

And you remove the ability to measure the OWLS to be anything other than
isotropic.

[Surfer]

On Thu, 24 Nov 2011 16:31:50 -0800, Aetherist <TheAet...@gmail.com>
wrote:

Section 2 in the following paper considers one-way speed of light
anisotropy measurements.

Experimental Investigation of the Fresnel Drag Effect in RF Coaxial
Cables
http://arxiv.org/abs/1009.5772

".....Fig.1 shows the arrangement for measuring the one-way speed of
light, either in vacuum, a dielectric, or RF coaxial cable. It is
usually argued that one-way speed of light measurements are not
possible because the clocks cannot be synchronised. Here we show that
this is false......"



In the following paper, reanalysis of a OWLS experiment found that the
results were consistent with absolute motion effects.

Combining NASA/JPL One-Way Optical-Fiber Light-Speed Data with
Spacecraft Earth-Flyby Doppler-Shift Data to Characterise 3-Space Flow
http://arxiv.org/abs/0906.5404

[Inertial]

"Surfer" wrote in message
news:tiqtc75sofcbh56fd...@4ax.com...
[snip]
Cahill is a well-known crackpot

[Aetherist]

Since the transit to B will always be less than 2D/c and what is
sent is Clock A PLUS 2D/c and B sets itself to this. Thus Clock B is
expressly sent to read A + 2D/c. Given that any TWL transit time
will be 2D/c then we can test this, A sends to B which sends to
A its reading (note, engineering-wise we need to account for internal
processing times). If B reading is exactly the same as A's at this
juncture we have our precise desired offset. We keep cycling to we do.
Finally, when true A sends to B rtheOK..If B receives the OK it
subtracts EXACTLY D/c from its reading. Now, without actual OWLS
process we have clocks that are offset from each other by D/c which
assumes isotropic c.

Now remember we did NOT assume the actual transit times WERE D/c
we set our system up so that IF they are we will get a transit
time which IS D/c in both direction and no offset. If however
the transit ARE NOT exactly D/c the the transits times will not be
identical and there will be a computable offset indication that
the clocks do not appear to be 'in-synch'. If you look at the
examples provided you'll see this effect.

[Aetherist]

There are two authors to the paper referenced. Also, rather than
personal attacks how about point out any actual errors. Start
with section 2 equations 2 thru 6 and go from there. That's
the scientific cthing to do...

[Inertial]

"Aetherist" wrote in message
news:5uqtc796t92t5bet5...@4ax.com...

>
>On Fri, 25 Nov 2011 11:46:05 +1100, "Inertial" <relat...@rest.com> wrote:

[snip for brevity]

>>And you remove the ability to measure the OWLS to be anything other than
>>isotropic.
>
>Since the transit to B will always be less than 2D/c and what is
>sent is Clock A PLUS 2D/c and B sets itself to this. Thus Clock B is
>expressly sent to read A + 2D/c.

To refresh your memory of what you are doing...

==

Clock A takes its current value subtracts D/c and sends this to
Clock B. Clock B then takes this value adds 2D/c to this and sets
itself. This should ensure that these clocks are offset from each
other by exactly 2D/c regardless of and OLWL anisotropy...

==

What we want is for Clock B to be set so that

You are setting the time on Clock B to be Time_On_Clock_A_When_Signal_Sent +
D/c. You want that to be the same as what clock A shows at the time the
signal arrives at B .. ie Time_On_Clock_A_When_Signal_Sent + transit_time.
The only way for those to be the same (which is what you need) is if
transit_time = D/c .. ie that OWLS is isotropic c. ie your clock settings
assume the result you are trying to measure.

And note that your "This should ensure..." is just nonsense. What it will
ensure is that the clocks are in sync (not offset at all) but only if OWLS
is isotropic c. Otherwise they are out of sync by some amount we cannot
determine.

The point here is ... if you are using two separated clocks to measure ANY
speed, light or otherwise, you HAVE to make assumptions about clock sync.
This has to be independent of what it is you are measuring. In your case,
you are using OWLS to synchronise the clocks and then trying to measure OWLS
using them. That's not going to work. Try again.

[Inertial]

"Aetherist" wrote in message
news:3pstc7p55ro5pinnf...@4ax.com...

>
>On Fri, 25 Nov 2011 12:34:32 +1100, "Inertial" <relat...@rest.com> wrote:
>
>>"Surfer" wrote in message
>>news:tiqtc75sofcbh56fd...@4ax.com...
>>[snip]
>>Cahill is a well-known crackpot
>
>There are two authors to the paper referenced.

Two papers were referenced .. and from what I say, both list as being by
cahill. If some other crackpot decided to work on the paper with crackpot
cahill, that doesn't change anything.

> Also, rather than
>personal attacks how about point out any actual errors. Start
>with section 2 equations 2 thru 6 and go from there. That's
>the scientific cthing to do...

a) I don't have access to the papers

b) we are dealing here with YOUR problems .. and you still haven't realised
that your method will not work. Diverting off to someone else's crackpot
paper isn't helping you understand.

So leave the crackpot papers alone and concentrate on what YOU are
proposing, with the separated clocks measuring OWLS anisotropy, which will
not work.

[Aetherist]

On Fri, 25 Nov 2011 12:54:18 +1100, "Inertial" <relat...@rest.com> wrote:

>"Aetherist" wrote in message
>news:5uqtc796t92t5bet5...@4ax.com...
>>
>>On Fri, 25 Nov 2011 11:46:05 +1100, "Inertial" <relat...@rest.com> wrote:
>[snip for brevity]
>>>And you remove the ability to measure the OWLS to be anything other than
>>>isotropic.
>>
>>Since the transit to B will always be less than 2D/c and what is
>>sent is Clock A PLUS 2D/c and B sets itself to this. Thus Clock B is
>>expressly sent to read A + 2D/c.
>
>To refresh your memory of what you are doing...
>
>==
>Clock A takes its current value subtracts D/c and sends this to
>Clock B.

No, Clock A adds 2D/c and sends this to B which sets itself to this
value.

>Clock B then takes this value adds 2D/c to this and sets
>itself. This should ensure that these clocks are offset from each
>other by exactly 2D/c regardless of and OLWL anisotropy...
>==

No, won't work because actual transit time may not be D/c.

>What we want is for Clock B to be set so that
>
>You are setting the time on Clock B to be Time_On_Clock_A_When_Signal_Sent +
>D/c. You want that to be the same as what clock A shows at the time the
>signal arrives at B .. ie Time_On_Clock_A_When_Signal_Sent + transit_time.
>The only way for those to be the same (which is what you need) is if
>transit_time = D/c .. ie that OWLS is isotropic c. ie your clock settings
>assume the result you are trying to measure.

By setting the value at Clock A to A + 2D/c we can e assured that Clock
B will set itself ahead of any actual arrival time. Now Clock B 'would
be' ahead of clock B by D/c IF that ransit was D/c. If Not, it is some
other value. But the instant Clock B sets it sends back to Clock A.

Given TWLS IS 2D/c this 'should' make the arrival at A match A's time
exactly. If so, A sends the OK. When B gets this OK it subtracts D/c
from its reading. IF AND ONLY IF OWLS actually equals D/c. Now A sends
its reading to B. B subtract A's from its on arrival to get a delta t.

Since we DID NOT actually depend on any OW signal to set this up no
hidden offsets can affect it. so

T_AB = T_B - T_A from A to B
T_BA = T_A - T_B from B to A

If it is D/c great, T_AB = T_BA, if it anything else T_AB - T_BA != 0
Since we setup clock B to read EXACTLY the same as A at any given
instant. This is the whole point & goal, to get two clocks reading
exactly the same at the same instant, no Offset, period. This makes
the delta times actual deltas. Now, if OWLS isn't isotropic setting
offsets using signaling assuming it is will certainly make results
dependent upon the assumption. I am attempting to come up with
a procedure that assumes isotropy and DOES NOT! require any setting
based upon actual arrival times. By removing any dependency upon
actual transits and simply setting up assuming explicit isotropy
results can show whether the initial assumption is true OR FALSE.
Science is all about testing assumptions.

[Aetherist]

On Fri, 25 Nov 2011 12:58:27 +1100, "Inertial" <relat...@rest.com> wrote:

>"Aetherist" wrote in message
>news:3pstc7p55ro5pinnf...@4ax.com...
>>
>>On Fri, 25 Nov 2011 12:34:32 +1100, "Inertial" <relat...@rest.com> wrote:
>>
>>>"Surfer" wrote in message
>>>news:tiqtc75sofcbh56fd...@4ax.com...
>>>[snip]
>>>Cahill is a well-known crackpot
>>
>>There are two authors to the paper referenced.
>
>Two papers were referenced .. and from what I say, both list as being by
>cahill. If some other crackpot decided to work on the paper with crackpot
>cahill, that doesn't change anything.
>
>> Also, rather than
>>personal attacks how about point out any actual errors. Start
>>with section 2 equations 2 thru 6 and go from there. That's
>>the scientific cthing to do...
>
>a) I don't have access to the papers

Funny, this link worked fine for me

http://arxiv.org/abs/1009.5772

Just click the PDF link...

>b) we are dealing here with YOUR problems .. and you still haven't realised
>that your method will not work. Diverting off to someone else's crackpot
>paper isn't helping you understand.

I can multi-task, can't you? I'm sure Surfer would be glad to address
you technical issue as long as you're specific and addressing actual
issues. You are not a cleric from the middle ages are you? Deal with
the actual physics, quit the name calling...

[Inertial]

"Aetherist" wrote in message
news:ubttc7poa1d1c1ieg...@4ax.com...

>
>On Fri, 25 Nov 2011 12:54:18 +1100, "Inertial" <relat...@rest.com> wrote:
>
>>"Aetherist" wrote in message
>>news:5uqtc796t92t5bet5...@4ax.com...
>>>
>>>On Fri, 25 Nov 2011 11:46:05 +1100, "Inertial" <relat...@rest.com>
>>>wrote:
>>[snip for brevity]
>>>>And you remove the ability to measure the OWLS to be anything other than
>>>>isotropic.
>>>
>>>Since the transit to B will always be less than 2D/c and what is
>>>sent is Clock A PLUS 2D/c and B sets itself to this. Thus Clock B is
>>>expressly sent to read A + 2D/c.
>>
>>To refresh your memory of what you are doing...
>>
>>==
>>Clock A takes its current value subtracts D/c and sends this to
>>Clock B.
>
>No, Clock A adds 2D/c and sends this to B which sets itself to this
>value.

I am quoting your own description of what you are doing .. don't you know?

>>Clock B then takes this value adds 2D/c to this and sets
>>itself. This should ensure that these clocks are offset from each
>>other by exactly 2D/c regardless of and OLWL anisotropy...
>>==
>
>No, won't work because actual transit time may not be D/c.

That's what I am telling you !!! Gees.

So WTF is the method you are actually using now ?????

>>What we want is for Clock B to be set so that
>>
>>You are setting the time on Clock B to be Time_On_Clock_A_When_Signal_Sent
>>+
>>D/c. You want that to be the same as what clock A shows at the time the
>>signal arrives at B .. ie Time_On_Clock_A_When_Signal_Sent + transit_time.
>>The only way for those to be the same (which is what you need) is if
>>transit_time = D/c .. ie that OWLS is isotropic c. ie your clock settings
>>assume the result you are trying to measure.
>
>By setting the value at Clock A to A + 2D/c we can e assured that Clock
>B will set itself ahead of any actual arrival time. Now Clock B 'would
>be' ahead of clock B by D/c IF that ransit was D/c. If Not, it is some
>other value. But the instant Clock B sets it sends back to Clock A.

WTF are you talking about .. clock b being ahead of itself

>Given TWLS IS 2D/c this 'should' make the arrival at A match A's time
>exactly.

If you are saying that time_on_clock_a_when_signal_sent + 2D/c =
time_on_clock_a_when_signal_received_back .. then yes of course (given we
are assuming TWLS is c)

But that doesn't help you work out OWLS

> If so, A sends the OK. When B gets this OK it subtracts D/c
>from its reading. IF AND ONLY IF OWLS actually equals D/c.

No .. OWLS has nothing to do with this

> Now A sends
>its reading to B. B subtract A's from its on arrival to get a delta t.
>
>Since we DID NOT actually depend on any OW signal to set this up no
>hidden offsets can affect it. so
>
>T_AB = T_B - T_A from A to B
>T_BA = T_A - T_B from B to A
>
>If it is D/c great, T_AB = T_BA, if it anything else T_AB - T_BA != 0
>Since we setup clock B to read EXACTLY the same as A at any given
>instant. This is the whole point & goal, to get two clocks reading
>exactly the same at the same instant, no Offset, period. This makes
>the delta times actual deltas. Now, if OWLS isn't isotropic setting
>offsets using signaling assuming it is will certainly make results
>dependent upon the assumption. I am attempting to come up with
>a procedure that assumes isotropy and DOES NOT! require any setting
>based upon actual arrival times.

But you are failing

> By removing any dependency upon
>actual transits and simply setting up assuming explicit isotropy
>results can show whether the initial assumption is true OR FALSE.
>Science is all about testing assumptions.

>>And note that your "This should ensure..." is just nonsense. What it will
>>ensure is that the clocks are in sync (not offset at all) but only if OWLS
>>is isotropic c. Otherwise they are out of sync by some amount we cannot
>>determine.
>>
>>The point here is ... if you are using two separated clocks to measure ANY
>>speed, light or otherwise, you HAVE to make assumptions about clock sync.
>>This has to be independent of what it is you are measuring. In your case,
>>you are using OWLS to synchronise the clocks and then trying to measure
>>OWLS
>>using them. That's not going to work. Try again.

You still don't get it do you ... no matter how much you fiddle around with
these signals, you are getting OWLS isotropy assumptions.

Now .. seeing you seem confused about what you are doing (as you just said
your own method that I quoted was wrong) .. please tell me EXACTLY what is
it you propose is done with the clocks (no analysis of it .. just what
happens at each clock and what signals are sent).

I'll either point out your error, or admit you have found a way around this.
My bet is that the first choice is a certainty.

[Inertial]

"Aetherist" wrote in message
news:tsvtc794n37h84e4g...@4ax.com...

>
>On Fri, 25 Nov 2011 12:58:27 +1100, "Inertial" <relat...@rest.com> wrote:
>
>>"Aetherist" wrote in message
>>news:3pstc7p55ro5pinnf...@4ax.com...
>>>
>>>On Fri, 25 Nov 2011 12:34:32 +1100, "Inertial" <relat...@rest.com>
>>>wrote:
>>>
>>>>"Surfer" wrote in message
>>>>news:tiqtc75sofcbh56fd...@4ax.com...
>>>>[snip]
>>>>Cahill is a well-known crackpot
>>>
>>>There are two authors to the paper referenced.
>>
>>Two papers were referenced .. and from what I say, both list as being by
>>cahill. If some other crackpot decided to work on the paper with crackpot
>>cahill, that doesn't change anything.
>>
>>> Also, rather than
>>>personal attacks how about point out any actual errors. Start
>>>with section 2 equations 2 thru 6 and go from there. That's
>>>the scientific cthing to do...
>>
>>a) I don't have access to the papers
>
>Funny, this link worked fine for me
>
> http://arxiv.org/abs/1009.5772
>
>Just click the PDF link...

Ahh. thought it was one of those pay-to-see-the-paper site.

Regardless .. its not relevant here now

>>b) we are dealing here with YOUR problems .. and you still haven't
>>realised
>>that your method will not work. Diverting off to someone else's crackpot
>>paper isn't helping you understand.
>
> I can multi-task, can't you?

Make a new thread if you want.

> I'm sure Surfer would be glad to address
>you technical issue as long as you're specific and addressing actual
>issues. You are not a cleric from the middle ages are you? Deal with
>the actual physics, quit the name calling...

I'm pretty sure Surfer is the crackpot Cahill. If he want an analysis of
the papers, he can post them in his own thread. I'm not going to do it
here. There's enough to deal with with your own problems.

[Bruce Richmond]

On Nov 24, 8:36 pm, Aetherist <TheAether...@gmail.com> wrote:

> On Fri, 25 Nov 2011 11:46:05 +1100, "Inertial" <relativ...@rest.com> wrote:
> >"Aetherist"  wrote in message
> >news:87otc7hdq7pnbnibt...@4ax.com...
>

Minus whatever time it actually took for the transmission to cover the
distance. Clock A kept ticking while the unchanging signal was in
transit.

> Given that any TWL transit time will be 2D/c
> then we can test this, A sends to B which sends to
> A its reading (note, engineering-wise we need to account for internal
> processing times).  If B reading is exactly the same as A's at this
> juncture we have our precise desired offset.

And again clock A will keep ticking while the unchanging signal is in
transit from B to A. Add the two transit times together and they will
total 2D/c, but we don't know how the transit times compare to each
other. I can tell you though that clock B does not read the same as
clock A. Clock A lags clock B by whatever the transit time from B to
A is.

> We keep cycling to we do.
> Finally, when true A sends to B rtheOK..If B receives the OK it
> subtracts EXACTLY D/c from its reading.

And you just made the assumption that the transit times were equal.
If in fact light was traveling at c+v and c-v then D/c would not be
correct. In fact the assumption that the round trip took 2D/c wasn't
really correct either.

> Now, without actual OWLS
> process we have clocks that are offset from each other by D/c which
> assumes isotropic c.
>
> Now remember we did NOT assume the actual transit times WERE D/c
> we set our system up so that IF they are we will get a transit
> time which IS D/c in both direction and no offset.  If however
> the transit ARE NOT exactly D/c the the transits times will not be
> identical and there will be a computable offset indication that
> the clocks do not appear to be 'in-synch'.  If you look at the

> examples provided you'll see this effect.- Hide quoted text -

>
> - Show quoted text -

You need to look again. You have set it up so that the two way
transit time that you added to clock A equals the two way transit time
that you measure. You still don't know what the one way transit times
were. How do you know what the transit times really were without
using the clocks you just set based on the assumption that they were
equal?

[Aetherist]

Maybe I'm just not getting it, again. Let's look at particulars

Say, at 8:00 PM Sharp sends to clock B station exactly 0.01 light
seconds distant 8:00:00:0.02.

This arrives at Clock B at 8:00:00:0.01015 and B sets to 8:00:00:0.02
and send to A which takes 0.00985 sec arriving back at A at 8:00:00:0.02
Clock B reads 8:00:00:02985. Clock A finds this matches its reading
and sents OK. It takes 0.01015 seconds to arrive at B, B now reads
8:00:00:0.04 Clock A reads 8:00:00:0.03015. Clock B subtracts 0.01
and reads 8:00:00:0.03 Vs 8:00:00:0.03015 on Clock A.

Ok, ok, @#%!

I give up for now... There has got to be a way of testing this.

[Bruce Richmond]

On Nov 24, 9:37 pm, Aetherist <TheAether...@gmail.com> wrote:

> On Fri, 25 Nov 2011 12:54:18 +1100, "Inertial" <relativ...@rest.com> wrote:
> >"Aetherist"  wrote in message
> >news:5uqtc796t92t5bet5...@4ax.com...
>

But that is the very question you are trying to find the answer to.
You don't know at this point. If you assume that it does your clock
sync will confirm your assumption. If you assume it does not your
clock sync will confirm your assumption.

> Now A sends
> its reading to B.  B subtract A's from its on arrival to get a delta t.
>
> Since we DID NOT actually depend on any OW signal to set this up no
> hidden offsets can affect it. so

You included the assumption that the one way time was D/c when you set
clock B. If that wasn't in fact the case then you have a hidden
offset included.

> T_AB = T_B - T_A from A to B
> T_BA = T_A - T_B from B to A
>
> If it is D/c great, T_AB = T_BA, if it anything else T_AB - T_BA != 0
> Since we setup clock B to read EXACTLY the same as A at any given
> instant.

Based on the assumption that the one way transit time is D/c.

> This is the whole point & goal, to get two clocks reading
> exactly the same at the same instant, no Offset, period. This makes
> the delta times actual deltas.

If the actual one way transit time from A to B was D/(c+v) then you
included a hidden offset when you assumed it was D/c.

> Now, if OWLS isn't isotropic setting
> offsets using signaling assuming it is will certainly make results
> dependent upon the assumption.  I am attempting to come up with
> a procedure that assumes isotropy and DOES NOT! require any setting
> based upon actual arrival times.  By removing any dependency upon
> actual transits and simply setting up assuming explicit isotropy
> results can show whether the initial assumption is true OR FALSE.
> Science is all about testing assumptions.
>
>
>
> >And note that your "This should ensure..." is just nonsense.  What it will
> >ensure is that the clocks are in sync (not offset at all) but only if OWLS
> >is isotropic c.  Otherwise they are out of sync by some amount we cannot
> >determine.
>
> >The point here is ... if you are using two separated clocks to measure ANY
> >speed, light or otherwise, you HAVE to make assumptions about clock sync.
> >This has to be independent of what it is you are measuring.  In your case,
> >you are using OWLS to synchronise the clocks and then trying to measure OWLS

> >using them.  That's not going to work.  Try again.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -

[james thomas]

On Nov 24, 4:26 pm, Aetherist <TheAether...@gmail.com> wrote:

> >Mitch Raemsch; the prize- Hide quoted text -

>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

You could move toward light in the opposite direction that it is
propagating and you and the light will come together faster.

James

[Inertial]

"Aetherist" wrote in message
news:vi1uc7dm87t1ok0cq...@4ax.com...

> Maybe I'm just not getting it, again.

You think? :)

> Let's look at particulars
>
>Say, at 8:00 PM Sharp sends to clock B station exactly 0.01 light
>seconds distant 8:00:00:0.02.

OK .. so clock A sends clock B a message with value clock_a_time_now + 2D/c

> This arrives at Clock B at 8:00:00:0.01015

OK .. So for the sake of example you are assuming a 0.01015 transit time
from A to B (i.e. seeing what would happen if OWLS is not isotropic)

> and B sets to 8:00:00:0.02
> and send to A

So clock B sends back the message it got from clock A

> which takes 0.00985 sec arriving back at A at 8:00:00:0.02

Fine. So the clocks are now out of sync

> Clock B reads 8:00:00:02985. Clock A finds this matches its reading
> and sents OK.

Of course it does

> It takes 0.01015 seconds to arrive at B,

So you're sending the signal back again to B now

> B now reads
> 8:00:00:0.04 Clock A reads 8:00:00:0.03015.

OK

> Clock B subtracts 0.01

Why? That is assuming you know the OWLS is isotropic

> and reads 8:00:00:0.03 Vs 8:00:00:0.03015 on Clock A.
>
> Ok, ok, @#%!
>
> I give up for now... There has got to be a way of testing this.

Why do you think there has to be?

[Dono.]

On Nov 24, 9:28 pm, Aetherist <TheAether...@gmail.com> wrote:
>
> Maybe I'm just not getting it, again.

Of course you aren't, your Alzheimer and anti-relativistic bias form
an explosive combination, Paul.

[Dono.]

On Nov 24, 7:24 pm, Surfer <n...@spam.net> wrote:
>snip idiocies<

Ah, you are back with your nose up Cahill's ass, Peter. When will you
ever learn?

[Tom Roberts]

On 11/24/11 11/24/11 1:20 PM, Aetherist wrote:
> [...] (if c is isotropic) [...]

Even though you don't phrase it that way, you are ASSUMING that the speed of
light is isotropic, so you aren't "objectively determining OWLS". You have
simply described one of Einstein's synchronization procedures, using different
words and symbols.


Tom Roberts