Pioneer 10 rx error and tx frequencies?

1)Re error: Craig,you say that the received frequency power in
the FFT diagram is centered on the specific frequency of the
local oscillator frequency that most closely matches in phase and
frequency the received frequency. You say it is by eyeball
estimation about 15 to 20db above the values at other
frequencies.
So, Craig, George, Is it unnecessary to reconcile this error
estimate with the difference between the recieved oscillations of
voltage and the oscillations produced by a local oscillator at a
specifc rms amplitude at the selected frequency made to match
most closely in phase the received oscillations and then modified
in frequency to maintain the close match?
Perhaps so. But what about the degree of correspondence of zero
crossings in the selected in phase local oscillator sequence of
oscillating voltages and the corresponding sequence of zero
crossings in the reduced(intermediate)representation of the
received frequency?
I should think that this would be indicative of the
reliability of the 'detected' frequency and phase given to the
local oscillator and would have some relationship to the 100db
Sig/Noise or whatever indicated FFT frequency with the most
power.??

2)Re transmitted frequency: For the nth time where is the
transmitted frequency or is this just something you make up to
give the predicted Doppler result assuming the speed of light
delay?

3)Re received frequencies.In the tracking data logical record,
item 31 and 32 gives Doppler Count in units of 1000 time the
number of cycles. I gather this corresponds to Craig's Doppler
count which is instead in units of cycles.
What item gives the FSKY minus 2292000000Hz?
4)re p6 of DSN 810-005 Rev.E/202,Rev.A
"The uplink carrier frequency is synthesized with the exciter
...... [at the receiver site] ...The uplink carrier may be either
constant or varied in accord with a tuning plan. In either case,
the phase of the[synthesized] uplink carrier is recorded for use
in the computation of a Doppler effect."
This sounds to me like the transmitted frequency at the
assumed transmission site is simulated at the receiver site and
used in computing the expected frequency.
5)Thus unless it is possible to determine the transmit
frequency at the receiving site it will not be possible to test
the hypothesis that light speed does not extrapolate beyond 1
second(ie beyond r for r/c1). If the transmit frequency at the
receiving site is known to be the same as the transmit frequency
at the assumed site then of course it would be possible to test
this hypothesis.

"ralph sansbury" writes:
1)Re error: Craig,you say that the received frequency power in
the FFT diagram is centered on the specific frequency of the
local oscillator frequency that most closely matches in phase and
frequency the received frequency. You say it is by eyeball
estimation about 15 to 20db above the values at other
frequencies.

No, I did not say that. I said that there was a carrier peak with
some breadth, bracketed by an overall noise level. I did not say
anything about a local oscillator, or phase. The centering of the
peak is merely a plotting convenience.

The FFT is an unbiased method for estimating the signal power at many
frequencies simultaneously, not just a local oscillator frequency.
For purposes of measuring signal strength, the FFT is just fine. For
more detailed radiometric tracking, of course the phase must be
tracked, which is why the cycle counters are used.

So, Craig, George, Is it unnecessary to reconcile this error
estimate with the difference between the recieved oscillations of
voltage and the oscillations produced by a local oscillator at a
specifc rms amplitude at the selected frequency made to match
most closely in phase the received oscillations and then modified
in frequency to maintain the close match?

This is a nonsensical paragraph. The FFT power density spectrum is
not an error estimate, therefore the remainder of your question is
irrelevant. Please keep this straight: the noise level is completely
separate from the modeling error in the tracking analysis.

Perhaps so. But what about the degree of correspondence of zero
crossings in the selected in phase local oscillator sequence of
oscillating voltages and the corresponding sequence of zero
crossings in the reduced(intermediate)representation of the
received frequency?
I should think that this would be indicative of the
reliability of the 'detected' frequency and phase given to the
local oscillator and would have some relationship to the 100db
Sig/Noise or whatever indicated FFT frequency with the most
power.??

The signal to noise level does indeed determine how well the Doppler
cycle count (= phase) can be tracked. But that's nothing new, from a
signal processing perspective. The Doppler cycle count technique does
*not* require an exact correspondence between the reference signal
(the local oscillator) and the received signal. It is the difference
between these two signals which is accumulated in the counter, and
then recorded for later analysis. There is enough information to
reconstruct the received "sky" frequency from that.


2)Re transmitted frequency: For the nth time where is the
transmitted frequency or is this just something you make up to
give the predicted Doppler result assuming the speed of light
delay?

And, for the N+1th time, the transmitted frequencies are recorded and
stored with the Doppler count data as special "ramp" records, with
timestamps. Again, you appear to be failing to pay attention.


3)Re received frequencies.In the tracking data logical record,
item 31 and 32 gives Doppler Count in units of 1000 time the
number of cycles. I gather this corresponds to Craig's Doppler
count which is instead in units of cycles.
What item gives the FSKY minus 2292000000Hz?

Perhaps it is the output of my own program, which George may have sent
to you. The "sky" frequency is computed in accord with the
recommendations of Moyer (2000), or Morabito & Asmar (1994).
Subtraction of 2.292 GHz is to avoid printing the same digits over and
over again, it's as simple as that.


4)re p6 of DSN 810-005 Rev.E/202,Rev.A
"The uplink carrier frequency is synthesized with the exciter
..... [at the receiver site] ...The uplink carrier may be either
constant or varied in accord with a tuning plan. In either case,
the phase of the[synthesized] uplink carrier is recorded for use
in the computation of a Doppler effect."
This sounds to me like the transmitted frequency at the
assumed transmission site is simulated at the receiver site and
used in computing the expected frequency.

What it sounds to you is irrelevant. Uplink and downlink sessions can
overlap -- but not always -- so it is natural to have a single
reference signal, in this case from the uplink exciter. All of the
Pioneer 10 uplinks were done at a constant transmitter frequency. The
downlinks, on the other hand, will have the Doppler signatures of
earth rotation and spacecraft motion imprinted on them. The uplink
synthesizer cannot mimic these. Indeed, the synthesizer is used only
as a reference frequency for Doppler counting. What the reference
frequency actually is, is irrelevant (as long as it's within the
counter's bandpass).

The comparison to a "predicted" frequency only happens hours, months
or years later when the tracking analysis is performed in software.


5)Thus unless it is possible to determine the transmit
frequency at the receiving site it will not be possible to test
the hypothesis that light speed does not extrapolate beyond 1
second(ie beyond r for r/c1). If the transmit frequency at the
receiving site is known to be the same as the transmit frequency
at the assumed site then of course it would be possible to test
this hypothesis.

