Re: [linrad] More Mars info and questions

["w3sz" <w3sz@xxxxxxxxxxx>]

HI, Marko and all!

Thanks for the helpful information and the excellent points!

I agree with all of your points on what is the 'necessary bandwidth' in this case. 
If I can do it without compromising detection, I like to have a wider waterfall
bandwidth to place the signal in its proper context.

I do have both GPS and Rb control available here for the PTS Synthesizer LO's and was
planning to usee or the other. My LT70S is not GPS controlled of course, but I have
coupled in an LO signal from one of the extra PTS's here through a 180 pF [just what
I had within arms-length reach] to 'tickle' the LO in the LT70S with the proper GPS
or
Rb-locked frequency to keep it locked, too.  I tried this last night and it seems to
work fine, and then everything is on frequency.

The frequency as you point out will need to be stable roughly to the half-width of
one bin over the period of integration, whatever that is chosen to be.  I don't know
if there is an advantage to going much lower, e'g. to 0.1 Hz.  I have found that here
I can use a waterfall bandwidth of 24 KHZ and a 2nd FFT bin width of 0.1 Hz and
though I have a processing delay of 12 seconds, everything seems happy and the CPU is
only 36-40% occupied, although the high resolution and baseband display update cycles
take about 6 seconds.

I put a copy of a screen dump of Linrad receiving a Continuous Carrier with these
settings at http://www.qsl.net/w3sz/test823.gif

I have experimented with Linrad running on two machines here today using (1) the
audio from a 432 receiver to feed Linrad and (2) an LT70S transverter feeding an
R2Pro LNA feeding a TAK-xxx mixer with a PTS 160 LO feeding an RX2500.  Both machines
are then running the Linrad with Delta44 input and SB ouput soundcards. 

The 'real' Linrad receiver using option [2] seems to do a bit better for really weak
signal stuff I think as the baseline is more homogeneous due to its having been
calibrated with the Linrad software.

But it looks like the audio approach should be usable though.

I am not a DSP expert, so I have some questions:

1.  It is a problem to sample at 16 bits rather than 8 if the CPU handles it?  I
thought this would always be an advantage, or at least no disadvantage.

2.  If the bins can be kept equal to or smaller than whatever the ideal width is,
then is
there a disadvantage to making the waterfall wider, as I want to do, assuming there
is no aliasing at the desired signal?  Again I am assuming that the CPU can handle
the work.

3.  And now the hard questions.  For detecting the Mars Rover and making 'S' files to
analyze later as well:

    a.  What parameters should be used for a setup of type [2] above?
    b.  How about for type [1]?
    c.  What parameter choices determine the frequency [or temporal] resolution of
the 'S' files, and what is the specific relationship between parameters chosen and
the characteristics of the 'S' file?

Assume for this exercise first that the computer CPU power is not a consideration.

I have listed the parameters I am currently using and planning to use below.  I will
also enable AFC and see how that affects CPU usage / timing issues

I am hoping Leif will help out here :)  I want to do the best job of collecting data,
and not find out after the experiment is over that I spoiled things by not having a
parameter set ideally.  So I want to know how to ensure collecting the best 'S' file,
as well as how to set things for best detection probability.

Remember when you play around that if you choose FFT2 to be type [0] or [1] your FFT
size is limited to 64K and thus your minimum bin width for a given waterfall
bandwidth is limited.  If you use FFT2 type [2] then the FFT size can be larger than
64K, and thus you can achieve a better frequency resolution for a given waterfall
bandwidth and sampling rate, since resolution [bin width] is sampling rate / fft
size.

My parameters are:

First FFT bandwidth (Hz) [10]
First FFT window (power of sin) [3]
First forward FFT version [2]
First FFT storage time (s) [6]
First FFT amplitude [1000]
Enable second FFT [1]
First backward FFT version [0]
Sellim maxlevel [6000]
First backward FFT att. N [6]
Second FFT bandwidth factor in powers of 2 [6]
Second FFT window (power of sin) [1]
Second forward FFT version [2]
Second forward FFT att. N [8]
Second FFT storage time (s) [20]
Enable AFC/SPUR/DECODE [0]
AFC lock range Hz [150]
AFC max drift Hz/minute [100]
Enable morse decoding [0]
Max no of spurs to cancel [0]
Spur timeconstant (0.1sek) [5]
First mixer bandwidth reduction in powers of 2 [4]
First mixer no of channels [1]
Baseband storage time (s) [200]
Output delay margin (0.1sek) [5]
Output sampling speed (Hz) [6000]
Default output mode [1]
Audio expander exponent [3]
A/D speed [24000]
Check [1110102]

73,

Roger
W3SZ

