On Sun, 25 Feb 2007 10:32:32 -0000, "George Dishman"
wrote:


"Henri Wilson" HW@.... wrote in message
.. .
On 23 Feb 2007 01:45:05 -0800, "George Dishman"
wrote:
On 23 Feb, 09:07, HW@....(Henri Wilson) wrote:
...
It could easily be generated in radiation belts around
the whole binary system. That might act as a local EM reference frame

You still haven't learned what "reference frame" means.

Don't be silly George. I am using the term loosely here.

You are using it completely wrongly here.

The actual reference frame is that of the barycentre. I'm saying there is
a
surrounding 'field' of some description that is virtually at rest wrt the
barycentre and which tends to unify the speed of all light inside the
region to
'c' WRT the region. I say 'tends to' becuase its effect must obviously
taper
off with distance from the centre.
When I said the field 'constitutes a local reference frame' I mean 'the
field
defines the same frame as the barycentre' and can be used as a reference
for
light speed. It is just as legitimate to say 'speed wrt the barycentre' as
'speed wrt the field'. They have the same meaning.

Utter garbage. You say later:

The origin of this frame is the barycentre of the pair.

The origin of a frame is whatever origin you use
for the measured values.

I didn't mean 'origin' as in 0,0 on a graph.

That's essentially what "reference frame" means, though it
doesn't imply a specific style of graph paper. It means
nothing more than the refernce point for measurements.

Oh Dear! ...and I thought I had been conversing with somebody who was a little
more intelligent than the others....

Have another think George.

I meant the frame owes its existence to the fact that there is a definable
centre of mass for the whole system.

No, a frame owes its existence to the fact that someone
has decided to choose a particular reference point for
his graph paper.

Load of crap George.
A frame is not a POINT.
A frame is everything at rest wrt a defined point....All frames are infinite.

and unify
the emitted light speeds.

We are assuming its speed wrt Earth varies between about c+/-
0.00009.

No, we are taking as a given that the time between
pulse arrivals varies by about 90 parts per million.
Some of that variation is due to the velocity but
some will be due to c+v pulses catching up to c-v
pulses a little in the time before extinction
equalises their speeds.

...and that results in exactly the same doppler shift as your own model.

What do you mean by my "own model", SR or my
corrections to your Ritzian version?

SR.

The only basic difference is that for small values of v, one uses the
equation
(c+v)/c and the other c/(c-v).

No, both those are for sound or a Galilean aether. For
SR the formula is sqrt((c+v)/(c-v)) as confirmed by Ives
and Stilwell.

If frequency f is transmitted and received as f' then:

f'/f = (c+v)/c

Define df = f' - f

df/f = v/c

For v c both c/(c-v) and sqrt((c+v)/(c-v)) give the
same expression with slight differences in the second
order part. Hence publications use a simple convention
when changing Doppler to radial speed: v/c = df/f
That's what you need to do in your program.

My program is correct...and I don't predict speeds, I use the published
figures.
The doppler equations for BaTh, LET and SR are virtually identical for small v.

I am suggesting you only need to calculate t = vR/c^2
for the value of v at each point rather than your
iterative sum at each point.

Sorry, I'm not with you.
What's R? It has dimensions of length.
I can't see an extinction RATE anywhere there.

The rate would be a function of time so as an exponential
it would include exp(-t/T) where T is some constant. The
speed difference would fall to 1/e or 37% in time T.



As a function of distance the term is exp(-t/R) where
R is the distance travelled in time T. Again the speed
difference would fall to 1/e or 37% in distance R.

Using Time or length is virtually the same anyway. I use length for my xrate.

I don't think the exponential approach is workable because the integral is
definite.
My series solution is far better.



George I think we are talking about different things again.

I'll explain what the two curves represent.
The blue one is the true c+v lightspeed wrt a flat plane normal to the
observer
LOS and close to the source. (We can ignore travel time across the orbit).

It is the true velocity at that time so "travel time across the
orbit" doesn't come into it, but yes we both understand what the
curve represents.

The program assumes that hypothetical pulses of equal brightness are
emitted at
regular time intervals by the source as it orbits. At the observer
distance,
these pulses arrive in different concentrations, due to bunching.

Again we both understand that. Now what the red curve is supposed
to be is the "observed source velocity". I put that in quotes
because we cannot actually measure the source velocity directly
so what is done is the recedived pulse rate is published as a
velocity by applying the convention v/c = df/f. Your program
calculates the concentration of the pulses so all you need to do
is scale that as velocity and display it as the red curve.

No you are missing the point entirely. Forget pulsars for a minute. In BaTh,
the pulse concentration is NOT a simple doppler effect. There is NO doppler
shift at the source. The 'colour' of the light in the pulses DOES NOT change no
matter how the pulses 'bunch' together.
My program averages the 'source colour' of the light that arrives in a certain
time interval. It uses that to produce the red curve.

You are using the classical approach to claim that the two 'ends' of a photon
will move at different speeds when and if emitted while their source is
accelerating. You claim the ends will continue to move relatively are they
travel. ...and end up with the same doppler pattern as the 'pulse bunching'.
So for a photon to catch another, its rear end would catch its front, giving it
zero length. (for constant aceleration, anyway)

I say the 'length' of each emitted photon IS affected by the source's
acceleration but that this ABSOLUTE length does not continue to change during
inertial travel.
I say it is as though a minute rigid rod connects each 'intrinsic wavecrest' of
a photon. The lengths of those 'rods' will change only during an acceleration
of the photon.


The program divides the orbit period into 500 equal time intervals and
counts
the number of pulses that arrive at the observer in each interval. This is
a
direct indicator of apparent brightness variation.

It is also the value that is used to work out the velocity in
actual observations.

Nah. It doesn't work like that.

The red curve is derived by averaging the true SOURCE velocities of all
the
pulses that arrive in each particular interval.

That is where your error lies.

George, as a matter of interest I might investigate your claim further. It
could only work for fairly small magnitude changes but might actually provide
some interesting results.
It would mean generally that observed velocities are much greater than the true
ones. It might even explain why my predicted distances are always shorter then
the official ones.
If this is true and I don't need much 'unification' at all, then it will
provide almost unassailable proof that the BaTh is correct.

But I'm not very optimistic that it will....

The maximum of the blue curve
is c+v. So the maximum of the red curve can never be higher than that.

Yes it can, the bunching due to acceleration causes a false
velocity to be calculated using v/c = df/f which can produce
significantly higher values.

Certainly there are points on the red curve that are higher than those of
the
blue at the same phase....but that's not the issue.

It is actually, the acceleration part is 90 degrees out of
phase with the velocity (more complex for an elliptical
orbit) and the observed phase is a mix of the two. That's
what we want to predict which is why you need to correct
your calculation.

You might be sorry you talked me into investigating this...

George



"When a true genius appears in the world, you may know
him by this sign, that the dunces are all in confederacy against him."
--Jonathan Swift.