The transmitted frequency is determined by solving the light travel
time equations. Fortunately, there is only one solution trajectory
(within an extremely tight confidence region) which agrees with the
data. As I have mentioned several times in the past, changing the
speed of light by even one part in one million ,destroys any possible
solution. Therefore your supposition is completely erroneous.

Your phrase, "transmit frequency at the receiving site" is
nonsensical. *IF* the uplink transmitter is operating at the
receiving site, it would be for the *next* session, not the current
one.

Furthermore, you have been provided with many examples where the
receiving station is completely blocked from the line to the
spacecraft when the uplink occurs, or the transmitting station is
blocked when the downlink occurs. In fact, blockage is far more
common than not.

I am aware that you claim that somehow the transmitter's uplink signal
is misinterpretted as the same station's downlink. But that ignores
some very obvious and fatal issues like: if it were true, how do the
signatures of spacecraft and earth motion get imprinted on the signal?
(they wouldn't) or, how does *ANY* spacecraft telemetry get detected
on the signal? (it wouldn't be) or, what happens when uplink and
downlink are not always overlapping? (your supposition would be
false) or, how could any spacecraft be successfully navigated? (they
couldn't be) And finally, how could the uplink be mistaken as the
downlink when they are separated by over 200 MHz in frequency? (they
couldn't be mistaken) Your supposition is completely and utterly
unfounded.

CM

"Craig Markwardt" wrote in
message news

"ralph sansbury" writes:
1)Re error: Craig,you say that the received frequency power
in
the FFT diagram is centered on the specific frequency of the
local oscillator frequency that most closely matches in phase
and
frequency the received frequency. You say it is by eyeball
estimation about 15 to 20db above the values at other
frequencies.

No, I did not say that. I said that there was a carrier peak
with
some breadth, bracketed by an overall noise level. I did not
say
anything about a local oscillator, or phase. The centering of
the
peak is merely a plotting convenience.

I realize but the whole point of doing this is to obtain a
frequency for the local oscillator
that is an accurate representation of the noisy received signal.
It is certainly not just a plotting convenience.


The FFT is an unbiased method for estimating the signal power
at many
frequencies simultaneously, not just a local oscillator
frequency.


Again I did not say that it wasn't.

For purposes of measuring signal strength, the FFT is just
fine. For
more detailed radiometric tracking, of course the phase must be
tracked, which is why the cycle counters are used.

That is why I said in the first paragraph that the FFT gives
the frequency
that the phase locked loop uses to obtain a local oscillator
frequency
that most closely matches the received noisy oscillations.


So, Craig, George, Is it unnecessary to reconcile this
error
estimate with the difference between the recieved
oscillations of
voltage and the oscillations produced by a local oscillator
at a
specifc rms amplitude at the selected frequency made to match
most closely in phase the received oscillations and then
modified
in frequency to maintain the close match?

This is a nonsensical paragraph. The FFT power density
spectrum is
not an error estimate, therefore the remainder of your question
is
irrelevant. Please keep this straight: the noise level is
completely
separate from the modeling error in the tracking analysis.

But what is the relationship? It sounds like you dont really
know the answer and you dont think it matters. I think it may
matter.


Perhaps so. But what about the degree of correspondence of
zero
crossings in the selected in phase local oscillator sequence
of
oscillating voltages and the corresponding sequence of zero
crossings in the reduced(intermediate)representation of the
received frequency?
I should think that this would be indicative of the
reliability of the 'detected' frequency and phase given to
the
local oscillator and would have some relationship to the
100db
Sig/Noise or whatever indicated FFT frequency with the most
power.??

The signal to noise level does indeed determine how well the
Doppler
cycle count (= phase) can be tracked. But that's nothing new,
from a
signal processing perspective. The Doppler cycle count
technique does
*not* require an exact correspondence between the reference
signal
(the local oscillator) and the received signal. It is the
difference
between these two signals which is accumulated in the counter,

What difference exactly and how is it "accumulated" and what
is
the relation between the degree of correspondence and the
signal/noise
figure and the accuracy in fractions of Hz of the specified
received frequency
as indicated by the local oscillator etc..?

and
then recorded for later analysis. There is enough information
to
reconstruct the received "sky" frequency from that.


2)Re transmitted frequency: For the nth time where is the
transmitted frequency or is this just something you make up
to
give the predicted Doppler result assuming the speed of light
delay?

And, for the N+1th time, the transmitted frequencies are
recorded and
stored with the Doppler count data as special "ramp" records,
with
timestamps. Again, you appear to be failing to pay attention.

Again is this item 112 in the tracking data logical record or
what other item number?



3)Re received frequencies.In the tracking data logical
record,
item 31 and 32 gives Doppler Count in units of 1000 time the
number of cycles. I gather this corresponds to Craig's
Doppler
count which is instead in units of cycles.
What item gives the FSKY minus 2292000000Hz?

Perhaps it is the output of my own program, which George may
have sent
to you. The "sky" frequency is computed in accord with the
recommendations of Moyer (2000), or Morabito & Asmar (1994).
Subtraction of 2.292 GHz is to avoid printing the same digits
over and
over again, it's as simple as that.


Understood. But what item number in the tracking data contains
the FSKY
in your program output?
I am looking at a Pioneer 10 cd with 21 files with a little
gnu c++ program on my laptop
and in the first 266 bytes am getting a lot of binary 00000000
bytes. This should be the file identification record where eg
bits 73 through 84 contain the last two digits of year.(which
should be 87 I think since file is named "87037.dat"
What is going on here?

4)re p6 of DSN 810-005 Rev.E/202,Rev.A
"The uplink carrier frequency is synthesized with the exciter
..... [at the receiver site] ...The uplink carrier may be
either
constant or varied in accord with a tuning plan. In either
case,
the phase of the[synthesized] uplink carrier is recorded for
use
in the computation of a Doppler effect."
This sounds to me like the transmitted frequency at the
assumed transmission site is simulated at the receiver site
and
used in computing the expected frequency.

What it sounds to you is irrelevant. Uplink and downlink
sessions can
overlap -- but not always --

For example and are these the times when there are a lot of
blanks in the received frequencies because of bad weather or
whatever other excuse is used?

so it is natural to have a single
reference signal, in this case from the uplink exciter. All of
the
Pioneer 10 uplinks were done at a constant transmitter
frequency. The
downlinks, on the other hand, will have the Doppler signatures
of
earth rotation and spacecraft motion imprinted on them. The
uplink
synthesizer cannot mimic these. Indeed, the synthesizer is
used only
as a reference frequency for Doppler counting. What the
reference
frequency actually is, is irrelevant (as long as it's within
the
counter's bandpass).

The comparison to a "predicted" frequency only happens hours,
months
or years later when the tracking analysis is performed in
software.


5)Thus unless it is possible to determine the transmit
frequency at the receiving site it will not be possible to
test
the hypothesis that light speed does not extrapolate beyond 1
second(ie beyond r for r/c1). If the transmit frequency at
the
receiving site is known to be the same as the transmit
frequency
at the assumed site then of course it would be possible to
test
this hypothesis.

The transmitted frequency is determined by solving the light
travel
time equations. Fortunately, there is only one solution
trajectory
(within an extremely tight confidence region) which agrees with
the
data. As I have mentioned several times in the past, changing
the
speed of light by even one part in one million ,destroys any
possible
solution.
If your suppositions about the motions of the earth site
and lines
between earth site and the craft at the time of transmission and
the time
of reception/transmission by the craft and the time of reception
by the
earth are correct. And then there are the fudge factors ascribed
to
atmospheric effects, relativity etc..

Therefore your supposition is completely erroneous.



Your phrase, "transmit frequency at the receiving site" is
nonsensical. *IF* the uplink transmitter is operating at the
receiving site, it would be for the *next* session, not the
current
one.
That is the hypothesis that is to be tested.

Furthermore, you have been provided with many examples where
the
receiving station is completely blocked from the line to the
spacecraft when the uplink occurs, or the transmitting station
is
blocked when the downlink occurs. In fact, blockage is far
more
common than not.

1)And the 87 87 and 89 files I have, have
lots of blank data which could account for this.

