GMDX Convention

I'm pleased to advise that I have been asked to speak at the GMDX Convention without hesitation deviation or repetition, on the subject of SDR with knob on.

The convention is at its usual venue in Stirling on 1st April 2017. Rob 'YTS has promised me that this is not an April Fool's joke!

See you there?

Christmas present!

Firstly, a belated Merry Christmas to my many followers and my best wishes for a Flex Controller filled new year.

Apropos of which, I have been quietly adding information to the Mk II controller pages (see above). There's a lot more to write yet but I hope you find what's there interesting, informative and useful. As always, your comments are greatly appreciated, in the comments section below please.

What does it cost?

I've been asked a few times recently what sort of costs are likely to be involved in building the Mk II controller. To a large extent this is down to the builder's preferences - you can spend a shed-load of money on nice cabinetry, professional panel cutting, etc. The actual underlying hardware is relatively inexpensive.

I've done a quick costing exercise for both mini and maxi controllers. The midi, if anyone would be interested in one would be somewhere in between. This is what it looks like:

These don't seem unreasonable prices, compared, say, to a Maestro. Of course the Maestro does rather more - it has a panadapter/waterfall display and built in features such as keying that would be separate costs on the 'WGV controllers.

Eventually I will have to start thinking about PCB production and that, dear reader, will be the point at which you'll need to decide if you want in or not!

Visalia 2017

*** BREAKING NEWS ***

I have been asked to reprise my SDR with knobs on! presentation at the International DX Convention, Visalia, California in April next year. Of course it won't be the same presentation because things have moved on quite a bit in the meantime. Further information when I have it. See you there?

Mini - Midi - Maxi

I've been busy over the past ten days or so defining the characteristics of different styles of controller and thinking about the software implications. The overriding requirement is that a single executable should be able to work in any physical layout.

This is not as easy as it might seem!

Controller definitions
Tempting though it might be to have a complete free-for-all common sense dictates that we need to define some standardised configurations. After quite a lot of thought I have concluded that these are they:

• Mini controller. One physical VFO, up to four encoders and 16 switches.
• Midi controller. Up to two physical VFOs, up to six encoders and 32 switches.
• Maxi controller. Two physical VFOs, eight encoders and 32 switches.

Each controller type is able to manage up to two slices, so all controllers are effectively dual VFO rigs. The maxi controller is effectively the Mk I controller physical specification and I can't see that there is a need for anything larger. An interesting thought is that there should be no particular reason why one couldn't have more than one controller per radio, with each controller taking its own, unique pair of slices. A sort of grown-up version of little knob/big knob operating!

Software considerations
Until a few days ago all my development work had been on the basis of what we now know as the Maxi controller. Thinking about the Midi and, especially the Mini controllers made me realise that there was a need for a new class of encoder and switch controls.

The Mini controller and, potentially the Midi controller have only one physical VFO. As we wish to control two slices, we need a switch to select which slice the VFO knob is controlling at any one time. I soon realised that this is also true for encoders and switches. For example, I have a switch definition that allows the user to lock VFO-A and another switch to lock VFO-B. In a maxi controller this makes complete sense but less so in the Mini controller, where we may feel that we can ill-afford the space for two physically separate switches.

The answer, of course, is to use the VFO switch to also switch all these other switches to operate on VFO-A or VFO-B, whichever is currently selected. The same logic applies to the encoder functions.

So, using the VFO lock as an example, we actually have three potential functions:

• Lock VFO-A
• Lock VFO-B
• Lock selected VFO

The same applies for encoders. Using filter width control as an example we have the following functions

• Filter width for VFO-A
• Filter width for VFO-B
• Filter width for selected VFO

By having three functions defined for each control type we have total freedom to implement separate controls or common controls for the two logical VFOs as required. 

Which VFO have I selected?
So we now have a switch function that permits the user to map the physical VFO to either VFO-A or VFO-B. It's obviously rather important to know which VFO is selected and I've spent some time thinking about that too.

A single VFO system operating in split mode,
with the VFO controlling VFO-A

