"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