[hpsdr] cuSDR remote operation?

Lyle Johnson kk7p4dsp at gmail.com
Mon Nov 26 18:55:03 PST 2012


Phil,

I agree, option 3 looks the best given the philosophy of the HPSDR 
preoject, and the ability to leverage what has already been done.

While a Raspberry Pi is an interesting widget, it seems to me that there 
is little point in trying to use such a minimalist platform except for 
the challenge of doing so.

A project I am doing commercially uses an SBC from www.embeddedarm.com  
As you note, there are lots of choices in the marketplace.  This is one 
piece of hardware we ought not to need to develop ourselves!

73,

Lyle KK7P

> ***** High Performance Software Defined Radio Discussion List *****
>
> Hi Aivars,
>
> You have raised an interesting topic regarding remote operation of HPSDR
> systems.
>
> In fact I'm currently in the process of writing an article about just this
> topic seeing that there a number of different SDR architectures appearing
> -these are:
>
> 1. Do the minimal amount of processing in the SDR hardware and do the bulk
> in the PC/Tablet
>
> 2. Do all the DSP and networking in the hardware and keep any processing
> in the PC/Tablet to an absolute minimum.  That way the SDR hardware can
> plug directly into the Internet.
>
> 3. Do the minimal amount of processing in the SDR hardware. Use a small,
> low cost, single board computer (SBC) connected directly to the SDR
> hardware that is dedicated to the SDR and networking i.e. an SDR Server.
> This also removes the bulk of the processing from the PC/Tablet.
>
> Most HPSDR users are using option 1 at the moment and Jeremy's success
> with the iPad of being able to 'drink from a fire hose' is an impressive
> example of how well this can work!
>
> An example of option 3 is the work that John Melton is doing in porting
> ghpsdr to a Raspberry PI SBC.
>
> Each of these options has pros and cons but they are simply just that -
> different options.
>
> My own interest is in option 3 since we can keep the cost, and complexity,
> of the SDR hardware down and many members can contribute to the design and
> development of an SDR Server.
>
> There are some very small, high performance and low cost, Linux based SBCs
> appearing on the market that will make ideal SDR Servers.  This option
> gives us enormous flexibility into the future.
>
> With an SDR Server, using a highly efficient process to compress the
> receive audio becomes viable as does compressing the bandscope data. In
> which case the data rate from the SDR Server will be substantially lower
> than a direct connection to Metis or Hermes.
>
> And FYI, cuSDR uses a Client-Server architecture (although presently both
> reside on the same PC during the development phase) which will support
> option 3.
>
> 73 Phil...VK6APH
>
>
>
>
>
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> On Nov 26, 2012, at 8:45 AM, "Aivars Straupe" <yl2gvc at inbox.lv> wrote:
>>
>>> ***** High Performance Software Defined Radio Discussion List *****
>>>
>>>   Hello!
>>> I've got a question about cuSDR remote operation. Is it possible to
>>> organize that over internet? First, how to transfer sound? Second, which
>>> ports are necessary to forward? And, is there any possibility to
>>> minimize traffic? I found just one, switch from 192 to 48. That minimize
>>> traffic to 600kb/s, but that is still a lot. Any suggestions?
>> Remember that currently openHPSDR hardware doesn't route IP.  That means
>> you have to be on the same network segment as the hardware.  This
>> precludes "over the Internet operation."  The big sticking point is that
>> the hardware needs to get a discovery packet from an IP address to wake it
>> up and get it to recognize you.  This has to be done via broadcast, which
>> means that it must be done on the local network somehow.
>>
>> Audio shouldn't be an issue.  It's generated on the computer side anyways.
>>   It doesn't need to be really "transferred," it needs to be pushed out a
>> local device rather than (or in addition to) the openHPSDR audio
>> connector.  This is what's done on Heterodyne for iPad because the typical
>> use case for those folks is not near the openHPSDR rig.
>>
>>>   73!!!
>>>                                       Aivars.
>> --
>> Jeremy McDermond (NH6Z)
>> Xenotropic Systems
>> mcdermj at xenotropic.com
>>
>>
>>
>> _______________________________________________
>> 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/
>>
>>
>
> _______________________________________________
> 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/
>


 1353984903.0


More information about the Hpsdr mailing list