In the end, I've decided that the best way to show the current VFO is to highlight the VFO frequency display by underlining it. This immediately grabs the attention. Of course the underline is only needed in a single physical VFO configuration and even then only when both VFO-A and VFO-B are active. It seems to work very well.

Profiles
Finally, and in a related development area, I've now implemented user selectable profiles. This lets the user change the layout of his controller at will. In fact it is the way I tested the mini controller controls - switching between a maxi controller and mini controller configuration simply by loading a different profile.

Of course the profile manager also had to be updated to know about the new class of switched VFO controls. That too seems to be working well.

All in all a lot of progress along the way to a single Host Controller code set that can support any controller configuration.

Mk II progress report

I've not been posting so much recently, in part because I've been busy with other things but also because I get no feedback these days and have no idea whether anyone is even tuning in any more. It takes some effort to maintain the Blog, so if you want it to continue please do say hi from time to time.

Anyway, various components that I have been waiting for have finally arrived on the slow boat from parts forrin and that means I can get on with the hardware side again. In particular, the arrival of a pair of high resolution VFO encoders has enabled me to finally demonstrate that my design concept of having a separate Arduino I/O controller is OK. Although the maths suggested that latency issues would be insignificant it's not until I can try it out for real that I feel confident that I've really achieved proof of concept. The practical  upshot is that tuning latency on the Mk II is not noticeably different from any other tuning method.

I also have the right angle HDMI connectors and that means I can get on with PCB design. I'm hoping that my PCB designer friend and I can get together early next week. Most likely I will commission both full-size and mini controller PCBs.

Meanwhile, the software side has been moving along OK, albeit at a somewhat slower pace. There is a limit to the amount of development that can be done without a proper hardware platform and I was getting to that point. I have, however, added quite a lot of back-end code, notably the ability to support up to four Flex 6000 radios on a single network and select as required. This and other developments have added quite significantly to the capabilities of my API interface middleware, making it a more complete proposition.

The more I get into the Mk II development the more I am convinced that this is the correct architecture, especially as a platform for others to implement their own controllers. The Mk I depended too much on specialist Arduino capabilities and numerous libraries that were difficult to get working in harmony. In the Mk II the Arduino code for the I/O Controller is extremely simple, requiring nothing specialist at all. The Windows-based Host Controller can be packaged up in a way that makes it appropriate for a turnkey approach, with the code delivered as an executable and local configuration to match the specific hardware.

It would be interesting, therefore, to hear from anyone that is still interested in the possibility of rolling their own controller based on the Mk II.

Programming the API

Over on the FlexRadio community I was encouraged to write down my experiences of programming with the FlexRadio Smart SDR Application Programming Interface. The result is a fairly extensive document that has been reviewed by FlexRadio technical staff and is now available on the FlexRadio Wiki.

If you are interested in writing your own interface code or would like to better understand how my controller works then you may find it interesting. Definitely for software geeks only :)

Coding progress

I've had a pretty productive week on the Mk II controller software development front. The display panel is now more or less finished:

The layout is more or less identical to the Mk I screen, for the simple reason that it seems to work nicely from an ergonomics perspective. There are a few nice new features that were easier to implement in Windows than as native Arduino code:

• The mute and lock indicators are now small icons that show the status graphically rather than in words.
• The filter display is dynamic - its shape varies as the filter width and shift controls are used. This took a surprising amount of time to write!
• Band and mode selection is now much neater, with a nice pop-up window...

This is brought up by pressing the programmed band/mode switch or by clicking on the mode indicators in the main screen. Band/mode selection is achieved by clicking or touching on the relevant pad.

Pretty well all the code behind the screen is now completed, so I am now somewhat ahead of myself in software terms and I really need to get on with the new PCB layout so I can get that into fab. Can't do that until some hardware arrives on the slow boat from the far east. Thinks... perhaps I should go and make some QSOs and stop sitting in front of this computer all day. Or go flying, or something.

Mk II PCB design

