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.