I'm back!

It's been a while, over three years in fact, since I wrote to this Blog and in truth I had considered that the FlexRadio controller project was finished. But my projects are never really finished and the intervening years have seen more or less continual minor software changes, adding new features, fixing the odd bug and adapting to new versions of the Smart SDR software.

I've decided to resurrect the Blog because I have started on a completely new hardware development, which unlike the changes of the past few years is a significant body of work that changes the user interface somewhat. 

What am I up to?

The Mk II controller in use
(note the lack of labels!)

Old hands at this Blog will recall that one of the huge benefits of the controller was the ability to have a "virtual" front panel implemented in hardware. That means a proper physical front panel for the radio, with tuning knobs, rotary controls and push-buttons but with the ability to map any control function to any physical control. So, for example you could have a panel configuration for contests that is tailored to contesting, another for DXpeditions and yet another for DXing or rag-chewing,

In practice, although feasible, there is never any point in reassigning the VFO controls to anything other than VFOs (although one might swap them around, say for a left-handed operator). Rotary controls (volume, bandwidth, etc.) certainly can change: a control that is useful for contesting might be less so for DXing and so it would come or go on the physical panel as required. All of this is driven by a "profile" and there can be as many profiles as your operational needs might wish.

Problems and solutions

OLED

There is a problem! Because each control can do different things depending on the profile, it is not possible to label the controls with their function. That's not really an issue with the VFO knobs - pretty obvious what they do - and it's a fairly easy problem with the rotary controls because they can be arranged around the large screen that their functions can be displayed there.

A 3.5" LED touch-screen

Push-buttons are a different matter. OLED push-buttons are available that let you dynamically display the function but they are physically large and extremely expensive. After a lot of research and soul-searching, I rejected this approach. Which left... touch screens.

With a touch screen it is simple to add text on the screen to describe the push-button function. As most push-buttons have dual functionality (short press, long press) it makes sense to put the short press function label inside the switch outline and the secondary, long press function label below. 

A touch screen-based controller

The touch-screen controller PCB

I was, to be honest, nervous of going the touch screen route. There is something satisfying about the tactile feel of a proper switch that is lost with touch screens. But, I guess we've all become used to them these days, what with smart phones and iPads and the like, so I decided to experiment. I now have a trial implementation, using a pair of small touch screens to replace the 20 or so push-buttons of the old Maxi Controller. I've designed a PCB and had it produced. The software has been updated to provide a basic implementation. 

In short, I have a new FlexRadio Controller project on the go! Over the next few weeks/months I'll describe in more detail the hardware and software work that I am doing to make it happen.

RSGB Convention

I will once again be presenting a paper at the RSGB Convention this coming weekend. My presentation, SDR - The station of the future is at 11:45am on Sunday in Lecture Room 4.

This is a completely new presentation that reviews the history of SDR and looks at the way the amateur radio offerings have changed over time.

I then discuss operational aspects of having an SDR in the shack, looking at issues such as performance, ergonomics, value proposition, applications and the API, etc. 

See you there?

More station integration

A while back, here and here, I discussed the idea of the integrated controller and mused that the single board computer therein could take on all applications associated with station operation.

Well, it's taken a while but I've finally achieved that objective. Yesterday I prised my logging program out of the venerable laptop it has run on for several years and transplanted it into the Udoo X86 Ultra that is built into the Maxi-controller. This was not without its problems, in particular, the need to support a USB to RS232 interface which wouldn't work under Windows 10 (eventually fixed).

The application line up on the Maxi-controller PC is thus:

• SmartSDR
• My FlexRadio Host controller
• DX Atlas
• IonoProbe
• StarLog

Of these, SmartSDR is by far the most CPU intensive, requiring around 25% of available processing power. The host controller is next up but only around 3% and the others are <3% most of the time.

There is still a little work to do. At the moment my antenna switching control is via a Velleman P8055 USB to parallel interface. This works OK but is an external unit that is now unnecessary. My plan is to use the Arduino functionality of the Udoo X.86 SBC to take over this function. That requires new code in StarLog and, of course, code for the Arduino. I'll also need to make a "shield" to fit onto the Arduino headers to hold the line driver IC that sends the switching signals out to the antenna switch at the base of the tower. Coming soon(ish).

Belated update

It's all been a bit quiet on the project front recently, in part because I have been busy with other things. I'm still waiting for the FlexRadio white paper on remote operation, so there has been no progress on that aspect of the project. As I received no feedback as to whether I should wait until this work was completed before making the project publicly available, I have chosen not to release it for now.

Of course the Maxi-controller has been in operation as my main station for around six months now and, by and large, it has proven highly satisfactory. I've discovered, and fixed, a few minor bugs, as is the way with these things - but no show stoppers. Just as well: apart from the Icom IC-7300 I have no other options, chez 'WGV.

There has been progress elsewhere.

I've started on documentation for the project. This is in the form of a Windows HTML help file, so it can be opened from within the controller program or directly. This will, in time, become the main repository for information specific to the controller and will complement this Blog. Effectively the Blog will be, as it is now, for discussion about the project and the help file will document the actual implementation.

The Profile Manager had got a bit behind the controller development cycle, so I spent quite a bit of time updating that. In so doing I realised that there were some inconsistencies in the structure of both the Profile Manager and, by association, the controller itself.

• The Profile Manager didn't always properly differentiate between logical functions and physical controls. This showed up in the layout of some forms and, importantly, in the naming of certain coding variables. 
• The profile files, similarly, used protocol language that could cause confusion.

