[hpsdr] Proposal for a new Software project.

[Jeremy McDermond]

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
> 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




 1259669140.0