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!

Front panel update

At last the front panel has come back from the CNC workshop. Although it's taken far longer than it should have, the result is excellent! Everything fits together perfectly and it really does look the part.

The panel with some controls mounted

I fitted some of the controls to get an idea what it would all look like as you can see above. Before final assembly I'll be getting the panel sprayed in a dark grey matt finish and I also need to think what, if any, silk screening to apply. As all the controls are "soft" there is no point labelling them but it may be that some other labelling might be in order.

With the panel completed, I now have all the hardware I require for the first version of the controller. I should now be able to get on with completing the physical construction and, of course, there is still a lot of software to be written (there always is - it's a project without end!).