I am aware that you claim that somehow the transmitter's uplink
signal
is misinterpretted as the same station's downlink. But that
ignores
some very obvious and fatal issues like: if it were true, how
do the
signatures of spacecraft and earth motion get imprinted on the
signal?

2)If by signatures you mean time stamp, the reason is that
the
computer programs in the communication system erroneously assume
speed of light delay for the distance specified from Newtonian
calculations
of position independent of light speed delay.

(they wouldn't) or, how does *ANY* spacecraft telemetry get
detected
on the signal? (it wouldn't be) or, what happens when uplink
and
downlink are not always overlapping? (your supposition would
be
false)



or, how could any spacecraft be successfully navigated?
(they
couldn't be)

3The navigation depends on the Newtonian calculations
primarily
And to the extent erroneous modifications creep they may in
general
be too small to cause problems. But half of all spacecraft have
had
navigation problems.

And finally, how could the uplink be mistaken as
the
downlink when they are separated by over 200 MHz in frequency?
(they
couldn't be mistaken)

4)Your supposition here is nonsensical. The uplink is sent as
before
to the spacecraft where it is multiplied by 240/221 or whatever
and
send back to the receiver on earth two seconds about after the
uplink
was sent.

Your supposition is completely and
utterly
unfounded.

So let's test it.

Ralph

"ralph sansbury" writes:

"Craig Markwardt" wrote in
message news
[ ... ]
This is a nonsensical paragraph. The FFT power density spectrum is
not an error estimate, therefore the remainder of your question is
irrelevant. Please keep this straight: the noise level is completely
separate from the modeling error in the tracking analysis.

But what is the relationship? It sounds like you dont really
know the answer and you dont think it matters. I think it may
matter.

Relationship of what? The power spectrum is not an error estimate,
therefore your question doesn't make sense. The noise level is
controlled by the antenna, amplifiers and earth environment. The
modeling error is controlled by how well the spacecraft dynamics are
modeled in the analysis. They are independent of each other. You are
trying to compare butterflies and balloons.


The signal to noise level does indeed determine how well the Doppler
cycle count (= phase) can be tracked. But that's nothing new, from a
signal processing perspective. The Doppler cycle count technique does
*not* require an exact correspondence between the reference signal
(the local oscillator) and the received signal. It is the difference
between these two signals which is accumulated in the counter,

What difference exactly and how is it "accumulated" and what is
the relation between the degree of correspondence and the signal/noise
figure and the accuracy in fractions of Hz of the specified received frequency
as indicated by the local oscillator etc..?

I'm going to say this one more time. The carrier signal being tracked
is mixed with the reference signal (which is generated by the exciter
for the DSN). The mixed signal has the beat frequency (f_sky minus
f_ref). Dedicated cycle counting equipment counts the number of
integer cycles and fractional cycles (phase) of this beat. If the
signal remains locked, then the frequency accuracy is of order
1/(accumulation time), or a few mHz (= few x 0.001 Hz). Noise can
cause cycle slips (loss of lock), in which case the accumulation time
is the mean time between slips. There are few cycle slips in the
Pioneer data, and they are generally readily detectable as frequency
jumps.

I understand why the uplink exciter is used as the reference. For
many near earth missions, the light travel time is a few seconds or
minutes, so the uplink and downlink can be taken in the same tracking
session. Thus it makes sense to use the uplink as a reference. It
doesn't matter since the record of the reference frequencies is kept,
which allows the sky frequency to be reconstructed.

And, for the N+1th time, the transmitted frequencies are recorded and
stored with the Doppler count data as special "ramp" records, with
timestamps. Again, you appear to be failing to pay attention.
Again is this item 112 in the tracking data logical record or
what other item number?

No, items 113 and 114 in "ramp" records. The "ramp rate" is usually
zero, indicating the uplink frequency was constant with time.

Perhaps it is the output of my own program, which George may have sent
to you. The "sky" frequency is computed in accord with the
recommendations of Moyer (2000), or Morabito & Asmar (1994).
Subtraction of 2.292 GHz is to avoid printing the same digits over and
over again, it's as simple as that.


Understood. But what item number in the tracking data contains
the FSKY
in your program output?

The outputs are labeled. FSKY is derived from the raw telemetry
according to the references I have cited multiple times.


I am looking at a Pioneer 10 cd with 21 files with a little
gnu c++ program on my laptop
and in the first 266 bytes am getting a lot of binary 00000000
bytes. This should be the file identification record where eg
bits 73 through 84 contain the last two digits of year.(which
should be 87 I think since file is named "87037.dat"
What is going on here?

It sounds like you aren't decoding the files correctly yet. The dates
are there.


What it sounds to you is irrelevant. Uplink and downlink sessions can
overlap -- but not always --

For example and are these the times when there are a lot of
blanks in the received frequencies because of bad weather or
whatever other excuse is used?

No. 30% of the overall dataset was taken with successful and
non-overlapping uplinks and downlinks.


The transmitted frequency is determined by solving the light travel
time equations. Fortunately, there is only one solution trajectory
(within an extremely tight confidence region) which agrees with the
data. As I have mentioned several times in the past, changing the
speed of light by even one part in one million ,destroys any possible
solution.
If your suppositions about the motions of the earth site and lines
between earth site and the craft at the time of transmission and the time
of reception/transmission by the craft and the time of reception by the
earth are correct. And then there are the fudge factors ascribed to
atmospheric effects, relativity etc..

Earth rotation parameters are measured directly very precisely by
multiple independent techniques. If the lines between the stations
and the spacecraft were wrong by more than a few degrees, then the
ground antennae would not have detected the signal. As I have said
multiple times, but you have ignored, I have allowed the light
transmission time to change in the analysis, but that has ruined the
solution. I do not apply atmosphereic "fudge factors." The
correction due to relativity are small compared to the anomalous
signal (0.075 Hz vs 2-3 Hz), and exactly computable, therefore is not
a fudge factor. Thus, each of your claims are unsubstantiated.



Furthermore, you have been provided with many examples where
the
receiving station is completely blocked from the line to the
spacecraft when the uplink occurs, or the transmitting station
is
blocked when the downlink occurs. In fact, blockage is far
more
common than not.

1)And the 87 87 and 89 files I have, have
lots of blank data which could account for this.

Your software produces lots of erroneous blanks, and thus do not
account for anything.


I am aware that you claim that somehow the transmitter's uplink
signal
is misinterpretted as the same station's downlink. But that
ignores
some very obvious and fatal issues like: if it were true, how
do the
signatures of spacecraft and earth motion get imprinted on the
signal?

2)If by signatures you mean time stamp, the reason is that
the
computer programs in the communication system erroneously assume
speed of light delay for the distance specified from Newtonian
calculations
of position independent of light speed delay.

No, by "signature" I meant, the frequency signature that could only be
imprinted on the signal by certain earth and spacecraft motions.
Ignoring all the other obvious problems with your supposition: if the
light propagation equation *were* wrong, then the receiving station
would be at a longitude completely inconsistent with the data. PLUS,
the earth's orbital velocity would be different. Both of these
effects are comparable (0.25 - 0.5 km/s), and 100,000 times larger
than the 4 mHz residual levels I measured.

And finally, the computer systems do not need to "assume" the speed of
light delay. If the reference frequency is anywhere within 1 MHz
(100 km/s) of the downlink, it is possible to do Doppler tracking.
This is true for any spacecraft in the solar system. Of course, the
DSN folks know what they are doing, and get much closer than this.


3The navigation depends on the Newtonian calculations
primarily
And to the extent erroneous modifications creep they may in
general
be too small to cause problems.

Incorrect. See above. Failing to account for light travel time
introduces huge errors, of order 0.25 to 0.5 km/s.


But half of all spacecraft have had navigation problems.

Name one spacecraft where a navigation problem was caused by incorrect
modeling of Doppler tracking data.

CM

Craig. Lets not argue about light speed.
Where is it stated what the transmit frequency is?
What item number?
Are items 31 and 32 the number from which the received frequency
is derived?
I gather this is the beat frequency or difference frequency or
intermediate frequency reached
after several steps ie a sequence of analogue or digital voltage
values.
The integer cycles are just zero crossings or rather every other
zero crossing
here eg as the voltage values change from minus to negative with
respect to a mean
zero. I dont understand what is meant by fractional cycles or why
the units are in
Hz times 10000. I gather also that even these units must be
divided by 256 to get
the actual frequency. Is this correct?
My program shows that all of the bytes up to 277 and 278 are
00000000
which are written out also as ASCII blanks. (But you say that
only 70 percent
of the data is blank or not usefull for one reason or another.) I
really would
like to get a look at the raw data if there is any. Am beginning
to doubt it.
Could I have your cooperation in this?

Here is the code I used to see what
was in item 3, byte 10 and the four high order bits of byte 11 ec
of the first 263 byte logical record etc for the next logical
record.


icnt=0;while(icnt279)
{
AA.get(w);u=w;icnt=icnt+1;
if(9icnt12||276icnt278)cout icnt;j=0;int t,j,ch[8],u; char
w;
for(t=128; t0; t=t/2)
{if(u&t) ch[j]=1; else ch[j]=0;j=j+1;}
for (j=0;j8; j=j+1) cout ch[j];
cout "w is" w"next byte is";


"Craig Markwardt" wrote in
message news

"ralph sansbury" writes:

"Craig Markwardt"
wrote in
message news

Relationship of what? The power spectrum is not an error
estimate,
therefore your question doesn't make sense. The noise level is
controlled by the antenna, amplifiers and earth environment.
The
modeling error is controlled by how well the spacecraft
dynamics are
modeled in the analysis. They are independent of each other.
You are
trying to compare butterflies and balloons.

The power spectrum of pure noise with equal power
roughly over all frequencies would be different presumably
than the power spectrum you get here of a received frequency plus
noise
that would be different from the power spectrum of a pure version
of
the received frequency. Thus the power spectrum gives an
indication of
the modelling error involving a selected frequency.
The modelling error is the difference between the predicted
voltage
values over time and the actual received voltage values over
time.
Now if the predicted voltage values given by a sine function of
a specific frequency and phase starting at the beginning of a
specific
time interval have a smaller error sum of squares for this model
than the sum of squared differences between the voltage values
and
their (zero)mean then you can say that the model is reliable and
that
the control of error by the antenna etc has been adequate.
So now hopefully you see how there might be a relationship
between
this chi square ratio and your 20 to 15 db eyeball estimate of
the signal noise ratio of the selected frequency in the power
spectrum.




What difference exactly and how is it "accumulated" and
what is
the relation between the degree of correspondence and the
signal/noise
figure and the accuracy in fractions of Hz of the specified
received frequency
as indicated by the local oscillator etc..?

I'm going to say this one more time. The carrier signal being
tracked
is mixed with the reference signal (which is generated by the
exciter
for the DSN). The mixed signal has the beat frequency (f_sky
minus
f_ref). Dedicated cycle counting equipment counts the number
of
integer cycles and fractional cycles (phase) of this beat.

Thanks for being so patient.
The beat frequency or difference frequency or intermediate
frequency reached
after several steps is a sequence of analogue or digital voltage
values.
The integer cycles are just zero crossings or rather every other
zero crossing
eg as the voltage values change from minus to negative with
respect to a mean
zero.


If the
signal remains locked, then the frequency accuracy is of order
1/(accumulation time), or a few mHz (= few x 0.001 Hz).

So if the intermediate frequency doesn't change for 1000
seconds
then you say the frequency accuracy is .001 Hz.
But what about the accuracy in the normative sense
that the received frequency,
or this intermediate representation of the received frequency,
is sometimes zero at different times than the local oscillator
whose
frequency and phase are fine tuned to most closely match this
intermediate
frequency?
If for example half of the time there was no correspondence
between the
predicted frequency zeros and the observed frequency zeros then
the
accuracy would be 2.292 GHz plus or minus 1 GHz.


Noise can
cause cycle slips (loss of lock), in which case the
accumulation time
is the mean time between slips. There are few cycle slips in
the
Pioneer data, and they are generally readily detectable as
frequency
jumps.

I understand why the uplink exciter is used as the reference.
For
many near earth missions, the light travel time is a few
seconds or
minutes, so the uplink and downlink can be taken in the same
tracking
session. Thus it makes sense to use the uplink as a reference.
It
doesn't matter since the record of the reference frequencies is
kept,
which allows the sky frequency to be reconstructed.

No, items 113 and 114 in "ramp" records. The "ramp rate" is
usually
zero, indicating the uplink frequency was constant with time.

Perhaps it is the output of my own program, which George
may have sent
to you. The "sky" frequency is computed in accord with the
recommendations of Moyer (2000), or Morabito & Asmar
(1994).
Subtraction of 2.292 GHz is to avoid printing the same
digits over and
over again, it's as simple as that.


Understood. But what item number in the tracking data
contains
the FSKY
in your program output?

The outputs are labeled. FSKY is derived from the raw
telemetry
according to the references I have cited multiple times.


I am looking at a Pioneer 10 cd with 21 files with a
little
gnu c++ program on my laptop
and in the first 266 bytes am getting a lot of binary
00000000
bytes. This should be the file identification record where eg
bits 73 through 84 contain the last two digits of year.(which
should be 87 I think since file is named "87037.dat"
What is going on here?

It sounds like you aren't decoding the files correctly yet.
The dates
are there.

No they aren't. I am not decoding just reading binary
I am just reading successive bytes and the first 263 bytes
are zeros. This procedure works with other files why not
with this cd?


What it sounds to you is irrelevant. Uplink and downlink
sessions can
overlap -- but not always --

For example and are these the times when there are a lot of
blanks in the received frequencies because of bad weather or
whatever other excuse is used?

No. 30% of the overall dataset was taken with successful and
non-overlapping uplinks and downlinks.

In other words yes. 70% !!!!! of the data is considered
USELESSbecause
it does not conform to the speed of light delay assumptions!!!!!


The transmitted frequency is determined by solving the
light travel
time equations. Fortunately, there is only one solution
trajectory
(within an extremely tight confidence region) which agrees
with the
data. As I have mentioned several times in the past,
changing the
speed of light by even one part in one million ,destroys
any possible
solution.

You mean you have to get rid of data which does not somehow
in any
way possible confirm the politically correct view.


If your suppositions about the motions of the earth
site and lines
between earth site and the craft at the time of transmission
and the time
of reception/transmission by the craft and the time of
reception by the
earth are correct. And then there are the fudge factors
ascribed to
atmospheric effects, relativity etc..

Earth rotation parameters are measured directly very precisely
by
multiple independent techniques. If the lines between the
stations
and the spacecraft were wrong by more than a few degrees, then
the
ground antennae would not have detected the signal.

Nonsense. The antenna is moved until it picks up the signal
and is moved to maintain conact. This is done when transmission
occurs over the same scheduled time that reception occurs and
the received signal at this time could be due this just prior
transmission
and wrongly interpreted as due to transmission from another
station
hours before. And then of course 70 percent of the data is thrown
out
when it does not match the speed of light delay assumptions.

As I have said
multiple times, but you have ignored, I have allowed the light
transmission time to change in the analysis, but that has
ruined the
solution. I do not apply atmosphereic "fudge factors." The
correction due to relativity are small compared to the
anomalous
signal (0.075 Hz vs 2-3 Hz), and exactly computable, therefore
is not
a fudge factor. Thus, each of your claims are unsubstantiated.



Furthermore, you have been provided with many examples
where
the
receiving station is completely blocked from the line to
the
spacecraft when the uplink occurs, or the transmitting
station
is
blocked when the downlink occurs. In fact, blockage is far
more
common than not.

1)And the 87 87 and 89 files I have, have
lots of blank data which could account for this.

Your software produces lots of erroneous blanks, and thus do
not
account for anything.
My software works on other files so why not here?


I am aware that you claim that somehow the transmitter's
uplink
signal
is misinterpretted as the same station's downlink. But
that
ignores
some very obvious and fatal issues like: if it were true,
how
do the
signatures of spacecraft and earth motion get imprinted on
the
signal?

2)If by signatures you mean time stamp, the reason is
that
the
computer programs in the communication system erroneously
assume
speed of light delay for the distance specified from
Newtonian
calculations
of position independent of light speed delay.

No, by "signature" I meant, the frequency signature that could
only be
imprinted on the signal by certain earth and spacecraft
motions.

The signature would be similar in many cases and in those
that
are different perhaps these are among the 70 percent of rejected
data.


Ignoring all the other obvious problems with your supposition:
if the
light propagation equation *were* wrong, then the receiving
station
would be at a longitude completely inconsistent with the data.
PLUS,
the earth's orbital velocity would be different. Both of these
effects are comparable (0.25 - 0.5 km/s), and 100,000 times
larger
than the 4 mHz residual levels I measured.

But how do I know you dont throw out any data that
doesn't conform to this and probably change
the transmit frequency which is nowhere indicated in the data?


And finally, the computer systems do not need to "assume" the
speed of
light delay. If the reference frequency is anywhere within 1
MHz
(100 km/s) of the downlink, it is possible to do Doppler
tracking.

I was talking about the navigation and operation commands and
data received not just the Doppler.



3The navigation depends on the Newtonian calculations
primarily
And to the extent erroneous modifications creep they may in
general
be too small to cause problems.

I
But half of all spacecraft have had navigation problems.

Name one spacecraft where a navigation problem was caused by
incorrect
modeling of Doppler tracking data.

The data is not readily available for obvious reasons. .

CM

"ralph sansbury" writes:
Where is it stated what the transmit frequency is?
What item number?

I've answered you multiple times. You ignore. It's also documented
in TRK 2-25.

Are items 31 and 32 the number from which the received frequency
is derived?

Yes, but the fields are in cycle counts. This is documented, and has
been discussed multiple times.

I dont understand what is meant by fractional cycles or why
the units are in
Hz times 10000.

They are not in units of Hz times 10000, and this is documented. If
you don't understand fractional cycles, then you have a problem.

My program shows that all of the bytes up to 277 and 278 are
00000000

Your program is wrong.

of the first 263 byte logical record etc for the next logical
record.

The logical records are not 263 bytes. However, some but not all of
the physical blocks recovered by NSSDC have an extra byte attached
(i.e. 8065 instead of 8064 bytes). This does not affect the first 28
logical records.


The power spectrum of pure noise with equal power
roughly over all frequencies would be different presumably
than the power spectrum you get here of a received frequency plus
noise
that would be different from the power spectrum of a pure version
of
the received frequency. Thus the power spectrum gives an
indication of
the modelling error involving a selected frequency.

No. The noise gives a measure of how well the signal can be detected,
and has nothing to do with how well the tracking solution is modeled.

The modelling error is the difference between the predicted
voltage
values over time and the actual received voltage values over
time.

No. The modeling error is the difference between the received and
predicted frequencies (not voltages), and can only be assessed in the
full analysis. It has nothing to do with the DSN tracking session.


If the
signal remains locked, then the frequency accuracy is of order
1/(accumulation time), or a few mHz (= few x 0.001 Hz).

So if the intermediate frequency doesn't change for 1000
seconds
then you say the frequency accuracy is .001 Hz.

I did not say that.

But what about the accuracy in the normative sense
that the received frequency,
or this intermediate representation of the received frequency,
is sometimes zero at different times than the local oscillator
whose
frequency and phase are fine tuned to most closely match this
intermediate
frequency?

If the carrier signal is locked in, your question is irrelevant.

If for example half of the time there was no correspondence
between the
predicted frequency zeros and the observed frequency zeros then
the
accuracy would be 2.292 GHz plus or minus 1 GHz.

The situation you describe is all-noise: the signal wouldn't have been
locked into the control loop, nor would telemetry have been received.
This is obviously not the case.


No. 30% of the overall dataset was taken with successful and
non-overlapping uplinks and downlinks.

In other words yes. 70% !!!!! of the data is considered
USELESSbecause
it does not conform to the speed of light delay assumptions!!!!!

I did not say that. Read carefully. 30% of the overall dataset was
taken successfully with non-overlapping uplinks and downlinks.
**70%** of the overall data set was taken **successfully** with
overlapping uplinks and downlinks. There was no analysis difference
between the non-overlapping or overlapping sets of data.


You mean you have to get rid of data which does not somehow in any
way possible confirm the politically correct view.

No.


1)And the 87 87 and 89 files I have, have
lots of blank data which could account for this.

Your software produces lots of erroneous blanks, and thus do not
account for anything.
My software works on other files so why not here?

Because you probably have one or more software bugs.


No, by "signature" I meant, the frequency signature that could only be
imprinted on the signal by certain earth and spacecraft motions.

The signature would be similar in many cases and in those that
are different perhaps these are among the 70 percent of rejected data.

No. 70% was not rejected. And, the signature would not be similar,
as the errors would be ~0.5 km/s = HUGE.


But how do I know you dont throw out any data that
doesn't conform to this and probably change
the transmit frequency which is nowhere indicated in the data?

You can know because I say: I didn't discard data based on light
travel time selections. I accepted all coherent tracking
sessions. The transmitter frequencies are stored in the data -- and
this is documented. You repeatedly ignore. I did not "change" any
transmitter frequencies. At this stage, I don't particularly care if
you take my word for it or not.


But half of all spacecraft have had navigation problems.

Name one spacecraft where a navigation problem was caused by incorrect
modeling of Doppler tracking data.

The data is not readily available for obvious reasons. .

So your claims are unsubstantiated, and therefore irrelevant.


You continue to fail to read what's presented to you. You fail to
consult the essential primary references or the documentation. You
ignore straightforward comments. You repeatedly ask questions that
have been answered. You offer unsubstantiated speculations. You
don't appear to have understood any of the basic signal processing
issues. In short, you don't appear to be learning, and I can't
justify spending more of my time on this thread.

CM

"Craig Markwardt" wrote in
message news

"ralph sansbury" writes:
Where is it stated what the transmit frequency is?
What item number?

I've answered you multiple times. You ignore. It's also
documented
in TRK 2-25.

But then when I say what I think it is you or George tell me
something else. This is a very awkward form of communication and
it makes me just as irritable as it makes you.
I gather then that items 31 and 32 contain the doppler count
from which the received frequency is derived,
and that items 113 and 114 contain a number from which the
transmitter frequency can be derived. This and items 3 through
10 with date time craft id and station id are the numbers I would
like to look at without the filters that you applied, to remove
incompletely filled in data or received frequencies that were
outside the expected range.
It is this last filter that concerns me since it might remove
values that were inside the expected range if my contention is
correct. Namely that the received frequency was obtained from a
transmission seconds earlier to the spacecraft which increased
the frequency in phase and sent it back to the same site.
Lets not debate this anymore now. If and when I get this
data for 1987 and 1988 I could produce a spreadsheet that would
show that the
observed doppler shift is more accurately or just as accurately
predicted according to the few second delay as that predicted
according to the assumption that the speed of light delay
extrapolates beyond a second which for the 1987 and 1988 data
would involve about an hour delay.
But the cd copies of the tapes which I guess you have
access to have problems or at least the copy nasa sent me.
The cd that nasa sent me has data on it that does not
correspond to the TRK-2-25 documentation.
I did a hexadecimal dump of the first file.
The first 32 bits of file "87037.dat" are zero and the next
eight bits are 3F=0011 1111.That is the next 4 bits are decimal
3. According to TRK documentation the first 36 bits contain
"data length =8" whereas this suggests the value is 3 instead of
8. This is also true for file "89200.dat"
The bits 37-40 then are 1111 and the next 32 bits are
hex 25 = 00100101 which is decimal 37 when TRK says it should be
10. Similarly for file "89200.dat".
The tenth byte and next 4 bits of the 11th byte should
contain the
last two digits of the year but they dont.

But what about the accuracy in the normative sense
that the received frequency,
or this intermediate representation of the received
frequency,
is sometimes zero at different times than the local
oscillator
whose
frequency and phase are fine tuned to most closely match this
intermediate
frequency?

If the carrier signal is locked in, your question is
irrelevant.
Not according to George: the local oscillator in the phase
locked loop does not produce an exact match of
the intermediate oscillation version of the received
oscillation. Rather it produces a similar oscillation where
the rising crossings of zero dont always match but
on average


If for example half of the time there was no
correspondence
between the
predicted frequency zeros and the observed frequency zeros
then
the
accuracy would be 2.292 GHz plus or minus 1 GHz.

The situation you describe is all-noise: the signal wouldn't
have been
locked into the control loop, nor would telemetry have been
received.
This is obviously not the case.


What are your reasons. I am interested in your reasons not
opinions without any support.


I did not say that. Read carefully. 30% of the overall
dataset was
taken successfully with non-overlapping uplinks and downlinks.
**70%** of the overall data set was taken **successfully** with
overlapping uplinks and downlinks. There was no analysis
difference
between the non-overlapping or overlapping sets of data.


What do you mean by overlapping uplinks and downlinks.?
Do you mean that the assumed time of downlink occurred at the
same time as an uplink but not at a later time when the downlink
from this uplink was expected?

This sounds to me like you are getting rid of otherwise good
data which does not
somehow in any way possible confirm the politically correct
view.

No.

Apparently unless you have a logical explanation.


1)And the 87 87 and 89 files I have, have
lots of blank data which could account for this.

