<div>David --</div>
<div> </div>
<div> This is much more the way I feel about what we are trying to accomplish.  We want to define how part of the program communicate and then build code that tries those interfaces and then modifies as we find better ways to accomplish tasks.  I would like to capture the existing condition as well as develop new ideas.</div>

<div> </div>
<div>We have a defacto standard, which powerSDR, Kiss Konsole, ghpsdr, ghpsdr3 and acorn-sr are currently using to talk to the hpsdr hardware.  It is defined in the USB document and copies of which can be found on the Athena wiki page and on the svn in Documents section.</div>

<div> </div>
<div>As for the other server to client powerSDR, Kiss Konsole, ghpsdr currently do not support this idea.  ghpsdr3 and acorn-sr do support a server client connection.  Since acorn-sr uses lots of other folks libraries and ghpsdr3 is C code on our svn, I will start with describing how ghpsdr3 works.  ghpsdr3 is just one way of accomplishing the job but is working code and it has been submitted to our SVN.</div>

<div> </div>
<div>I plan to put illustrated descriptions of the communication layers on the Athena wiki in the near future.  Then we can pull together a experimenters subset with some simple examples.  </div>
<div> </div>
<div>As you point out,  this is a hobby and it should be fun!</div>
<div> </div>
<div>  Dave, KV0S</div>
<div> <br><br></div>
<div class="gmail_quote">On Wed, Dec 2, 2009 at 1:27 AM, David McQuate <span dir="ltr"><<a href="mailto:mcquate@sonic.net">mcquate@sonic.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">***** High Performance Software Defined Radio Discussion List *****<br><br></div>Many thoughtful comments have been posted!<br><br>As one who has long appreciated the concept of separating diverse functions--hardware interface, signal processing, user interface, (ok, I've been in sdr for a scant year) but who also shys from complexity, may I suggest that simply defining the interface between these functions would allow almost immediate exploitation and exploration.  (ie fun!)  While a business may need to carefully define everything before implementing anything, amateurs can affort the "inefficiency" of some jumping in to give something a try, while others methodically define the longer term standards.<br>
<br>Anyone willing to post some (preliminary) protocol specs?  (Let's discuss!)<br><br>How about some example code fragments on how to send & receive TCP and UDP?<br><br>Are there other "channels" that should be considered in addition to TCP / UDP?<br>
<br>73,<br>Dave / wa8ywq 
<div>
<div></div>
<div class="h5"><br><br>_______________________________________________<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>KV0S - Dave Larsen<br>Columbia, MO, USA<br>