> 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
Mercury is good for DIRECT SAMPLING to about 55 Mhz and bandpass
sampling much higher. The limits depend on your construction of the
required front end to make it useful and the specs, which may be found
from linear technologies for the LTC2208.
http://openhpsdr.org/wiki/index.php?title=MERCURY
You can see from here:
http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1155,C1001,C1150,P13693,
that it has full power operating bandwidth (responds to) signals up to
at least 700 MHz according to the data on the URL. There is NO
filtering in front of the A/D and the buffer amplifier (LTC6400-20) is
good to well over 1 GHz.
Bob
N4HY
VK2KU wrote:
> 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
>
>
>
--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn
> 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 am pretty sure you could easily lock these units with
injection locking. Make a PLL that locks a crystal to
66.666666666666 MHz and couple some (small) power at that
frequency capacitively to one or the other pin of the crystal
inside the SDR-IQ. (I do not say it is a clever way of locking
the unit, but it is surely possible - and technically uncomplicated)
> 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?
Yes. But that is not enough.
The downsampling has to be synchronized as well and one will
need a way to synchronize the USB transfers also.
> 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.
Yes. But there is no reason that the transmitter has to be sold
by the same manufacturer as the receiver;-)
> 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?
Yes. I think so.
I also think the other manufacturers RFspace and Microtelecom are
well aware of the merits and complications of a two channel
(or multichannel) receiver.
I have a feeling we will not have to wait many years for this
kind of product to become available:-)
73
Leif