"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