Integration II

The past few days have seen more progress on integrating the FlexRadio system into my station. I've now completed the integration with my logging program StarLog and all the numerous radio control functions are working as far as I can tell. Of course the proof of this will be actual use - there is only so much testing that one can do, it has to be used live.

I've started thinking about documentation and, notably, my upcoming presentation at the RSGB convention in October. It occurred to me that the overall architecture will be conceptually new to many people, so that's a good place to start.

A fundamental concept is that the Flex 6000 can support multiple clients. In my case I have three:

• Smart SDR (SSDR), which provides the graphical interface - waterfall, pan adapter, etc.
• G3WGV Controller, which provides the physical user interface
• StarLog, which is the logging program interface.

Each of these operates essentially independently, the only connection between them being the radio itself, which we can consider to be a server. So, for example, if the controller tunes the radio then messages are sent to logging program and to SSDR so they can update their settings.

Between the FlexRadio and each of the user clients there is an Application Programming  Interface (API). These serve as an interface, driving the radio protocol on one side and providing data in a structured fashion to the application. Somewhat similar to the familiar concept of device drivers.

Each of these API/application pairs can reside in a separate physical computer, or, indeed, be run together on a single platform... within reason. The SSDR application, in particular is fairly resource intensive and requires a fast PC. StarLog is another substantial Windows-based application. Conversely, the Mk 1 G3WGV Controller runs on a lowly Arduino.

Which brings us neatly on to what computing platforms to use operationally. At the moment my station logging program runs on a 2009 vintage laptop, which is just about adequate for the task but quite certainly will not be able to take on running SSDR as well. I like using laptops for logging because the computer is on 24x7. Laptops have relatively low power consumption and also have a battery to tide over any power outages.

One solution may be to simply get a more recent and thus more powerful laptop. However, I am now looking into a more bespoke solution using a relatively new "maker board" the Udoo X86.

This is a most interesting new board. It is a powerful Quad Core Intel X86 system that will run Windows and support multiple full HD screens, etc. It should be easily able to run StarLog and may also be able to run SSDR concurrently. But more interesting even than that is that it has a built in Arduino compatible processor.

Why is this interesting? StarLog, amongst other things provides control of antenna selection via four digital I/O pins that send a 1 of 16 antenna selector signal to an antenna switch at the base of my tower. This means that I never have to select an antenna, nor do I have piles of coaxial lines running back to the shack and manual coax switches. Just a single LDF-450 cable. Handy!

At the moment I deliver this via a USB to parallel port interface unit. It works but it is rather untidy and is a bit of a challenge to get working after a computer restart. With The Udoo it would be simplicity itself to code this into the Arduino section and have a single board unified solution.

I also have a MicroHam microKeyer 2, which while it is a nice piece of kit, for me it serves only to be a WinKey keyer and an easy way to interface audio into StarLog's QSO recorder. Long ago I wrote an Arduino WinKey emulator that could run on the Udoo and with with the Flex system there is no longer the same issue with audio sources, so I could manage without the microKeyer.

I don't yet know whether I could also run SSDR on the same Udoo board. There's no problem from a connectivity point of view, it's mainly going to be about processing power. Also in the TBA category is whether I could run a "Mark 2" G3WGV controller on this set-up. Here the issue is connectivity - I need lots of I/O pins to support the encoders, switches, etc. The Udoo is rather short of these compared to the Arduino Due. A solution using multiplexing might be feasible... another thing to look into.

Anyway, however it works out, the Udoo board is definitely worth investigating and I have one on order. The only trouble is that it won't be available until December. Looks like a winter project to me!