[hpsdr] Software direction for openHPSDR...

[Jeremy McDermond]

I have a lot of mixed feelings on this subject that I've exposed to a few people before.  I'll try not to rehash a lot of ground that's already been covered.

On Aug 3, 2010, at 4:38 AM, Ken N9VV wrote:

> They were fully portable and would easily compile with MinGW/OpenGL/Qt on Windows and Linux. Their GUI was really cool. The use of OpenGL pushed the GUI load out to the video card and made the whole system very efficient for small CPU systems (mITX for example) and remote Internet users.

MacHPSDR uses OpenGL for both the waterfall display and the panadapter.  The waterfall is actually 4096 pixels wide, and OpenGL scales it to whatever size the view needs.  This corresponds to the 4096 bins of the FFT used to create it.  The same thing goes for the panadapter, it's larger on OpenGL than it is on your screen.

That being said, even with those optimizations (which are far from perfect, and MacHPSDR hasn't been extensively profiled or anything), the biggest contributor to the load on the system when I look at it with Instruments is the AGC code in DttSP.  It's structured such that doing any kind of parallelization of it isn't particularly easy.  I have to look at the problem more when I have some more brain power.

The code to these is released under the GPL, and the OpenGL itself is straight C.  Any of the other projects are welcome to borrow from them.  Extending them to do larger FFTs wouldn't be particularly difficult.

> The pressure is increasing to have portable code for the OpenHPSDR hardware project if we want to remain an attractive experimental platform for the future.

I have problems with the idea of portability for a few reasons.  I find myself in a weird position because I'm usually a big booster of multi-platform stuff.  The problem that I've thought about heavily and have been struggling with lately is that cross-platform GUIs, in general, have severe usability concerns.  I can pretty much pick out cross-platfrom toolkit programs on the Mac just by looking at them. They violate most of the UI rules set forth for the OS, and they feel like either a Linux app or a Windows app that's been shoehorned into the Mac paradigm.  This really makes for a poor user experience.  The programs that I've seen that are cross platform and have good user interfaces on the mac have eschewed cross-platfrom widget toolkits and made significantly divergent UI code for the different operating systems.

I'm all for consolidating the backend goo as much as possible, and trying to share code, but not at the expense of usability.

On August 3, 2010, at 12:39 AM, David McQuate wrote:

> I'd like to nominate John Melton's ghpsdr3 server as one of the blocks in a modular software system for HPSDR.  It's written in pure C, so can potentially run on any OS.  With a few fixes it compiles both on Linux and on Windows (Visual Studio).  It may be possible to port it to MinGW on Windows.  (Does Net Beans do C / C++  ?)  The server takes care of all the hardware-dependencies, and handles multiple simultaneous receivers.  It does this by de-multiplexing the I & Q data stream sent over the USB by Ozy, and sending the I&Q data to independent DSP modules using UDP ethernet packets.  It recognizes a few commands that allow it to send control data back to Mercury.  It also sends audio to Ozy / Mercury for headphone / speaker output.

But the problem with the server is the USB interface, which is its main job.  libusb has performance issues on the Mac, which is why I started coding in the first place:  ghpsdr had problems with performance.  There are also the problems that we had with libusb on Windows as well.  I know that some of the guys developing GMSK node adapters for D-STAR on Windows have had problems with libusb as well.  Given that dependency, you're really at the mercy of the quality of the libusb code for the quality of the server.  Again, partially like the GUI issue, you do a cross platform USB driver that tastes a lot like Linux, and consequentially only really works well on that platform.

Additionally, it prevents some kinds of innovation in the hardware interface layer.  For example, MacHPSDR has an integrated firmware loader that automatically detects when an Ozy/Magister is connected, and makes sure it has the latest firmware bundled in the application.  If we're just going to use John's server straight, that prevents this sort of advancement.

I like the idea of using John's components as reference implementations and specifications of the on-the-wire protocol.  That being said, I would really like to see the ghpsdr3 on-wire protocol match whatever we're going to develop for Ozy II.  This way an Ozy II and a ghpsdr3 server can be interchanged.

In that spirit, on my project list is a "ghpsdr3 compatible" low level IO daemon for the Mac that I've dubbed Ichabod.  It'll be a natively installable application that will have a preferences panel for control and background launching.

I think that we may also run into issues when we go to a networked architecture to talk to the hardware.  Most of the example projects we're looking are receive only.  I'm afraid that we might run into problems with the CW crowd and making QSK work correctly.  I'm just wondering whether the latency through the network, in addition to the network stack of the operating system, is going to be too much for the CW folks on the transmit side.

I think we'll just have to try it out to see if it works acceptably.

I also agree with Ken that John's GNU Radio module has a lot of potential for folks to be able to put interesting things together, and I'm kinda surprised I haven't heard of anyone trying it yet (I'm probably as guilty as anyone else).

I hope nobody takes this as sniping and destructive criticism.  It's meant to be a frank assessment of what I see about the state of software for OpenHPSDR and the problems that need to be considered and overcome.

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com




 1280841573.0