Quo vadis?

As I've said before, my software projects never really finish. There's always another must-have just over the horizon and so it is with my controller project.

I've previously discussed the idea of moving to an X86 and Windows-based solution but without any real analysis of why that might be a good thing. It turns out that the Mk I, Arduino-based controller does a great job, as far as it goes, so there need to be other drivers for change.

Mk I controller 
The Mk I controller has all the control functions that one might reasonably need physical controls for. It has a decent 5" touch screen that displays all the things anyone is likely to require except panadapter and waterfall. The controller can operate standalone or in conjunction with SSDR or the Maestro. Of course, in standalone mode there is no panadapter/waterfall, which limits its usefulness (once you've got used to them you'll be loathe to manage without).

The Mk I can't operate via WiFi - it requires a wired Ethernet connection. This is primarily because of weaknesses in the Arduino WiFi libraries, which don't play nicely with other services using the Arduino SPI interface. I could probably fix this if I put a load of effort into the driver code. The lack of WiFi means that /P operation, say in a hotel room, is not feasible.

My original design proposal for the Mk I controller was as a base station controller operating in conjunction with SSDR. It does this job admirably but has major limitations in other environments.

Mk II controller options
For the moment, I will assume that the Mk II will be windows-based, on an X86 platform.

The move to an X86 platform will make development and deployment far more straightforward. The Arduino ecosystem is not really designed for complex projects like this. Factors include the rather poor (and slow!) development environment and the lack of any proper quality control over essential libraries, which makes for tricky problems that shouldn't really exist. The Arduino platform was great for concept development but it's not really the way forward for the bulk of the controller.

As it happens, the Mk II controller will almost certainly still have an Arduino component. The Arduino is particularly good at supporting lots of I/O and that is definitely needed for the control interfaces. This is a comparatively low level requirement so the code should be very simple. An obvious solution is the Udoo X86 board, which has an Arduino processor built in. A standard X86 machine, with an Arduino connected via its serial port would work just as well.

I see two possible directions of travel:

1. Same functionality as the Mk I but with the addition of WiFi
2. A full controller that replaced SSDR completely

Option 1 is not particularly exciting although it does overcome a significant shortcoming of the Mk I. It would also be possible to run the logging software and other station control functions on the same processor, with a fairly useful reduction in station complexity.

Option 2 would be much more fun and, of course, far more complicated. In this option, the controller will fully support panadapter and waterfall displays and, by inference, a big enough subset of SSDR's functionality to render SSDR no longer necessary for day to day operation.

The issue here is that in any one set up you can, practically speaking, only have one panadapter/waterfall display per radio. This is because the radio itself does all the display sizing, so all displays must have the same pixel sizing. I suppose one could scale the display downwards but the results would probably look pretty awful. There is also talk of FlexRadio supporting more than one display in due course but time scales are elusive.

Now, if I do my own panadapter/waterfall then all sorts of interesting possibilities start to become apparent. For example, I could overlay the panadapter with call signs obtained via packet cluster, RBN or a local Skimmer. With closer integration between logging and controller software I have no doubt that there would be other fun things I could do.

Option 2 would, in normal use, not work alongside SSDR, although I could code an option to have the controller run in "control mode" where the panadapter/waterfall displays were disabled, permitting SSDR to be run. I think this might be necessary, as I suspect that software updates and other maintenance functions are likely to require continuing ability to use SSDR occasionally.

What to do?
Perhaps unsurprisingly, I am tending towards option 2 in the long run and, of course, a move to the X86 platform will be an essential enabler for that. In the short term I think the first task is port my Arduino code to the X86 environment (option 1) but with an eye on the bigger picture to avoid making any design decisions that might prejudice option 2 in due course.

I feel a winter project coming on...