[hpsdr] Developers: Don't Forget Local Client / Multiple Remote Server Architecture

[Roger Rehr W3SZ]

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