"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