Your software produces lots of erroneous blanks, and thus
do not
account for anything.
My software works on other files so why not here?

Because you probably have one or more software bugs.

I have tried it with other computers and software and there are
still problems. The cds I have are bad unless you have another
explantion.


No, by "signature" I meant, the frequency signature that
could only be
imprinted on the signal by certain earth and spacecraft
motions.

The signature would be similar in many cases and in those
that
are different perhaps these are among the 70 percent of
rejected data.


Yes they were as you admitted above.

No. 70% was not rejected.
You suggested that it was because there was overlapping.

And, the signature would not be
similar,
as the errors would be ~0.5 km/s = HUGE.

The spin motion of the earth could be similar in some cases
and in cases when it wasn't you would have rejected the data
because it was overlapping or for some other reason



But how do I know you dont throw out any data that
doesn't conform to this and probably change
the transmit frequency which is nowhere indicated in the
data?

You can know because I say: I didn't discard data based on
light
travel time selections. I accepted all coherent tracking
sessions.
What do you mean by incoherent tracking sessions. This is
just jargon for rejecting data not conistent with light travel
time assumptions.

The transmitter frequencies are stored in the data --
and
this is documented.

I see the assumed transmitter frequency which you said was
constant and which in your filter files that I have seen is
always the same although you also say that it can change.??
What do you mean by incoherent tracking as a basis for
rejection of some of the data?