This created quite a lot of coding work that has no real effect on the functional capabilities of the controller or the Profile Manager. I felt it was important though, especially as it is my eventual intention to make the code publicly available.

There have been some functionality changes too. A while ago I introduced the idea of long and short switch press functions but this enhanced functionality didn't extend to the encoder switches. It does now.

When controls are changed a pop-up message displays what the change was, which is mostly a good thing. Sometimes the pop-up would obscure the thing the switch had selected, for example, the band/mode form. That's not so good, and now each control function can be individually tailored to show/not show the pop-up as required.

Finally, as discussed last month, I have implemented the ability to fix by configuration the relationship between slices and VFOs. This has resulted in a big improvement in station integration, as everyday actions such as split selection from the logging program now work perfectly. As I discussed before, this is not an ideal solution but with the current Flex API it is the best I can do.

As we head into the winter I hope to have a bit more time to spend on the project.

Slice management

While I am waiting for the white paper on SmartLink, I've been giving some more thought to slice management strategy. The nub of the problem is twofold:

1. Slices are allocated from a pool on an as required basis, so there is no fixed relationship between a slice and its function. For example, if one opens a new slice for split working, you'll just get whatever the next free slice is. It might be slice 1 (slices are counted from 0) or it might not be, if slice 1 is already in use somewhere else.
2. There is no way to relate a slice to a particular function. So it's not possible to say that slices 0 and 1 "belong" to a specific controller/logging program combination.

These two factors make it nearly impossible to implement a proper SO2R using two controllers and a single Flex 6xxx radio. It would be possible if we were certain that both the controllers would always use a fixed number of slices - in that case we'd just open those slices as part of the setting up of the station and allocate them accordingly. To my mind that is too constricting a solution.

There isn't a solution to this at present. I have a proposal in with FlexRadio that introduces the concept of logical slices. Each logical slice can be allocated an identification string that is persistent, that is it survives physical slice creation and destruction and also survives radio power down. When that logical slice is instantiated as a physical slice then we know the logical mapping to controllers, logging program or whatever. All that is then needed is that the clients associated with a logical slice are aware of its identification - a simple configuration matter.

I have no time scale for implementation, nor, indeed, any indication that it will be implemented, although this is a definite, known problem that FlexRadio acknowledges and some sort of fix will surely be necessary in due course.

At a more parochial level, the way I have currently implemented slice management is that the user manually sets the relationship between slices and VFOs at run time. This is OK when the radio is in simplex mode - most likely slice 0 becomes allocated to VFO-A. There is no problem either, if split mode is in operation at that time. Simply allocate the VFOs as needed - most likely Slice 0 = VFO-A and slice 1 = VFO-B.

The problem comes when, say, you're in simplex mode and click on a spot with the logging program that shows split operation. My logging software interprets split information in the comments field. For example, if it sees "Up 2" in the spot comments then it starts a new slice and sets the transmit slice to that slice so you're all set to call the DX on the correct split. All well and good but the controller (which does see the new physical slice being created) doesn't know that the new slice is part of its bailiwick. So you then have to manually tell the controller that yes, this new slice is indeed, for now, its VFO-B.

You see the problem?

I need to think about this some more but I am coming to the conclusion that I need to implement an optional mapping  system that permits me to map physical slices to virtual VFOs. That's a nuisance and it would mean that a multi-controller system working on different slices (e.g. an SO2R station) would not work but it's the only way I can think to handle the lack of virtual slice identifiers.

I'm planning to write some test code in the next few days.

Remote update II

Things are moving on. I now have two Internet accounts with different static IP addresses, so I can test remote access.

As earlier tests suggested, my controller code doesn't work remotely, even if it is running on the same PC that has negotiated a remote connection. That was somewhat disappointing but now I think about it, it would have been surprising (and probably not a good thing from a security perspective) had it worked.

The SmartSDR radio
connection page for V2

The key to remote operation is a new FlexRadio service called SmartLink. SmartLink brokers a one time only, single use connection between the radio (server) and a client application and having done so disconnects and is no longer part of the session. It's quite a neat solution that removes the need for a VPN.

So I need to understand how SmartLink works. FlexRadio has provided some code in the latest FlexLib API package but there is insufficient detail for me to work out how to code it myself. Or perhaps I'm just not good enough at reading code written in C!

The technical guys at FlexRadio are, apparently, putting together a white paper that will explain the interface for developers to code to but as yet there is no time scale for publication. Meanwhile, adding remote operation capability to my controller code is on the back burner.

How important is remote operation to you? If you're thinking about using my code, would you prefer to wait until it's available or should I release a non-remote version sooner?

Remote update

The UKSMG presentation seemed to go well but I wasn't able to do any sort of demonstration because, as I discovered when I got away from my own network, my controller code doesn't work with the new remote feature in Smart SDR V2. To be honest I am not surprised.

So there is new code to write! I have today made arrangements with my Internet Service Provider to get another broadband account set up with its own static IP address. This will enable me to test any new code that I write across the Internet, from one user account to the other. It will be a generally useful thing to have. Fortunately, I run one of the network nodes for our broadband service here at 'WGV Towers, so it's just a case of setting up a new account (already done) and connecting up another router. I should have it all working tomorrow, when the new router arrives.

I also contacted FlexRadio about the API for the new SmartLink features. Hopefully some documentation will be published soon and I can then see what needs to be done.

That's the thing with software... there's always something new to play with.