[hpsdr] client/server over Internet

[Ken N9VV]

A "blast from the past";

Those interested in remote operation will enjoy reading about the 
client/server suite developed by John Melton in 2010 called *ghpsdr3*

Use Google to search for *ghpsdr3 G0ORX* and you will find a wealth of 
info.

I look forward to the future when John has rebuilt his QTH and has some 
brain cycles to re-invent ghpsdr3 with the power and beauty of 
*linHPSDR* (which he announced at F'Hafen);

<URL:https://openhpsdr.org/wiki/index.php?title=Ghpsdr3>

<URL:http://napan.ca/ghpsdr3/index.php/Main_Page>

<URL:http://g0orx.blogspot.com/>

GL 73 de Ken N-9-V-V


On 6/19/2018 10:26 AM, Roger Rehr W3SZ wrote:
> ***** High Performance Software Defined Radio Discussion List *****
> 
> Hi All,
> 
> Amazingly, I was working on the following post when I saw this posting
> of Scott's!  I changed the Subject of this post to reflect the main
> content of this reply.
> 
> However, before I place my post below, let me note that VBAudio's
> VoiceMeeter Banana CAN send VAC-type audio streams over the Ethernet
> using its VBAN facility, and I have experimented with doing just that
> and I have gotten excellent results (i.e. no problems detected) using my
> openHPSDR hardware with PowerSDR and the various WSJTX modes over a 5
> mile wireless 2.3 GHz Ethernet link.
> 
> On 6/19/2018 9:43 AM, Scott Traurig wrote:
>> Unless and until we see a true client/server implementation for
>> openHPSDR radios (this includes but is not limited to Apache radios),
>> solutions for remote operations will remain a spit and bailing wire
>> affairs.
> Here is the post I was working onwhen I saw Scott's comment:
> 
> It is truly wonderful to see all of the new activity on the reflector
> regarding DFC, Linux, the "new" protocol (which isn't so new anymore),
> midi controllers, etc.!  The announcements and discussions are
> generating lots of new ideas here, and I am sure many list readers are
> finding the same.
> 
> One idea that I thought "the big boys" would have grabbed onto and run
> with long ago is the idea of having an architecture with a local client
> (maybe even a browser) that could communicate with multiple remote
> severs.  I know that a lot of folks have expressed a desire to operate
> remotely, and there have been postings to this list in this regard over
> the past several years.
> 
> I implemented an architecture based on KissKonsole for doing this more
> than 2 years ago and have been using it on a daily basis with excellent
> results over the past 2 years.  But my implementation is [1] limited in
> scope and performance by my own intellectual and knowledgebase
> limitations, [2] highly specific to my needs here, and [3] of course
> does not contain the breadth and depth of features available, for
> example, in PowerSDR.  When I did this implementation, I expected that
> it would be a "stop-gap" measure to provide me this capability pending
> what I thought would be the soon-to-come arrival of a similar
> architecture written by someone with better software expertise than I.
> Unfortunately, that follow-on software has not arrived :(
> 
> Thus, the purpose the this email is to implore the "big boys" to
> consider implementing such an architecture as the basis for one or more
> of their exciting new projects.
> 
> My implementation currently handles up to 8 remote servers, any two of
> which can be "live" with full Tx/Rx capability at any one time, and all
> 8 of which have spectra/waterfalls continuously and simultaneously
> displayed by the client.  I would think that any new implementation
> should at least provide this level of capability.
> 
> My code is ragged and certainly should NOT be the starting point for a
> new project going forward, but the images of it at the URL below will
> explain what it does (and what the minimal capabilities of a new project
> going forward should be):
> 
> http://www.nitehawk.com/w3sz/CSharpsdrclientANDserverVersion2pt0.html
> 
> Such an architecture should also have Multiple CAT ports and multiple
> audio ports so that it can simultaneously work with a logger such as
> N1MM+ in SO2R mode, and at least 2 instances of WSJTX.  See:
> 
> http://www.nitehawk.com/w3sz/ServerIPWindow.png
> 
> and
> 
> http://www.nitehawk.com/w3sz/AudioDevicesSetup.png
> 
> It should also provide audio compression using something like the OPUS
> encoder/decoder to reduce the necessary bandwidth between the servers
> and the client:
> http://www.nitehawk.com/w3sz/OpusCodecSetup.png
> 
> Of course, with such a system there are NO physical connections to the
> radio for mic audio, receive audio, CW key, etc.  All of those are
> handled over the Ethernet connection between radio and its associated
> server-computer.  The only connections to the radios are [1] power, [2]
> Ethernet, [3] PTT out, [4] Receive RF in, [5] Transmit RF out, [6] 10
> MHz in, and [7] 10 MHz out.  In my implementation each server has its
> own server-computer, but that is not an essential feature of the design,
> and allowing a sufficiently powerful server-computer to handle more than
> one radio would be a nice feature.
> 
> Here's hoping that someone gets the ball rolling on this, and thanks to
> Scott for bringing this up!
> 
> P.S.  If you too would like to see a local client / remote server
> architecture that would intrinsically provide remote operation
> capability, it would be a good idea for you to post that here, so that
> any potential developers can get an idea of the interest level that
> exists for such an architecture.
> 
> 73,
> 
> Roger Rehr
> W3SZ
> 
> 
> 
> 
> _______________________________________________
> 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/
> 

-- 
  ¯\_(ツ)_/¯