You repeatedly ignore. I did not "change"

any
transmitter frequencies.

I accept your word on that but I am concerned about the
filtered received frequencies.


George and Craig, The point I am trying to make here is that
different frequency functions may fit the received periodic
waveform regarded as noise plus a specific doppler shifted
version of the know uplink frequency.
That is even though the best fit is given by the phase locked
loop local oscillator frequency etc., various nearby frequencies
alone or in conjunction with some harmonics could in fact be the
true received periodic oscillation..
That is,various frequencies around the power spectrum
frequency range with the most power could be the true frequency
etc..

Ralph

"ralph sansbury" writes:
But the cd copies of the tapes which I guess you have
access to have problems or at least the copy nasa sent me.
The cd that nasa sent me has data on it that does not
correspond to the TRK-2-25 documentation.
I did a hexadecimal dump of the first file.
The first 32 bits of file "87037.dat" are zero and the next
eight bits are 3F=0011 1111.That is the next 4 bits are decimal

Given the garbled and fragmentary nature of the program you posted, it
is likely that you have a software bug. The ATDF files I have are
identical to those available on-line for download at NSSDC. (example:
87037t071.dat = 9209088 bytes). A hex byte dump of the first 16 bytes
is:

00 00 00 00 80 00 00 00 0a 05 70 05 b1 10 12 14,