My friend the PCB designer has been busy on the Mk II design. The first task is to create a detailed circuit diagram, which can then be converted into a track layout.

This circuit has some interesting and very useful characteristics:

• It is symmetrical. The same circuit could be used for a PCB with one switch multiplexer, four encoders and a single VFO simply by removing half of the circuit. This will make it much easier to devise a min-controller in due course.
• Similarly, it is easy to create more complex boards using the same circuit "building block" approach.
• The Arduino is mounted directly onto the PCB using its header pins. No additional wiring should be required other than a USB connector to the Arduino and HDMI into the display (if fitted).

The next issue we need to address is the physical layout of the PCB. Ideally I would like to use the front panel that I am currently using for the Mk I controller. Unfortunately, the HDMI connector on the display gets in the way of the push buttons on the left side of the display. I've located a right-angled skinny HDMI adapter that might, just, provide sufficient room. It's on the slow boat from Hong Kong and until it arrives there isn't too much more we can do on the PCB front.

Meanwhile, I am adding code to the Windows side of the Mk II controller. This has thrown up the usual flurry of issues that confronts any software developer but each day a little more functionality is completed. More on this in due course.

Mk II progress (3)

And so my thoughts turn to the physical implementation options that the Mk II presents.

At a general level, it is clear that the Mk II offers far more flexibility in physical implementation, together with much less wiring complexity. I can immediately identify several possible configurations that would meet a variety of operating scenarios:

Full station controller: Effectively the Mk II equivalent of what I built as my Mk I implementation. This has a screen and two VFOs, with plenty of switches and encoders.Unlike the Mk I, the host PC could also be built into the cabinet, providing a complete station computing solution in a single package. Or, use could be made of an existing PC or laptop - the connection is, after all, just a single USB port.

Mini controller: A cut down version that could be perfect for travelling. Perhaps just one VFO and fewer encoders/switches. Still a display though. Same options for the host PC, although it seems more likely that one would use a laptop in this configuration. The controller could be put in a shallow box, perhaps a sloping panel, for ease of carrying.

Micro controller: Like the mini controller but without a display. The display would, instead, be shown on the host PC screen. Or perhaps not even displayed at all, as all the information you need would be shown on SSDR, which would have to be running in this configuration.

The upshot of all this is that a single set of code could be used to create a controller of any level of complexity, depending upon the user's requirements.

PCBs

My pal who does PCB designs for me was here yesterday. I have commissioned a Mk II PCB design with exactly the same control/screen layout as the Mk I he produced back in May. The cunning plan is to piggyback the Arduino onto this PCB, behind the display, so that there will be no physical wiring at all apart from the USB cable to the Arduino and HDMI cable to the display. This will make the controller very neat and easy to replicate. I expect to use the same approach for any other PCB layouts that I commission.

This is all very much a work in progress and I suspect it'll be Christmas before I have anything to look at. In the meantime the Mk I controller is doing a great job as my main station radio.

Mk II progress (2)

In part 1 I wrote about the I/O controller. With this working to a sufficient extent to start doing useful development on the host, that's where my attention has been for the past few days.

It quickly became apparent that there will be much greater flexibility with the host code running on a PC. The display can be anywhere you chose to put it and there can be other windows open in the application as required. On the other hand, it would be desirable to be able to operate using a small 5" screen, as before, so I have once again set the form size to 800 x 480 pixels - the size of the 5" screen.

The screen capture shows the limited progress so far. I can display the VFOs, various settings such as Tx, Tx, noise blanker, mode and RIT/XIT. This is enough for me to experiment and see whether the combination of I/O controller (the Arduino), Host (PC) and radio play nicely together. They do.

You can see that VFO-A is the RX VFO, it is locked and muted. VFO-B is the Rx and Tx VFO (a typical spit frequency DX chasing set up). It shows the split value, and the VFO is neither locked nor muted. Clicking on the various parts of the screen allows various switch functions to be initiated, just as on the Mk I controller.

Using this embryonic set up I was able to work ZL7G on 40m CW this morning. Always nice when one can use one's new toy to good effect!

