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.
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.
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.
USB3 will be the standard for interconnection long before then.
Doubtless there will be minor problems with sampling frequency being
incompatible with MAP65,
but such details should not present any major difficulties.
Do others share this vision?
> 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...
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...@sm5bsz.com> wrote:
> > 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...
The appears to be a misunderstanding. The Mercury A/D is operating at 130 msps and it has capture aperture well above the nyquist rate for bandpass sampling. As Leif says for the other models mentioned, a bandpass filter is required to eliminate aliasing and because you are using aliasing as your friend here, you have a fall off of sensitivity as you go higher in frequency. For effective operation, they need a bandpass filter and a preamp to lower the system noise figure.
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.
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.
> 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:-)
|