exactly as expected.



Not according to George: the local oscillator in the phase
locked loop does not produce an exact match of
the intermediate oscillation version of the received
oscillation. Rather it produces a similar oscillation where
the rising crossings of zero dont always match but
on average

If it is locked in, the loop must detect every cycle. That is the
very definition of "locked." Your requirement of an "exact" match is
irrelevant to that definition. Your scenario of 50% missed cycles is
clearly out of lock. With the system used, telemetry can't be
received until the loop has locked onto the carrier.



I did not say that. Read carefully. 30% of the overall
dataset was
taken successfully with non-overlapping uplinks and downlinks.
**70%** of the overall data set was taken **successfully** with
overlapping uplinks and downlinks. There was no analysis
difference
between the non-overlapping or overlapping sets of data.


What do you mean by overlapping uplinks and downlinks.?
Do you mean that the assumed time of downlink occurred at the
same time as an uplink but not at a later time when the downlink
from this uplink was expected?

This sounds to me like you are getting rid of otherwise good
data which does not
somehow in any way possible confirm the politically correct
view.

I will say this once more. There were cases where uplink sessions
overlapped in time with downlink sessions, and other cases where there
was no overlap. I analyzed all of this data together, without regard
to the overlap, and the results were entirely consistent. "Overlap"
is a description of whether uplink and downlink activities were
happening at the same time or not, period. Absolute uplink and
downlink epochs are not "assumed," they are measured precisely.