There is now a lot of code to write in the host to bring full functionality to the Mk II. This will be a project for the next couple of months, perhaps more. In the meantime, I've also been thinking about physical implementation and that will be the subject of part 3.

Mk II progress (1)

The last week or so has seen quite significant progress on the Mk II design, which now seems to be a feasible proposition.

Firstly, I stripped out unneeded code, some 90%, from the Arduino Mk I project, to create an I/O controller which just collects transactions from the VFOs, encoders and switches, then sends them on a serial port. I already had most of that code, so it didn't take long to get it working. Here's the serial I/O protocol I've ended up with:

At the top is the four commands that the Arduino sends to its host. These are sent every 20ms if there has been a change. Why 20ms? The Flex radio is not happy with updates much more often than once every 20ms, so there is no point collecting data from the controls any more frequently than that.

The protocol is deliberately designed to be as light as possible. The issue here is that we want the absolute minimum time between a control being changed and the effect of that change being processed by the radio. The Mk II design has added another series element in the chain and that must be made as fast as possible. This is how, say, a VFO frequency change progresses to the radio:

Control input > Arduino processing > Command serialisation > Host processing > Network transport > Radio processing.

At 115,200 baud, say 10,000 characters per second, the serialisation delay of a VFO change command, which is 8 characters in length is about 0.8ms, which is perfectly fast enough.

You'll also see a small set of codes that are sent to the Arduino. These are needed to set the LEDs and static tune rates for the VFOs. There's also a restart function, that is called when the host starts up to ensure that the I/O controller is in a known state.

I also defined the physical pin out from the Arduino to the various panel controls and indicators:

This pin out has the advantage that all pins are available along one edge of the Arduino, making it much easier to connect up to the physical controls, whether the controls are mounted on a PCB or are individually wired. I'll write more about this aspect of the design very soon.

Mk II architecture

A wet weekend and nothing much on the wireless up here in sunny Cumbria has provided the opportunity to do some in-depth thinking about the architecture of the Mk II controller. I'm getting a better handle on it now and I think it will look something like this:

At the top is the Windows-based processor. You will note that this is now shown as potentially separate from the controller and this is possible because there is in effect only a single USB connection between the processor and the controller. This has very interesting ramifications: the Windows processor can now be any suitable machine: a single board computer which may, or may not, be physically integrated with the controller, or it might be a separate PC of any sort, including a laptop.

The controller is now merely a bunch of physical controls with an Arduino to marshal the various control inputs and aggregate them into a serial feed to the main processor. All the heavy lifting is now done in the Windows machine and the Arduino is merely an I/O processor.The Arduino code is very simple and would need no configuration. One could envisage it piggybacking on the back of the controller front panel.

Gone, now, are all the wires between Arduino and panel. Gone, also, is the complexity of having to configure the Arduino code. Because the I/O task is really quite easy, I am sure that an Arduino Mega, with its much slower processor compared to the Due, would be up for the job. The control interfaces amount to 32 I/O pins, so the smaller Arduinos will not do the job but a Due or Mega should both be just fine.

Possible serial I/O command structure for
Communication between Arduino and X86 processor

 I think this is a very interesting looking architecture. Implementation become much simpler, there are numerous ways to build it that could make for extremely complex home-based controllers or simple  "hotel room" systems, with or without a separate PC. Furthermore, I already have virtually all the Arduino code from the Mk I project that can be reused.

Because the PC manages the display(s), the controller display, if needed is simply another display in a multi-screen Windows environment. In other words, this architecture could implement everything from a simple control pod with no display right through to a dual VFO controller with eight encoders and 32 switches. In fact one could go further: with two Arduinos one could have twice the number of controls. Now that would be one big controller!

This architecture will also be considerably easier to implement for non programmers. The Arduino code will be simple and require nothing more than an upload to the device. The Windows application will be a standard Windows install package. Connect the two together with a USB cable, wire up a few controls and away you go.

I have some components on order... can't wait to get started on this!

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

SDR with knobs on! II

