First release!

The wait (if indeed there was such a thing) is over! I have today uploaded version 0.002.00 of the controller code and supporting libraries to the Mk1 downloads page. There is other useful information on the other pages that should help you get the code running.

This source code is made available completely free of charge as a service to the amateur radio community and is released under the terms of the CC BY-NC-SA 3.0 license. https://creativecommons.org/licenses/by-nc-sa/3.0/.

Please note most carefully that this is an alpha trial version. There are almost certainly bugs yet to find and just because it works in my development/station environment doesn't mean it'll work for you. But as I think the likely audience will be computer literate Arduino fans who can do their own software development and maintenance, I am hoping this will not be a problem.

There are certain hardware and software dependencies that I have tried to document as I have gone along but I may have missed something along the way. What I hope for now is that you will be able, if you so choose, to compile the software and upload it to your Arduino Due. As you'll have quite a lot of hardware to build as well, that's probably about the best I can do for now.

My real hope is that this project and the release of all its code serves as a stimulus for others to take up the challenge and write more - and almost certainly better - code. I make no claims to being a C programmer, in fact I rather dislike the language, but it is the Arduino language of choice and needs must. I'm sure someone with better C credentials will be able to make something far better.

One final request:

Maintaining this Blog and writing the software in such a way that it can be let out on its own has been a considerable undertaking. I am happy to do this as a service to the amateur radio community.

If you do download the code and, in the fullness of time, start using it, please do let me know how you get on. Even if you don't plan to use the software but you find the Blog interesting and informative, please tell me. I always appreciate comments to my Blog posts, so please don't just take and give nothing back in return!

Miscellanea

A few titbits whilst I think of them...

RSGB HF Convention
My presentation, "SDR with knobs on!" is provisionally scheduled for Saturday 8th October at 11:45 in Lecture Room 5. Of course that might change, but that's the plan for now. See you there?

I'm particularly pleased to discover that the CEO of Flex Radio will also be presenting at the convention. I'm looking forward to hearing what he has to say!

Mk1 information
You'll note that I have started a new page with some details about the Mk1 controller. There's not much there just yet but I plan that this will develop over time, with the intention that it should contain helphul information for anyone who would like to build their own controller.

Downloads
Nothing there just yet but I will eventually put the controller code up there for you all to take a look at. Please try not to be too disparaging about my C programming skills:)

Is there anyone there?
Not getting much in the way of engagement from you Blog followers! Perhaps you've all gone away and I'm talking to myself. It would be nice to know if anyone is still QRV.

Improving the UI

With the 6500 back in service I have been able to add some further functionality to the Mk1 controller. In particular, I was keen to improve the user interface following on from early experiences before the radio went on vacation.

What's the control doing?
Each rotary encoder can have up to four discrete functions and it's useful to a) be able to see what exactly it is doing and b) what the current value is. I quite like the way in which the Maestro has done this with a pop-up that says what the control is and what the current value has been set to. So I've implemented a similar pop-up on my controller. A yellow bar pops up whenever a control is changed, as you can see in the picture.

In this case I have just tweaked the VFO-A width control. As you can see, the pop up shows the value and also, rather neatly, units (Hz in this case). The pop up stays there for one second, which is, I think, long enough but that is very easy to change.

Which control set am I using?
I referred earlier to the problem with switching between the main and secondary set of encoder functions. I decided to try my idea of having the secondary set "time out" and return to the primary set. This really seems to work. I've not had any difficulty with tweaking the wrong control since I did that. I think that it's here to stay, although I might make it a user option.

What button do I want?
Since any button can be configured to perform any function, it is a good idea to be able to easily find out which button is which. So I now have a screen display that shows this

It remains to be seen how useful this is. In discussions with a few others I'm coming to the conclusion that it might not be too much of an issue - people learn where the controls are quite quickly.

More hands-on testing required. It's a pity that conditions are so poor today!

The radio returns

My Flex 6500 has returned from its second vacation in Germany this year. This wireless is getting to be better travelled than I am in recent times!

I also have a new (to me) laptop with a 240GB SSD, 8GB of RAM and a quad core I7 processor. It's able to drive multiple screens and my plan is to make this my new station logging/control machine. I already have it running SSDR and it seems to work just fine. I just need to do a bit more work to get all the other stuff I use loaded and working. A job for the weekend I think.

While the Flex was on vacation, I added a lot of new code to my Delphi-based Flex API. This now should, in principle, support all the events and control functions that the Flex Radio API offers. Inevitably there were some minor bugs to iron out but this new version is now working well with my logging software.

The plan now is to get my station back up and running with the new PC and the Flex 6500, so I can continue evaluation and development work. It's probably getting close to time for me to start thinking about my talk at the RSGB Convention and before long I'll need to decide how to make the code and hardware design available to others who may want to make something similar.

Plenty to be getting on with!

Radio fixed

Again!

I heard today that my Flex 6500 has been fixed and will be on its way back home next week. That's great news and I am looking forward to cracking on with operational evaluation, aka making QSOs.

I've not been completely idle in the past week. Apart from making full use of the nice weather by getting lots of flying in, I have also added significantly to my Windows API code. As I now expect this to form the basis of the Mark II controller, there is quite a lot of additional functionality to implement. It'll be several more months before I can start work on the Mk II controller in earnest as I have decided that the hardware platform will be the Udoo X86 and I won't get my first sample until December.

Hopefully I shall have the 6500 back before the end of the week and I will write more then.

D'oh!

Back in April my Flex 6500 developed a rather odd fault which resulted in the radio being very deaf on 21/24/28MHz. This turned out to be a fault in the front end amateur radio band filter switching - when I set the radio to "Wide", i.e. taking in more spectrum than the amateur band, it was OK. Away the radio went for a vacation in Germany (the European Flex repair facility) and when it returned from its sojourn all seemed to be well.

Last week the fault returned. I suppose, in reality, that it was there all the time (perhaps intermittently) but as I was busy writing software rather than using the radio for making QSOs, I just assumed that the bands were a bit on the dead side. Anyway, the fault seems to be "hard" and, to give FlexRadio and the UK distributor their due, they have acted very quickly to sort it out.

So my software test-bed goes away to Germany again tomorrow and I have another couple of weeks of limited development capability. All is not lost - I can still work on parts of the code that don't directly interact with the radio. And, to be honest, I really ought to be making a start on my presentation for the RSGB Convention in a couple of months' time.

Hopefully when my 6500 comes back from DL it will be 100%, as is the general reputation for these radios. Meanwhile, updates to this Blog may be a little less frequent. I'm off now to make a few more QSOs before I have to pack it in its shipping box.

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.