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.<br>
<br>Note that the following comments apply only to RX, although by symmetry they apply to TX also.<br><br>(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.<br>
<br>(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.<br>
<br>(3) Channels are addressed by URI, with a quadruple of parameters: (start time, duration, frequency, bandwidth).<br><br>(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.<br>
<br>73<br>Frank<br>AB2KT<br><br><div class="gmail_quote">On Tue, Aug 10, 2010 at 3:30 AM, John Melton <span dir="ltr"><<a href="mailto:john.d.melton@googlemail.com">john.d.melton@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">***** High Performance Software Defined Radio Discussion List *****<br>
<br></div>
The current architecture is that the hpsdr and softrock hardware servers send I/Q data to the client over UDP.<br>
<br>
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.<br>
<br>
The dspserver sends and audio stream of aLaw samples at 8000 samples per second. This gives good mono audio output.<br>
<br>
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.<br>
<br>
We can also have an option to send the audio stream as raw 16 bit samples at up to 48000 samples per second.<br>
<br>
Regards,<br><font color="#888888">
<br>
John</font><div class="im"><br>
<br>
On 08/10/10 02:37, Phil Harman wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
***** High Performance Software Defined Radio Discussion List *****<br>
<br></div><div class="im">
Hi Ed,<br>
<br>
Perhaps one of the features the Server could offer is to make I @ Q data<br>
available if requested. That way the user could write their own DSP code<br>
as required.<br>
<br>
73's Phil...VK6APH<br>
<br>
</div></blockquote><div><div></div><div class="h5">
_______________________________________________<br>
HPSDR Discussion List<br>
To post msg: <a href="mailto:hpsdr@openhpsdr.org" target="_blank">hpsdr@openhpsdr.org</a><br>
Subscription help: <a href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" target="_blank">http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org</a><br>
HPSDR web page: <a href="http://openhpsdr.org" target="_blank">http://openhpsdr.org</a><br>
Archives: <a href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" target="_blank">http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>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<br>
<br><br>