[hpsdr] Software direction for openHPSDR...

[Thierbach, Ed]

Although that design is very flexible, it makes for a complex system for the person who just wants to connect their computer to their SDR.  

In that case (which seems to me like it's the common case), it creates an extra background task/system service/daemon or two, and it inserts network plumbing where no networking is really needed.  Shutting it down would be more than just quitting the program; the user would also have to terminate the "SDR server" process.  I can imagine plenty of cases where a reboot might be the only way to clear an error condition.

Perhaps a plug-in architecture could take care of both the direct-connect case and the more complex network-connect case.  The main program, with the front-end GUI and the DSP engine(s), could have two types of plug-ins.  The "device plug-ins" would connect the GUI to the radio -- a plug-in for a locally-attached HPSDR, another one for a network-attached HPSDR a la ghpsdr3, and others could be developed for other SDRs.  The "mode plug-ins" (gotta come up with a better name) would handle TX/RX modes not contained in the base software, such as PSK, RTTY, SSTV, DRM, and so on.  I could see some fairly complex ones, like ACARS or ALE.   I'd keep the standard mode handling (like CW, SSB, AM, FM) in the "base package", since the other plug-ins would likely need to make use of them.

Just a thought.  In the meantime, I'm quite happy with the "Pretty Betty" HPSDR port, and I hope to be able to give ghpsdr and ghpsdr3 a try soon.

73,
-Ed- AB8OJ

> The best design practice is to completely separate the GUI from the
> processing logic.  If the processor and GUI talk over a socket then
> you gain several things
> 1) The two sides are independent programs and each can be written in a
> programming language that makes sense for the task
> 2) Sockets can connects programs on the same computer or across anetwork
> 
> As computers get more powerful and cheaper, some day you will be able
> to hang the DSP computer on the antenna and connect it back to the GUI
> using a fiber optic network cable.
> 
> The idea is not new there are already several Java based GUI front
> ends for dttsp
> 
> 
> --
> =====
> Chris Albertson
> Redondo Beach, California

 1280861483.0