[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linrad] Re: Future SDR Developments

Hi Leif,

Thanks for your useful comments.
Yes, I was aware that the SDR-14 will work at up to 200MHz using its
direct input, and presumably the alias response of the unit with
appropriate filtering.
However the SDR-14 (and SDR-IQ) are not built in a way which enables
GPS locking of the sampling frequency, and the error in this (in my
case) is some 300Hz.
I do not really have the technical background for detailed discussion
of this, but it seemed to me that if we have 2 identical Mercury
boards, both locked to the same GPS signal, then for all practical
purposes it is as if they had a common LO. Is that indeed the case?
The other lack in the SDR-14 is that it is a receiver only, with no
provision for transmitting on 144MHz. A transmit function is necessary
if we are to dispense completely with a 28MHz transverter.

I appreciate your comments on the needed transfer rate of 2x1MHz. I
had not understood that.
And yes, of course it would be necessary to synchronize the transfers
from the 2 Mercury receivers. I have no idea what is involved in that,
but has anyone actually communicated these needs to the project
leaders in the HPSDR project?

73  Guy  VK2KU

On Jun 5, 10:52 am, Leif Asbrink <l...@xxxxxxxxxx> wrote:
> Hi Guy,
> > It is no more than 2 years since the SDR-IQ appeared, following its
> > sibling the SDR-14, with a clock frequency of 66.7MHz allowing direct
> > sampling at up to 30MHz.
> Oooh! The SDR-14 works nicely up to 200 MHz. You just have to
> put a selective amplifier in front of it to remove aliasing and
> (of course) use the direct input.
> > The Perseus SDR soon followed with direct sampling up to 40MHz.
> > I have been following the HPSDR project with considerable interest:
> >http://openhpsdr.org
> > The Mercury receive module has direct sampling up to 65MHz, already
> > more than double the SDR-IQ.
> > And there is a transmit module Penelope to match, with a GPS locking
> > module Excalibur soon to be released.
> > Surely in a year or so, two at the most, we will have direct sampling
> > at 144MHz, with no further need for transverting down to 28MHz, just a
> > need for a bit more front-end gain.
> We already have that. SDR-14 or a modified Perseus.
> > Already I can see the shape of my next major 144MHz upgrade:
> > Penelope transmit board with direct output at 144MHz,
> > Twin Mercury receive boards, sampling directly at 144MHz, one for each
> > polarity,
> > and Linrad as the main receiver, followed by MAP65.
> I am afraid that the units are not designed for that. It will be
> necessary to synchronize the the digital downconversion FPGAs
> and to provide for synchronization of the USB transfers as well.
> > USB3 will be the standard for interconnection long before then.
> Well, I do not think it is wise to force everyone to buy new hardware.
> USB 2.0 will be adequate for most applications.
> The reason Linrad is not working with the openhpsdr hardware is: "Perhaps
> the most exciting of all the modules, the Mercury module will enable direct
> sampling of the 0-65 MHz spectrum. Based on a Linear Technology LTC2208
> 130MSPS 16-bit A/D converter, the board will contain it's own FPGA to
> undertake Digital Down Conversion (DDC) to 250 kSPS or less for transfer
> over the Atlas bus to the USB interface on the OZY board."
> To become interesting the OZY board would have to combine the synchronized
> output of two Mercury boards and send the two I/Q data streams at a user
> selectable bandwidth to the PC. I would not invest my time in it unless
> the maximum bandwidth is at least 2x500kHz. 2x1MHz should be no problem
> since Perseus gives 2 MHz on a single channel. The high bandwidth is
> required for the removal of static rain.
> I am pretty sure someone will make such hardware available and I will
> buy one unit and make sure Linrad works with it as soon as I get a chance:-)
> > Doubtless there will be minor problems with sampling frequency being
> > incompatible with MAP65,
> > but such details should not present any major difficulties.
> Yes. We can do fractional resampling in the PC. (Linrad already has the
> code for that but I am not aware anyone tested it with MAP65.)
> > Do others share this vision?
> In a broad sense, yes:-) But differ in some details...
> 73
> Leif
>   SM5BSZ
You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad?hl=en