[hpsdr] Step 1 Question

[Frank Brickle]

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>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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20100811/30af5f3c/attachment-0004.htm>