I’m Andrew KC2G. For the past 3+ years I’ve maintained nDAX and nCAT, tools for making Flex-6000 series radios useful on Linux. nDAX does the virtual audio pipe thing, and nCAT puts a rigctld-compatible face on Flex’s TCP/IP API. Together they’re enough to let anyone use WSJT-X, fldigi, FreeDV, etc. easily and reliably.
But every now and then someone asks me about a full GUI client (a “SmartSDR clone”), with the waterfall and the full set of virtual knobs for rig controls. I know all of the protocol stuff necessary to make that happen, but I’m simply not a GUI dev. There’s no way I could pull it off.
But today it hit me — wfview is already almost exactly the GUI that people want, it’s open-source, and it’s cross-platform. Could I make it play with Flex?
There are three ways I could think of trying to do that:
I could just fork wfview, replace Icom protocol support with Flex, and release it as a separate program (with due credit given, of course).
Same as #1 except I work closely with the wfview devs to make it fully support both kinds of radios and integrate that support upstream.
I write a proxy of sorts that speaks the Flex protocol on one side and the Icom protocol on the other side, and then wfview could connect to my proxy thinking it’s an Icom. From my previous experience with RS-BA1 I believe the Icom protocol is basically CI-V over TCP plus audio over UDP, plus some kind of session protocol to set up the UDP. That might be out of date though!
Any thoughts? Any interest? I know it’s a little out of left field, but once the idea occurred to me I couldn’t ignore it.
Adding support for multiple protocols/connection types is on my todo list and this includes the Flex SmartSDR API (as I also have a 6500). This is based around the work I am doing to remove all of the hard-coded ‘Icom’ commands from wfview in my development branch.
My plan is to use the rigCommander class as a base and then create a number of different child classes for each protocol. Obviously the only one at the moment is Icom C-IV, but the ability to add other protocols shouldn’t be too difficult as the interface is pretty generic. (I just have to finish Icom rigs first!)
Thank you. Please let me know if there’s anything I can do to help when you get there — I’m pretty familiar with both the SmartSDR API and the VITA audio stuff.
In the meantime I might play with the proxy concept just for fun, but having it native in wfview is definitely the better option!
There exists a SmartSDR clone for Mac OS written by K3TZR. Other than the fact that he hasn’t finished implementing the transmit functionality, it seems to work extremely well. Perhaps he would be someone to tap for work to merge in Flex-6000 operability into wfview? If nothing else he might be a great resource for someone who is doing so that needs questions answered. Lord knows that the Flex6k platform needs free software alternatives. One would think it a boon for Flex to “get on the good foot” and make developing software for their products easier. I think that their internal documentation is incomplete and out of date. That is my recollection after going down that rabbit hole maybe a year ago.
The Flex protocol is pretty simple (rig commands basically use an extended Kenwood protocol). The main issue is the sheer amount of work involved in re-writing the wfview rig handling code to do anything other than Icom commands.
I am quite far into this process, and once it is ready for release, supporting other manufacturers is next on my list.