Well that was quite something! When I saw the size of the lecture room that I'd been allocated at the Convention I though I'd be doing well to fill a few rows at the front, with a bunch of hecklers lurking at the back. In fact the room was packed, with a few standing at the back and of hecklers there were none.

I had decided that I would do a quick demonstration and that involved quite a fair bit of setting up, with not much time between the end of the previous lecture and the start of mine. In the end it seemed to work out OK. There were plenty of interesting questions and lots of delegates came up to me afterwards to say how much they had enjoyed the talk.

It was a real pleasure to meet Gerald, K5SDR who came to my presentation and who then gave a complementary presentation of his own in which my controller got a mention. Gerald and I talked for some time about the emergence of SDR into mainstream amateur radio use. All in all a fascinating experience and I hope to follow it up with a visit to the FlexRadio HQ soon.

Unfortunately the talk was not officially videoed and there was an embargo on unofficial videoing. However, you can download the Powerpoint presentation materials from my Dropbox for a taster of what it was all about.

SDR with knobs on!

My presentation at the RSGB Convention is on Saturday 8th October at 11:45-12:30, in lecture room N138/N141. I look forward to seeing lots of you there. 

The theme of my presentation is the emergence of SDR as mainstream amateur radio technology and the way that has brought into focus mouse & keyboard ergonomics issues, resulting in products like Maestro. 

I will demonstrate that there is nothing that restricts SDR to panel-less operation and that, on the contrary, the advent of open source APIs such as the Flex API has created a vast opportunity for radio amateurs to create and customise their own radio front panels. I will use my own Flex API-based controller as a case study.

Gerald, K5SDR, the President and CEO of FlexRadio, will also be presenting at the convention. His slots are Saturday 13:30-14:15 and Sunday 14:30-15:15. We're working together to ensure that there isn't too much overlap.

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.
 

Integration III

Today is a red letter day! My controller has moved 8ft to the right along my desk. Not in itself a big deal but in so doing it has also moved out of my software development lab and into my operational station. And that is a big deal!

The G3WGV Flex Controller is on the left, FT5000 centre stage
and logging PC on the right.
Lurking in the background the KPA500 is just visible

Close up of the two contenders. Which one will win?

Firstly I had to make up a bunch of cables. Suddenly I need two more Ethernet cables up that end of the room and, of course there's all the usual stuff to connect the Flex 6000 in with the rest of the shack. I'm rather pleased that I was able to simply parallel up the FT5000 and Flex radio audio outputs, so I can swap between them with ease and QSOs on both rigs will be properly recorded by StarLog. The Tx enable on my KPA500 linear similarly seems to be quite happy to be paralleled up.

Of course it wasn't all plain sailing. I found that StarLog would happily work with either the Flex 6000 or with the FT5000 but not both. A few coding tweaks and that was resolved. I also chickened out of trying to use a single paddle for both rigs, so I've brought my old Bencher out of retirement to be the paddles for the Flex rig. Depending on how things go the MagPad and the Bencher may get swapped around before too long!

So this is an important day. I shall now be able to start using my controller for making QSOs. I'm quite sure this will yield all manner of ideas for improvements. You'll get to hear about it here. Now I am off to play radio!

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!

Integration I

For all that it's fun developing cunning software and building controller hardware, ultimately the goal is to integrate the Flex rig into my station, perhaps replacing the FT5000 that has done the job very well for the past few years. So my attention has been focussed in this area recently.

In an earlier posting I discussed the Windows API that I have been writing. This has got to the point where it can be integrated into my logging program, StarLog, so I've spent a gratifyingly small amount of time doing that. The logger can now read and correctly interpret slice frequencies and mode.

My next challenge is to send frequency/mode information to the radio and manage slice creation/removal to facilitate split operation. This is important because, for example, with the FT5000 I can click on a spot that shows "Up 2" or whatever and that automatically sets the Rx frequency, enables the sub VFO, sets it as the Tx VFO and sets its frequency to the correct split. StarLog also has useful short cuts like Ctrl-U to set a split up, Ctrl-D to set split down and Ctrl-S to set simplex operation. All this should be possible with the Flex... I just have to write the code.

