|
|
John C. Polasek wrote:
> On 31 May 2006 03:15:44 -0500, Craig Markwardt
> <craigmnet@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> >
> >John C. Polasek <jpolasek@xxxxxxxxxx> writes:
> >
> >
> >> On 30 May 2006 18:39:23 -0500, Craig Markwardt
> >> <craigmnet@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> >John C. Polasek <jpolasek@xxxxxxxxxx> writes:
> >> >
> >> >
> >> >> On 30 May 2006 14:34:28 -0500, Craig Markwardt
> >> >> <craigmnet@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >> >> >John C. Polasek <jpolasek@xxxxxxxxxx> writes:
> >> >...
> >> >> >> As George said in his note above,
> >> >> >> "The model was initialised in 1987 so at that time fmodel was set
> >> >> >> equal to fobs."
> >> >> >> The computer model clearly was so initialized as to time and
> >> >> >> frequency. You can see there would be no motivationto readjust these.
> >> >> >> ...
> >> >> >
> >> >> >You are incorrect. What was initialized in 1987 was the *trajectory*
> >> >> >model. Each tracking uplink provides a self contained coherent
> >> >> >frequency reference at the time of the session (not 1987). There are
> >> >> >no variables in the solution program which store the frequency as it
> >> >> >was in 1987.
> >> >> If by trajectory you mean the orbital elements were determined in 1987
> >> >> then, fine, but to produce actual ranges and velocities the
> >> >> mathematical model has to include a good value of G to convert planet
> >> >> distance into accelerations, to be integrated into real velocity. Then
> >> >> to convert the velocity to frequency for comparison of Doppler phase
> >> >> slippage, the program had to contain the multiplier f0/c as given in
> >> >> Eq. 1 of Anderson, 10 Mar. 2005:
> >> >[ note incorrect citation ]
> >> >> delta f(t) = f0*(1/c)*dr/dt
> >> >> The conversion of dr/dt to delta f uses f0/c. Are you trying to tell
> >> >> me that on initiation of each 5-day batch, they caused a re-setting of
> >> >> f0 to match the current clock? It does not seem likely. ...
> >> >
> >> >The equation you are citing is one that describes how DSN tracking
> >> >works in generic terms, and does not contain all of the technical
> >> >details. Still, if you had read the attached footnote (#38), you
> >> >would have found that "nu_0" is the "reference frequency." In fact,
> >> >the reference frequency is recorded at the moment of the tracking
> >> >session (it is the frequency standard of the station), and *NOT* in
> >> >1987. (see also eqn 13). It is not reset in "each 5-day batch,"
> >> >because it is recorded in each and every downlink record! [ and
> >> >several times per uplink. ] When will you get it into your head that
> >> >there are no variables in the program that store the "frequency" as of
> >> >1987?
> >> >
> >> >CM
> >> Firstly, #38 explains once again, only that "our frequency/velocity
> >> convention is backwards", a receding craft getting a blue shift that
> >> takes a bit of getting used to, but OK. No information is transmitted
> >> there.
> >
> >Incorrect. As noted above, it defines nu_0.
>
> How tautologically droll. Note #38 says in effect, "let's call the the
> transmitted frequency nu0, OK? and let's call the received frequency
> nu, OK?, and now, pay attention, we will evaluate their difference
> backwards, so don't get mixed up".
> Notice that since Pioneer was a nearly constant 12km/s that nu - nu0
> is approximately 94,000 hz but this delta nu is never discussed in the
> literature.
That's because the signal is received here on Earth and
the speed of our planet round the Sun is about 30km/s
so when we are approaching the craft there is a blue
shift corresponding to 18km/s while six months later
there is an overall redshift corresponding to 42km/s.
Even the ~0.4 km/s speed due to the rotation of the
earth is significant.
> It is in fact converted to craft velocity via V = -lambda
> x delta nu.
> (References to Fig. 1 & 2 are in my paper at
> http://www.dualspace.net/uploads/cosmoarxivnu3.pdf
> Fig. 1 is a reproduction of the principle equation regarding Ap and
> Fig. 2 is a plot of the frequency excess over a 7.5 year period
> beginning in Jan. 1987. The span is ~19 AU and the signal time 2.63
> hours.
John, the signal time was never 2.63 hours, the range
varied from about 40 to about 60 (19 AU span) or even
to 70AU for some of the later data, so the signal time
varied from 80 to 120 times 500s.
> The paper derives "little Ap" as a valid metrical anomaly).
>
> If you take the slope in Fig. 2, 1.5 Hz over 7.5 years, and scale it
> to signal time (= 1/25000) then you would get a frequency increment
> that would make the received frequency become 94,000.00006 Hz so the
> beat frequency would be 0.00006Hz. How extract Ap from that?
They can't, that's one reason why we know the anomaly
is far larger than anything cosmological redshift could
produce.
> It takes
> the years to make things observable. JP
>
> >> How is the reference frequency transcribed into the coefficients of
> >> the mathematical computer program? As I pointed out there needs to be
> >> a reliable G and a dependable f0, and of the latter, there was no
> >> motivation in 1987 to assert that f0 is anything but constant.
> >
> >Incorrect. As noted above, the reference frequency is measured during
> >each tracking session.
>
> You have to be specific, reference frequency of what? Of the radar
> transmission? We all know that. It's nu0.
>
> But we are neglecting another reference frequency, nu_87 that is built
> into the model.
As Craig says, there is no such frequency.
> Notice that all computation of Ap has to do with
> nu_observ - nu_model or in other words nu_obs - nu87.
Nope, nu_observed is tha actual observed received frequency
while nu_model is the predicted value of that received frequency
based on nu_0, the actual uplink signal sent pehaps 12 hours
earlier and the modelled speed of the transmitting site, craft and
receiving site in barycentric coordinates.
> The program
> contains a "canned frequency" that is used throughout Fig. 2 to
> determine delta f. JP
No it doesn't.
> >> What I have berought to your attention that is new is f0 increasing
> >> with time as f = f0(1+Ht), and when compared to the static value in
> >> the model, a linearly increasing disprepancy reveals itself.
> >
> >Irrelevant, since there is no "static value in the model."
> >
> >> The values f0 and c have to be in the program with no impetus to
> >> change f0. Of course the ref frequency "is recorded at the moment of
> >> the tracking session". Please clarify: is there a laboratory event
> >> that causes one to change the equation constants?
> >
> >Improper question, since the reference frequency is not a constant.
> >
> >> I am talking about the construction of the model, against which all
> >> these readings are taken. Is f0 a custom value for each shot?
> >
> >Now you seem to be getting it. The uplink, downlink and reference
> >frequencies are all recorded separately (and continuously for the
> >latter two) during each tracking session, and used for analysis.
> >There are *no* frequency "constants" stored from 1987.
>
> The uplink is ftran, your precious reference frequency is a clock used
> to stabilize ftran, they are the same and the downlink is frec. Of
> course these are recorded with each shot.
> But all Ap computations are with respect to another frequency, f87,
No, as Craig says, the calculations were based on the trend
of the quantity (ftran-frec) for each individual measurement.
Bear in mind ftran is at a DSN station on Earth and Earth is
rotating so you have to include the effect of that rotation on
the uplink frequency and that varies minute by minute.
> that has got to be in the computer model in order to convert the
> derived velocities into frequencies, the factor f87/c. JP
George
|
|