Nowhere did I say I got rid of data because of overlapping sessions,
because in fact I kept it.



What do you mean by incoherent tracking sessions. This is
just jargon for rejecting data not conistent with light travel
time assumptions.

No. Non-coherent sessions happen when the spacecraft uses its own
oscillator, which is susceptible to temperature induced drifts. These
types of sessions are useless for radiometric tracking because the
clock drift cannot be disentangled from any Doppler-induced frequency
drift.


I see the assumed transmitter frequency which you said was
constant and which in your filter files that I have seen is
always the same although you also say that it can change.??

The uplink frequency can be ramped, but wasn't. The uplink frequency
was constant for each session.

George and Craig, The point I am trying to make here is that
different frequency functions may fit the received periodic
waveform regarded as noise plus a specific doppler shifted
version of the know uplink frequency.

The waveform is sinusoidal, so your point is irrelevant.

That is even though the best fit is given by the phase locked
loop local oscillator frequency etc., various nearby frequencies
alone or in conjunction with some harmonics could in fact be the
true received periodic oscillation..

Which frequencies or harmonics? How can harmonics be "nearby?" (they
cannot) Can you provide (even) a single example? All of the downlink
power spectra I have seen have been flat except for one peak.


CM

"ralph sansbury" wrote in message
...

So if the intermediate frequency doesn't change for 1000 seconds
then you say the frequency accuracy is .001 Hz.
But what about the accuracy in the normative sense that the received
frequency,
or this intermediate representation of the received frequency,
is sometimes zero at different times than the local oscillator whose
frequency and phase are fine tuned to most closely match this intermediate
frequency?
If for example half of the time there was no correspondence between the
predicted frequency zeros and the observed frequency zeros then the
accuracy would be 2.292 GHz plus or minus 1 GHz.

