Operational evaluation

"No battle plan survives contact with the enemy" - Helmuth von Moltke

So, it seems, it is with homebrew FlexRadio controllers! After almost a week of hands on operation, in which I've made a good number of DX QSOs and a bunch of contest QSOs in WAE, I can expand on this basic premise in the Flex controller context as follows:

1. For the most part the controller works well
2. There are numerous minor tweaks that will make it work much better
3. There are clear limitations in a network controlled radio that are either not apparent in traditional radios or, at least, are much less pronounced
4. There are performance issues that seem to indicate that a Mk II controller with a more powerful processor will be needed sooner or later

There's always a risk that one becomes overly critical at this early stage in deployment, so let's say right up front: it works. In fact it works very well. I can happily make QSOs with it and the controller feels quite comfortable in use. The panel layout works and the integration with my logging program and SSDR is just fine. I should also add that there is a real feeling of satisfaction using this controller, akin to the feeling I recall from my youth, building and then using top-band transmitters.

So to my mind, the concept is validated. There are no show stoppers. Yes there are improvements that can and indeed must be made but, hey! it's software - we can do this.

I think the biggest issue is also the controller's biggest asset - its sheer flexibility. Since any physical control can be assigned any function, it follows that there is no fixed relationship between control position on the panel and its function. Thus, there is no point in labelling the control - it is whatever we want it to be. But this carries its own set of problems: "what is that control doing right now?" Or from another perspective, "where is the control to do ...?"

Exacerbating this issue is that the encoders have four discrete functions, arranged in two pairs. One such control is the volume control for VFO-A. The shifted function is audio pan - well at least you'll soon work out what's going on if that's selected instead of audio gain. However the second pair, as currently configured is TX power and tune power. I have lost track of the number of times I have tried to adjust the audio level, only to find the control wasn't doing that - it was winding the Tx power up and down!

Well, that can be fixed in a number of ways. The obvious approach is to avoid silly control combinations like that! I also think that I'll try a time-out for the second function pair, perhaps 10 seconds, so the control always returns to the primary function set automatically.

Anyway, I have a little list and I shall be working through that over the next week or so.

The next point is more fundamental. For all that we have blindingly fast networking and unlimited processing power these days, the fact remains that it takes a finite amount of time to move commands and data across the network and then process them. This is most noticeable with VFO tuning, where if you tune quickly then the radio misses a few steps in an attempt to keep up. This has the effect of sounding like the step has changed and instead of the CW note varying smoothly as the dial is turned, instead it moves in distinct steps. A bit like the very early synthesiser radios.

It's not clear to me yet whether this is a network speed issue or a processing limitation... or perhaps both. It's not terribly important but when one has been used to a nice radio like the FT5000, it feels like a bit of a step backwards.

And that brings me neatly onto the last point. Processing power. I'm increasingly coming to the conclusion that the Arduino Due (the most powerful in the Arduino range) is just not quite powerful enough for this application. I see this in various ways: the VFO tuning issue I mentioned above, a tendency for the display to get behind and start showing gibberish, slow response to the more complex rotary encoder functions and so on.

I'm not saying that the current set up is inadequate but I just have a feeling that I need more power. The only way to find out will be to try something bigger and as I have discussed on several occasions, the Udoo X86 processor seems to be an ideal test bed. As I'll not be able to get my hands on one until December, I have plenty of time to continue making improvements to the Mk I controller!

Anyway, this has been a most excellent and useful exercise. I plan to continue with a mixture of software development and hands on QSO-making and see where that gets me to.