Another integration challenge is QSO recording. The Flex SSDR includes a separate client known as DAX that streams slice audio as a sound device. This sounds just the job but it turns out to not quite be what we need.

With the FT5000 I record a stereo audio channel. If I'm running simplex then both left and right carry the same audio - the main Rx. When I select split, the main Rx (DX) goes the the left channel and the sub Rx (pileup) goes to the right channel. Side tone is on both channels regardless of split mode. This works well and is perfect for listening to recordings after the event.

The Flex DAX has other ideas. Each slice (VFO in common parlance) creates a separate mono audio channel. There is no way to merge two slice audio channels into a single stereo channel. I might be able to take two mono channels and merge them into stereo in StarLog but it's far from ideal because the simplex audio would only go to the left channel. Not a show stopper though.

Worse is that the DAX streams do not carry side tone. Indeed there is no DAX channel for side tone. As a 100% CW operator that is a show stopper - I would only be recording one side of the QSO. Come to that, the same applies on phone and probably on data modes. I can't find a solution to this problem, although I am making enquiries on the FlexRadio forum.

If, as seems highly likely, I am unable to use DAX for QSO recording I shall have to use one of the two analogue audio outputs. The Flex has separate headphone and low level speaker outputs, each with their own level controls. Both are more or less the same output level. I traditionally have headphones and speaker connected in parallel (donning the cans when the going gets tough, turning down the speakers if necessary). So I could use the loudspeaker output for that function and the headphones output, via the PC sound card, for recording.

That'll work but I had rather hoped to get away from wires given that the audio is already digitised and available in the PC to support SSDR.

At this rate it won't be too long before I can make the Flex 6500 my station radio. Just in time for the sunspots to disappear!

The Flex API

It all started off innocuously enough. As the development of the Flex Controller gets closer to a usable system, I have started looking into integration issues. Notably, the Flex radio and/or controller needs to work with my home brew logging program, StarLog. Specifically, The logging program needs to be able to pull frequency/mode information from the radio and send frequency, mode and split commands to the radio.

The simplest option appears to be to use the Flex CAT add-on. This separate application becomes another client of the Flex radio and provides an Icom-like CAT interface via a virtual com port. All well and good but not really a very satisfying solution for at least the following reasons:

