On 16 Mar, 02:33, HW@....(Henri Wilson) wrote:
On Fri, 16 Mar 2007 00:18:00 -0000, "George Dishman" wrote:
"Henri Wilson" HW@.... wrote in message
.. .
On 15 Mar 2007 01:26:03 -0700, "George Dishman"

Nope, that would be of no use at all. Consider a simple
circular orbit of the pulsar P around the barycentre B
as seen by an observer O very far away (not to scale):

B

P x P' O

| |
|- D -|

Light from the two locations P and P' would be launched
with the same speed towards the observer, c' = c+0.7v,
because I've drawn them at 45 degrees to the LoS. The
light from P would be expected to take D/c' longer to
reach us.

That's a strange drawing George.
The barycentre should be where x is.
Anyway I know what you mean.

I don't think you do. Let me add the location of the
companion dwarf as C and draw the two situations
separately. Here's the first:

C

B

P O

The companion is lighter so it's farther from B. Here
is the second situation quarter of an orbit later:

C

B

P O

Of course the observer sholud be farr off to the
right of your screen

Oh all right. I thought you were trying to draw something else.
Same result anyway.
....
Point x is midway between P and P' where the light path
is perpendicular to line x-B. In ballistic theory the
gravity of the star accelerates the light between P and
x and then slows it between x and P' so that the speed
at P' is the same as light emitted at P'. Everything
from there to O is the same. The time it takes the light
to get from P to P' is therefore slightly _less_ than
D/c' because the mean speed is slightly higher than c'.
The Shapiro effect is the difference between that time
and D/c'.

Yes I'm aware of this. The average speed is faster than c' between P and
P'.

Right so the signal arrives earlier, it is not a delay.
The gravitational redshift is identical in each case as
is the eventual speed.

that's right.

OK, now we have cleared that up, if you plot the
alteration of arrival time as a function of the
phase, you will find it peaks when the source is
behins the companion and the relative width of the
peak depends on the inclination of the orbit. There
will be no effect for face on and a high narrow peak
for nearly edge on. However, there will be almost no
velocity effect since any increase between P and x
is always matched by a corresponding decrease between
x and P'. That's why we can use it as a reference for
the phase.

Consider a pulsar in an edge-on circular orbit.

Pulses from the near and far sections of the orbit move towards you at c
and that from the edges at c+v and c-v.

Bunching of pulses is a maximum at maximum acceleration, ie., for pulses
emitted from the far section of the orbit. It is minimum for those emitted
at the near, or 'convex' section.

There is also the effect that consecutive pulses from the
edge travel slightly differnt distances to reach us. Those
from the edge where the source is approaching us travel
progressively shorter distances so are slightly bunched by
the velocity while those on th other side travel a little
longer each time so are moved apart.

However, the 'bunched section' moves towards the observer at a slower
speed than does the group of pulses from the edges.

Slower than those from one edge, faster than from the other.

Now, my original method does not take this into account, although the red
velocity curve it generates actually shows the arrival velocities.

The velocities affect the 'y' position but the changed
time of arrival affects the 'x' position. However, any
change in that from one pulse to the next also affects
the _relative_ separation hence looks like a modification
to the velocity.

I cannot yet see how your 'pulses separation' method does NOT include the
VDoppler.

It SHOULD include it but if as you say above your program
does not take this into account, that could explain why it
is missing the VDoppler effect.

I'm working on it. I'll eventually find what's happening.
....
It will be done....but it isn't as simple as one would think.

I can see that your approach might make it tricky. Let
me know when you crack it.

George