If the PLL is in lock then there are exactly the same number
of zero crossings in the actual signal and the LO signal in a
33 minute period. However, each zero crossing of the LO might
be slightly earlier or later than the corresponding event in
the actual signal by a fraction of a cycle.

George

"Craig Markwardt" wrote in
message news

"ralph sansbury" writes:
But the cd copies of the tapes which I guess you have
access to have problems or at least the copy nasa sent me.
The cd that nasa sent me has data on it that does not
correspond to the TRK-2-25 documentation.
I did a hexadecimal dump of the first file.
The first 32 bits of file "87037.dat" are zero and the next
eight bits are 3F=0011 1111.That is the next 4 bits are
decimal

Given the garbled and fragmentary nature of the program you
posted, it
is likely that you have a software bug.

As I said that was the program used to get the dump.

The ATDF files I have are
identical to those available on-line for download at NSSDC.
(example:
87037t071.dat = 9209088 bytes). A hex byte dump of the first
16 bytes
is:

00 00 00 00 80 00 00 00 0a 05 70 05 b1 10 12 14,

exactly as expected.

In your notes you say you obtained this directly from the tape so
it may be that in transferring the tape bytes to the cd that
something happens to produce 3F instead of 80 etc.
The point is I would like to obtain the data you obtained and
before you filtered it and I would like a program and compiler to
read it.
Or better yet just use your programs to extract from the
tapes the unfiltered received doppler counter number and the
date and time for 87 and 88 as integers or ansi characters
suitable for input to an excel spreadsheet and send me the cd.



Not according to George: the local oscillator in the phase
locked loop does not produce an exact match of
the intermediate oscillation version of the received
oscillation. Rather it produces a similar oscillation where
the rising crossings of zero dont always match but
on average

If it is locked in, the loop must detect every cycle. That is
the very definition of "locked." Your requirement of an "exact"
match is irrelevant to that definition.

But as you see from George's reply here the 'detection of every
cycle' is too vague.
The real definition seems to be there are the same number of zero
crossings as the
voltage rises in a 33 minute period but not an exact
correspondence.



Your scenario of 50% missed cycles is
clearly out of lock. With the system used, telemetry can't be
received until the loop has locked onto the carrier.


If missed cycles means that there are two local oscillator
rising zero crossings before there is a intermediate received
frequency rising zero crossing then this could be made up by
three intermediate received frequency rising zero crossings
during the same time interval there are two local oscillator
rising zero crossings and then one repetition of this etc..
That is over a long enough period eg 33 minutes the average
number of zero crossings in both cases will be the same and yet
clearly there is a lot of noise in the received frequency and
other candidate frequencies with or without their harmonics
might produce the same degree of "lock".


What do you mean by overlapping uplinks and downlinks.?
Do you mean that the assumed time of downlink occurred at the
same time as an uplink but not at a later time when the
downlink
from this uplink was expected?


I will say this once more. There were cases where uplink
sessions
overlapped in time with downlink sessions, and other cases
where there
was no overlap.
It is not clear at all what you mean by overlap(complete
or partial?) or consistent. Since all scheduled sessions of
typically four hour durations involved simultaneous transmission
and reception and complete overlap what do you mean by cases
where this did not happen. How do you know there were cases where
there was no uplink during the downlinks?
One- invalid- way would be to point to bad received data at
times that implied that there might not have been an uplink at
the assumed earlier uplink time and site.
If there were valid cases of downlinks when no transmission
was going on then I would expect the data received at this time
to be noise.
And it is not obvious that some sort of spurious lock could
occur in these cases and that doppler noise and slipped cycles in
the data which you said in your notes that you did not understand
may indicate this.



I analyzed all of this data together, without regard
to the overlap, and the results were entirely consistent.


"Overlap"
is a description of whether uplink and downlink activities were
happening at the same time or not, period. Absolute uplink and
downlink epochs are not "assumed," they are measured precisely.



Nowhere did I say I got rid of data because of overlapping
sessions,
because in fact I kept it.



What do you mean by incoherent tracking sessions. This
is
just jargon for rejecting data not conistent with light
travel
time assumptions.

No. Non-coherent sessions happen when the spacecraft uses its
own
oscillator, which is susceptible to temperature induced drifts.
These
types of sessions are useless for radiometric tracking because
the
clock drift cannot be disentangled from any Doppler-induced
frequency
drift.


That makes sense.

I see the assumed transmitter frequency which you said
was
constant and which in your filter files that I have seen is
always the same although you also say that it can change.??

The uplink frequency can be ramped, but wasn't. The uplink
frequency
was constant for each session.

George and Craig, The point I am trying to make here is
that
different frequency functions may fit the received periodic
waveform regarded as noise plus a specific doppler shifted
version of the know uplink frequency.

The waveform is sinusoidal, so your point is irrelevant.

I doubt that the recieved oscillations of voltage from the 8
Watt transmitter a billion miles away is as 'sine like' as the
local oscillator in the Phase Locked Loop.
The difference between a pure sine mixer oscillator frequency
and the received frequency may be more sine like than the
received frequency but maybe not.


That is even though the best fit is given by the phase
locked
loop local oscillator frequency etc., various nearby
frequencies
alone or in conjunction with some harmonics could in fact be
the
true received periodic oscillation..

Which frequencies or harmonics? How can harmonics be "nearby?"
(they
cannot)
Obviously I mean the harmonics of neaby frequencies

Can you provide (even) a single example? All of the downlink
power spectra I have seen have been flat except for one peak.

But how wide is the peak? To say that a Doppler shift of so
much has occurred and that a Doppler shift of a slightly
different value has not occurred you need to have a very sharp
peak.
Also the lack of exact matching zeros in the PLL oscillator
and the intermediate received frequency suggests a problem but
maybe not. I wish you or George make a clear, cogent argument
that this lack of matching is not "relevant".
Ralph