----- Original Message Follows -----
> Hello,
> 
> I asked almost the same questions on Mars-net and got the following info:
> 
> SCET is basically UTC on Mars, so the signal will appear cca 3 min (OWLT)
> after end of occultation as given in SCET.
> (Add OWLT to SCET to get UTC on earth)
> 
> BTW, if you don't have QRM (that is, if you can only hear (or see on FFT)
> noise) then there's no need to sample at 16 or 24 bit precision (even 8bits
> is too moch, but it's the lowest sound cards will go.) You only need more
> bits if you need to filter out strong QRM - but then it probably hopeless
> anyway :-)
> 
> Doppler is +-4Khz max (even less during the time the signal is available)
> so there is no need to record more than 10kHz of bandwidth either. 
> 
> If you know the doppler and your RX frequency, SSB bandwidth will do.
> Even if you keep your RX frequency fixed - during the time (<15min) when
> the signal could be available, the change of doppler is less than 800Hz.
> You'll only have to retune your rx between EOCCSE end EOCCSB and
> back, however.
> 
> Since in the final processing, bandwiths of one Hz or less will be needed
> for detection, locking to a rubidium or GPS clock will be handy.
> In absence of these, the receiver should at least be stable to <1Hz
> during the few minutes of available integration time....
> 
> I have asked S51ZO to use his 70cm array  (8X10WL DL6WU).. this
> weekend I'll visit him to check the sensitivity using celestial sources.
> If it's OK, I'll probably make some recordings for later processing.
> There is of course no hope of real time detection.
> 
> 73, Marko S57UUU
> 
> 
> On Friday 22 August 2003 05:58, w3sz wrote:
> > Hello, All!
> >
> > Here is some more information on the Mars Relay UHF tests, and a request
> > for clarification by those of you who know spacecraft lingo as to what we
> > need to do with the SCET times listed in the pdf files Joe directed us to:
> >
> > [ http://206.46.189.90/~km1p/ is the page of Joe's that has the helpful
> > data files]
> >
> > This page contains Link Budget data you can adapt for your system as well
> > as other data.  The file MGS_Events.pdf gives the potential times for the
> > CW tests, from 8-26 to
> > 8-29.
> >
> > SCET is 'spacecraft event time' and is basically if I understand correctly
> > UTC onboard the spacecraft at the time the spacecraft perceives event in
> > question.  When a signal is sent from earth to a spacecraft, SCET = TRM +
> > OWLT, where OWLT is one-way light time and TRM is UTC when the transmission
> > is sent from earth to a spacecraft.
> >
> > I have not heard this term before, and thus I don't know if when the signal
> > goes from the satellite to earth if we need to add the transit time to the
> > SCET to get UTC, or if the SCET times listed in MGS_Events.pdf are just our
> > UTC, having already been corrected for transit time.  I am hoping someone
> > with more knowledge than I can answer this.  It would be nice if either [1]
> > we can just use SCET as UTC or [2] someone else has done the correction. 
> > If I did my math right the OWLT is about 3.1 minutes for this case [see the
> > file MGS_Geocentric_Doppler.pdf].  So it does make a bit of difference,
> > especially if you are planning to record 16 or 24 bit 90 KHz wide Linrad
> > data files and want to record them at the right time ;)
> >
> > I would assume that we would need to listen for signals sent from 15 to 0
> > minutes before EOCCSB and for 0-15 minutes after EOCCSE as listed in the
> > file MGS_Events.pdf.
> >
> > The question I can't answer is can we just use the SCET times listed in
> > this file or do we need to add 3.1 minutes for the OWLT to the SCET times
> > listed. [and of course I could have done the math wrong].
> >
> > Also, I think the Link Budgets were done when the spacecraft was 2.1 to
> > 2.8E+10 meters
> > distance, and now I think that it will be 5.58E10 meters away so the link
> > budget would need to be adjusted for that as well as for receive antenna
> > gain, etc.
> >
> > I am planning to use my 4 M2 4329WL array with GasFET preamp at the power
> > divider going to an SSB electronics LT70S.  I will then hook up 2 TUF-1H's
> > with a 1/4 wave length of coax to give me the phase shifting to the Linrad
> > Box, and Linrad will function as my 28 MHz IF rig which I will need to tune
> > to 33 MHz.  If the Helical filter in the preamp on the mast is too narrow,
> > I am dead in the water.  If the filters in the LT70S are too narrow I will
> > do some playing with the LT70S, or alternatively try to pull off the IF
> > from one of my IC970's, as they go up to 450 MHz.  I won't get 90 KHz of
> > bandwidth for Linrad then, but I should get at least 15 KHz.
> >
> > Comments appreciated!  I am quite sure I have made some errors as I have
> > not thought about any of the above subjects before writing this email.  It
> > is fun, though ;)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 73,
> > Roger Rehr
> > W3SZ
> > FN20ah
> > http://www.qsl.net/w3sz
> 


73,
Roger Rehr
W3SZ
FN20ah
http://www.qsl.net/w3sz


LINRADDARNIL