1. The use of legacy RS232 com ports. Although they are virtual ports (they don't really exist, certainly not in any physical form) they still require com port support in the logging program and it seems faintly ridiculous to use this approach in a modern system designed from the ground up.
2. The different architecture of the Flex radio means that concepts like split operation are realised in a quite different way, meaning that the standard Icom CAT protocol is inadequate. FlexRadio has added a number of Flex-specific CAT-like commands to bridge the gap but that's a fudge and, of course, it means that I would have to write new code in the logging program.

There is another way. The logging program can be made to become a client of the Flex radio, using the Flex Application Programming Interface (API). This is the gold star way to do it but it needs considerably more code and a lot of knowledge of the API that I certainly did not possess.

And so it happens that I have spent most of this week writing a Delphi Pascal program for my PC. It started out as a project to explore how CAT could be implemented via API but has become so much more.

Getting under the bonnet of the API turned out to be a difficult but fascinating voyage of discovery, at least in part because of the relative paucity of documentation. Fortunately there is the existing FlexAPI, the code for which is published and there is also a good forum community. As I've progressed my understanding has grown and now the program does far more than the tasks required for a logbook API.

The test program lets me play with the various facets of the interface protocol and see precisely what the radio responds with when I poke it with commands. Before I could make sense of that I spent a head banging evening looking at the actual packet data on the Ethernet interface, using Wireshark. You can't get much lower level than that.

Anyway, the result is that something really quite interesting has happened. I can now see my way to producing a complete API library that could be used with Windows applications to create a PC-based Flex Radio Controller. Now think back to my Blog entry a while back in which I contemplated a second generation controller based on something like the soon to be released Udoo X86 board. Suddenly things start coming together!

Another possibility is that this new code could be made into a DLL, meaning that it could be used with any PC application written in any language. I'm not sure that I'm ready to go there yet but it's certainly something to keep in mind for the future.

So I now have a solution to integrating my logging program into the Flex radio architecture via the Ethernet API. That's the next job I reckon.

Multiple profiles & other goodies

The big news this week is that the controller now supports multiple profiles. Swapping between profiles is just a case of a couple of touches on the screen and takes place instantaneously.

In testing I discovered the hard way that it is quite possible to create and then switch to a profile that doesn't include a Menu select switch. At this point I have lost control of my controller, and there is no way to recover to a working profile! I think I shall have to write some code to make that impossible.

In other news the display now shows graphical representations of the various DSP functions: APF, NB, WNB & NR.

You can see the graphics below the S meter, to the right of the filter graphic.Each DSP function is a small horizontal bargraph ranging between 0 and 100%. I have chosen not to add any numerical information, partly because it's unnecessary but also because there really isn't enough space. It's just as well I don't plan to have anything else on the main page!

Each DSP function is turned on or off via a switch that can be defined as required. My standard profile has these as touch areas on the relevant icon just above the frequency display, which seems intuitive.

Finally, I have done quite a lot of tidying up of the code. Some of the early code was a bit ungainly and as the project has progressed I've developed standards that needed to be engineered into this early code. The result is more maintainable, easy to read code, so it's worth the effort.

Sunday update

It's been a reasonably productive week at 'WGV Towers. Quite a lot of new switch and rotary encoder functions have been added, rounding out the control options nicely.

I now have 40 switch functions and 32 rotary control functions, with probably a few more of each yet to implement. This is considerably more than I originally envisaged and that has caused me to slightly rethink the way that these functions might be presented to the operator.

Switch functions
There are four possible ways to invoke a switch function:

• A physical push button or toggle switch
• The VFO control LED push buttons
• The push switches on each encoder
• Touch areas on the screen

Of these, the last one, touch areas, is the one that has seen the most development in the past week. Nine on/off functions such as RIT, XIT, APF and noise blanker on/off have been implemented for each VFO by touching the relevant area on the main display screen. This has the potential to free up a large number of physical buttons, although it is possible to have both a touch and a button for the same function if desired.

Another possibility that I am looking into is long and short button presses having separate functions. This is a fairly common concept and should not be too hard to implement.

Encoder controls
The Flex radio offers some 40+ control functions, most of them applicable to each slice. Many of these are of little value to the controller but nevertheless, I already have 32 controls defined, spanning the two VFOs.

Realising that these controls fall neatly into two categories - regularly used and infrequently needed - I have now implemented an encoder command set switch to support two sets of controls per encoder. If the encoder switch is used to switch controls then this means that each encoder can have a total of four assigned controls. On my 8 encoder prototype this means that the software can project up to 32 controls onto the front panel. Hopefully that'll be sufficient!

Max/Min/Step
When I first laid out the design for the encoder controls, I envisaged that a control would have a maximum and minimum value and a step value that could be configured at will. At the time, I could see no need for these values to be anything other than integer.

Experience has shown that this was wrong. For example, one control is display brightness and this has a range of 0 to 15. As the encoders produce 48 pulses per revolution, this meant that zero to full brightness occurred in just a quarter of a turn! So I have now implemented floating point numbers for the Max/Min/Step values. By setting the brightness control step to 0.25 the 16 steps now occupy a full turn on the encoder.

All in all, quite a lot of progress this week.

Front panel II

Last week I was able to get the front panel sprayed and over the last couple of days I've mounted all the panel components. At last I have all controls operational!

With the VFO control buttons/LEDs and all encoders working it's now possible to get on with the code to integrate all these functions. Inevitably I've found a couple of bugs lurking and those have been squashed fairly quickly.

There is still the back panel to complete, together with the power supply logic. Other than that, it's pretty well all software from now on.

In other news, we have a new Prime Minister. It's all happening!