[linrad] Re: Linrad via Ethernet

[<leif@xxxxxxxxxx>]

> I hadn't looked that close yet. Maybe the AD6620 data sheet deserves
> more than 'a brief look'...
Yes;-)

> >Maybe it would be better to use some general purpose gate array
> >for the second filter. I do not like the idea of allowing the PC
> >to receive oversampled signals because any spare processing power
> >it might have can be put to bettert use:-)
>
> I respectfully disagree.
>
> For ham/hobbyist purposes, *nothing* beats the price/performance of
> commodity PC hardware. I just had a look on eBay; I can get a
> PIII/933 with 256MB RAM and no disk for EUR80 + shipping. And that's
> from a store; similar hardware can usually be had for very little
> from people who've upgraded their system twice since.
Yes, but I am not so sure you will find it is capable of filtering
two channels at 4 MHz to give a well used output at 1 MHz.

> IMHO, actual hand-soldered hardware should be limited to the absolute
> minimum to get raw data to a PC. The more complex the design, the
> less likely that it will work first time around (and 4-layer protos
> are getting cheap but not *that* cheap). FPGAs are nice, but how many
> people have the skills to program them well? A much larger target
> audience will be able to code filters in C than in VHDL, and there
> are plenty of free signal processing libraries out there.
Hmmm, I have no idea how to program it - but once it has been done
there is no need to change the program.

> Is one cheap PC not enough for filtering *and* Linrad ? Add another
> PC, and dedicate one to filtering/decimating. Need/want to do
> contests 'in the field' ? Search on eBay for 'laptop broken screen'.
> That's how I ended up with an Athlon/1.2GHz for US$75 (plus shipping,
> but that's a whole 'nother rant).
Oooh! We are discussing different things.
Remember: "My dream is a unit ..........."
This will require a high performance PC that might not even be available
today because I want to do full processing of two channels at 2 MHz
bandwidth at least.

> >Some more bandwidth is highly desireable (to fight static rain well.)
> >Two channels (provision for syncing several units) is required for
> >use with Linrad on a X-yagi array for EME. More channels would
> >be extremely valuable on HF bands. (On HF less bandwidth is needed
> >so the PC will have no problems)
>
> Absolutely agreed. I'm building mine as a testbed for diversity/MIMO
> experiments, so the thing will definitely have the ability to slave
> additional units. I like to have my synth/sample clocks synchronized.
OK. Fine:-)

> >The SDR-14 with an ethernet interface, a digital filter in a gate
> >array
>
> Like http://comsec.com/wiki?UniversalSoftwareRadioPeripheral ; you mean ?
Yes. This solution, the USRP, uses AD9862 and the dynamic range is
inadequate as far as I understand. but they use an Altera FPGA and although
I do not quite know what it is I assume it is a well selected chip;-)

> >       and a better sampling clock would be one solution:-)
>
> This is one area where I am very interested in your suggestions; I
> was quite impressed by the depth of your discussions on oscillators
> on the Linrad pages.
>
> What would 'a better sampling clock' look like in your opinion ? My
> current line of thinking is to have one reference OCXO/TCXO (possibly
> disciplined *very slowly* by GPS), with other frequencies generated
> by locking low distortion VCXOs/VCCROs to this reference.
The SDR-14 has good phase noise when used at i.e. 2.5 MHz but when I feed
144 MHz into it it becomes too noisy to be really useful. I assume this
is due to careless design but I have never seen the schematic and I have
not been curious enough to open the box.

I would go for something like the LO in the RX10700 with provision for
GPS control but I would not add that at the first shot because I see no
need for frequency accuracy.


> Add transformer-fed low jitter LVDS->CMOS converters (or fast low jitter
> comparators, like the Linear LT1720) to generate the ADC sample clock
> if needed (ie: if the jitter performance of the ADC clock input is
> worse for AC-coupled sine waves than for CMOS, need to investigate
> this).
My experience with comparators is that they introduce much more phase
noise than well chosen saturated amplifiers. A comparator is designed to
make its transition when the inputs are equal, an amplifier will have a
undefined transition point that will drift with temperature, supply
voltage and drive level.

The first step in converting from sine-wave to square-wave is critical.
I would try a 74AC14 with all six gates in parallel. I would feed
it with a 6V sine-wave from the oscillator via a low impedance LC circuit
(to minimise the noise due to the equivalent noise input current) and
to make the AF noise on the input zero. A saturated amplifier is also
a frequency mixer and I would not like to mix AF noise due to leakage
currents or other 1/F noise with the LO signal;-) The output would go
directly to the AD6644 (or whatever 14 bit AD used). The output could
also feed "anything" through say 100 ohms for use as a buffer for
other clock consumers. The 100 ohm resistor to isolate the clock
from noise in the "anything" chip. 1/F noise will modulate the input
impedance of "anything" and that will modulate the LO. A series resistor
will reduce this effect and the very low output impedance of six
parallelled gates helps - also for the noise emitted by the AD6644
itself.

> Random thought: instead of locked VCXOs, maybe have a separate
> digital channel record the frequency/phase differences wrt the
> reference clock and have software correct for these. Hmmm...
This would be a clever solution:-) The frequency error contains noise.
In a phase locked loop one runs into problems when trying to filter
out this noise well because the phase shift of a steep filter
causes instabilities. This leads to a compromise between filtering
and response time. By applying the frequency error further down
the Rx path at a point where the signal delay matches the filter
delay one will get a very robust system easily:-) In Linrad the
appropriate point is at the output of the decimation to the baseband.
Here the frequency is already shifted by a frequency offset that
may vary with time. (It does if AFC is enabled) Adding a small correction
to this shift would not cost anything and sampling the phase error at
a few kHz, then applying the appropriate filter and delay would
be very easy. Good idea:-)

73

Leif / SM5BSZ

PS. I looked up the time jitter of LT1720. It is 11 or 15 ps RMS
depending on the transition direction at 20 MHz. I guess it will
be a bit smaller at 66 MHz but probably not much below 7 ps. The
time jitter (aperture uncertainty) of the AD6644 is 0.2 ps RMS,
about 30 times smaller. As far as I understand it means that an
LT1720 would degrade the phase noise at 144 MHz by 60 dB or so:-( DS.



#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL