[hpsdr] SDeR1

[David McQuate]

I'd like to find out more information on SDeR1.
Is the developing code available for looking / trying ?
Any documentation written at this point?
Are there ways I might contribute to the development?

Thank you!
Dave
wa8ywq

Frank Brickle wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
>   
>
> ------------------------------------------------------------------------
>
> I just wanted to drop a few ideas into the discussion at this point. 
> They're not fully developed here, but I hope the implications will be 
> clear. They're fundamental design principles in the new DttSP, which 
> we're calling SDeRl.
>
> Note that the following comments apply only to RX, although by 
> symmetry they apply to TX also.
>
> (1) IF streams can come in two forms: pre-D (pre-demodulation) or 
> post-D (post-demodulation). *Most of the time*, what a server is 
> passing around is pre-D signal. Demodulation generally happens at the 
> client, or else is carried out by a lightweight proxy inserted between 
> the server and and endpoint client.
>
> (2) What a server sends to clients as IF are *channels*, generally 
> sub-channels of some broader-bandwidth sampled RF. The channels can 
> all be thought of as selected sub-bands of the full bandwidth. They 
> are specified in terms of center frequency, bandwidth, and time. So 
> what a client asks for, and gets, is always baseband with respect to a 
> specified frequency, and narrowband with respect to the full, upstream 
> RF bandwidth.
>
> (3) Channels are addressed by URI, with a quadruple of parameters: 
> (start time, duration, frequency, bandwidth).
>
> (4) "Servers" can be recursively created and inserted into streams as 
> lightweight proxies, as mentioned in (2), so as to subdivide IF 
> subchannels for further clients. A user-level client only needs to 
> know how to process a single narrowband, baseband channel.
>
> 73
> Frank
> AB2KT
>
> On Tue, Aug 10, 2010 at 3:30 AM, John Melton 
> <john.d.melton at googlemail.com <mailto:john.d.melton at googlemail.com>> 
> wrote:
>
>     ***** High Performance Software Defined Radio Discussion List *****
>
>     The current architecture is that the hpsdr and softrock hardware
>     servers send I/Q data to the client over UDP.
>
>     In the current systems, there are 2 clients,  one is the dspserver
>     and the other is a modified version of ghpsdr (receiver) that
>     connects to the I/Q server.  There is no problem sending I/Q data
>     around a local LAN running at 100 or 1000 Mb, but you would not
>     want to send I/Q data over the internet.
>
>     The dspserver sends and audio stream of aLaw samples at 8000
>     samples per second.  This gives good mono audio output.
>
>     I have taken the audio output from jMonitor and fed it into fldigi
>     (using a cable between 2 sound cards).  There is no reason why we
>     cannot have a client that makes the audio available on VAC on
>     Windows and Jack on Linux.
>
>     We can also have an option to send the audio stream as raw 16 bit
>     samples at up to 48000 samples per second.
>
>     Regards,
>
>     John
>
>
>     On 08/10/10 02:37, Phil Harman wrote:
>
>         ***** High Performance Software Defined Radio Discussion List
>         *****
>
>         Hi Ed,
>
>         Perhaps one of the features the Server could offer is to make
>         I @ Q data
>         available if requested.  That way the user could write their
>         own DSP code
>         as required.
>
>         73's Phil...VK6APH
>          
>
>     _______________________________________________
>     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/
>
>
>
>
> -- 
> Does anyone doubt that once a society ceases to be able to afford 
> schools, public transit, paved roads, libraries and street lights -- 
> or once it chooses not to be able to afford those things in pursuit of 
> imperial priorities and the maintenance of a vast Surveillance and 
> National Security State -- that a very serious problem has arisen, 
> that things have gone seriously awry, that imperial collapse, by 
> definition, is an imminent inevitability? -- Glenn Greenwald
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/

 1282752390.0