[hpsdr] Proposal for a new Software project.

[Murray Lang]

Serving the entire bandwidth of I/Q data is simple in concept but I 
wonder about the accumulated network bandwidth with numerous clients, 
particularly with 192KHz (stereo) sampling. I would be interested to see 
if the following approach makes sense to anyone other than myself.

What about performing the FFT at the server (only once to shared 
memory)? Per-client agents at the server perform the desired DDC on the 
shared spectral data and transmit the windowed segment to the client, 
probably compressed. The client is then responsible for the IFFT and IQ 
processing. This is obviously more complex but perhaps makes network 
demands more manageable. One niggle with it is that some representation 
of the entire sampled spectrum would also need to be sent to each client 
for the user to browse.

I imagine TX would be the reverse. That is, the client FFTs its I/Q data 
and sends a spectrum segment to the server, which merges all client 
spectra (after DDCs) into a collective spectrum - again in shared 
memory. The server IFFTs this to produce I/Q signals for the transmitter.

As for the command channel, there are lots of standards to choose from 
that avoid the need for proprietary IP socket stuff.

I hope this isn't too far left of field for the current thread.

Cheers,
Murray - VK6HL
>
>
> On Tue, Dec 1, 2009 at 7:05 AM, Jeremy McDermond 
> <mcdermj at xenotropic.com <mailto:mcdermj at xenotropic.com>> wrote:
>
>     ***** High Performance Software Defined Radio Discussion List *****
>
>     On Dec 1, 2009, at 5:26 AM, John Melton wrote:
>
>         The client server interface is fairly simple.  It uses a TCP
>         connection
>         for commands but uses UDP for the I/Q samples and any returned
>         audio.
>
>
>     Maybe this is way too complex to implement for what we want, but
>     I've been thinking about the problem of a "HPSDR Server" a bit,
>     and it seems to me what we're implementing is a essentially a
>     streaming media server with I/Q data.  It makes a certain amount
>     of sense to me to use existing protocols on the wire, so it might
>     make some sense to consider RTSP/RTP for transporting control and
>     data in this case.  We can come up with some sort of URL format in
>     the RTSP port to specify receiver and frequency, and we can use
>     RTSP to set up RTP streams on UDP ports for the clients to pick
>     up.  A frame format can be defined or stolen in RTP for the I/Q
>     data we need as well.  We can probably use some of the work of
>     others in the forms of RTSP/RTP libraries.  The advantages of this
>     are that RTP is designed to transport time-sensitive media like
>     this that requires a low amount of jitter.  We're not too
>     different than streaming video or audio in that regard.
>      Additionally, RTSP and RTP are well understood, and will flow
>     past many firewalls without any problem.
>
>     Again, a fairly ambitious idea, and maybe not a "1.0 feature" but
>     something to think about at least.
>
>
>
>         Regards,
>
>         John g0orx/n6lyt
>
>
>
>
>
>         _______________________________________________
>         HPSDR Discussion List
>         To post msg: hpsdr at openhpsdr.org <mailto: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/
>
>
>     --
>     Jeremy McDermond (NH6Z)
>     Xenotropic Systems
>     mcdermj at xenotropic.com <mailto:mcdermj at xenotropic.com>
>
>
>
>
>     _______________________________________________
>     HPSDR Discussion List
>     To post msg: hpsdr at openhpsdr.org <mailto: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/
>
>
>
>
> -- 
> The dose makes the poison. -- Paracelsus
>
> Please note new phone numbers:
> mobile: (908) 442-8863
> work: (908) 428-4916
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20091201/963c6305/attachment-0004.htm>