14 October 2016

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...


  1. John

    Why Windows, and not Linux?

    Mike G0GJV

  2. Hi Mike,

    It was good to see you at the convention and catch up on your news.

    Why not Linux? I have never been able to get on with Linux! Numerous times over the past decade I've looked at it (briefly it must be admitted) and been deterred by the need to do so much everyday stuff via a command line interface. We stopped doing that 20+ years ago in the Windows world. Add to that the often poor, though admittedly improving driver support for things that I find useful and it becomes just too much hard work.

    I will be the first to admit that this is a bit of a cop out. Apart from a very brief period in my early 20s I have never programmed professionally, so everything I do has been learned in hobby mode. I've settled on a windows-based Delphi XE development environment that lets me do everything I want to do, so I have little need to consider Linux, or other alternatives.

    This might change in the fullness of time. I dislike W8 and am positively antagonistic towards W10. When it becomes no longer possible to continue with W7 (note: I held out using XP until really quite recently!) then I will look at Linux again and see what the options are at that point.

    Meantime, it's Windows and Delphi XE for me.

    73, John, G3WGV

    1. Ok John, much as I expected! I've similarly held out against Linux until relatively recently, when I've been forced by having to use it professionally.

      It can still be a bit of a pain, but its a lot better than it used to be; it also works on little machines (e.g. Raspberry Pi, and the ARM based udoos). I've now moved off C++ Builder (the C++ equivalen. But of Delphi) and I'm using Qt - free, and in many ways better, and mostly seamlessly cross platform. I know you prefer Delphi to C/C++; is Lazarus (I think thats a cross platform Delphi look alike) a possibility?

    2. Yes, I think if I had a professional programming background then I too would be on Linux, C/C++ et al. When I programmed for a job it was all in assembler! I suppose I am getting used to C now, as I have written quite a large body of code for the Arduino in C. I still prefer Delphi - somehow it just seems more readable to me although that it most likely because of greater exposure to it.

      I looked at Lazarus in considerable detail a couple of years back before upgrading from my venerable Delphi 6 to Delphi XE7. It was pretty good but fell by the wayside because of poorer component availability, e.g. networking and, especially, database support, which I needed for my logging software.

      Another consideration in all this is that processing power is now dirt cheap, so there is little incentive to worry about running a lightweight O/S. I quite liked the Arduino because it is essentially a bare metal machine but I haven't really adapted to the RPi. I do have a few kicking around here from various experiments.

      73, John, G3WGV

  3. Anyway - keep going, it all looks interesting, even though I'm not likely to get a Flex!

    Mike G0GJV