[hpsdr] multiple receivers - is it really necessary

[Steve Bunch]

I used to work for a cellphone company.  When I got cellphones for my  
wife and daughters, I told them "This is NOT a phone, it's a radio.   
If you think of it as a phone, you'll just be disappointed.  If you  
think of it as a radio, you'll be amazed at how well it works."  My  
wife occasionally mentions that she remembers that vividly -- for  
example, when her call drops when we go through a low spot on the  
highway.  :-)   My son's a ham -- no disclaimer was needed when he got  
his!

Many modern cellphones have two receiver front ends so they can do  
antenna diversity reception.  Even within the size of a cellphone,  
less than a wavelength long, you can get a few dB's of benefit from  
combining the signals from two antennas (with different polarization,  
shadowing, etc.).  In an SDR, this implies multiple front ends down  
into multiple A/D converters; in the case of HPSDR, that means  
multiple Mercury boards.  Supporting multiple Mercury's, for this and  
other fun things, is a Good Idea.

One of the simplest and most useful multi-receiver use cases is  
monitoring one or more frequencies, other than the one you're  
listening to, while waiting for something to happen.  Lots of people  
do this all the time on VHF/UHF, e.g., listening for activity on  
simplex or other repeaters while chatting on a repeater, using  
multiple radios.  Useful frequencies are often more than 192KHz apart  
in the high bands, so if you only have one 192KHz A/D stream coming  
from the Mercury to the PC, implementing multiple RX's in your PC SDR  
program doesn't do much for you.  But you will be able to listen to  
multiple frequencies in an entire band at a time (up to 54MHz of it,  
anyway!) using a single-Mercury HPSDR and a transverter, once the  
Mercury firmware support for multiple rx is available.

It is certainly nice, and probably preferable from a flexibility  
standpoint, to do multiple-rx on a wide band in an SDR by scooping a  
lot of bandwidth into the PC and doing ALL the processing there, but  
for narrow-band work, especially in a very wide frequency band, you  
just don't need to use so much brute force.  Putting multiple NCO/ 
filter chains into the FPGA and sending multiple narrower streams to  
the PC should take much less processing power (and less REAL power --  
using USRP/GNUradio on a Pentium D, my AC power consumption went up by  
over 15W to listen to FM broadcast).  It's a Good Idea.

Thanks for all the hard work you guys put in on this!

Steve, K9SRB

On Aug 3, 2009, at 8:17 AM, Graham / KE9H wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
> Hi Mike:
>
> Well, it certainly is not your "grandfather's" radio.
>
> Would your friend say that a Cellular Radio system is "radio" ?
>
> :-)
> --- Graham
>
> ==
>
>
> Mike Hamel wrote:
>> Hi Graham,
>>
>> I have a friend who has a knack for putting things bluntly, and  
>> when I
>> talk with him about the potential applications for networked
>> multilocation SDRs, he dryly says "ok, but is it really radio  
>> anymore?"  :-D
>>
>> Thanks for the VLBI references. I will get a stepladder and check  
>> them
>> out (likely a bit above my head).
>>
>> Regards,
>>
>> Mike
>> wo1u
>>
>>
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/


 1249315573.0