13 December 2016

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.

8 comments:

  1. Hi John,
    Got my 6500 in september, so still a bit of a newbe. Excellent work you are doing and my plans are to build a MkII when I do get some spare time. I currently run the Maestro and the simple layout makes it a pleasure to use.
    73 Lasse SM5GLC

    ReplyDelete
    Replies
    1. John
      Looking forward to reading your progress with the Mini controller, as I believe this is what I want for my 6700. 73 Peter G3ZSS

      Delete
    2. Hi Lasse and Peter,

      Thanks for your comments - it is nice to know that people are following the Blog!

      I'm hoping to get to the mini controller PCB design very early in the new year. I know exactly what's needed, it's just a case of getting the PCB layout sorted out and into fab. I'll then be taking expressions of interest in getting a larger production run done but of course the volumes will never be large. I'll put all the updates here for you to see.

      73, John, G3WGV

      Delete
  2. Hi John
    I use MS a lot on 50MHz, and currently experimenting with MSK144. It's fairly common to use the protocol CQ 285 GM4KLN IO77, when calling on the MSK144 calling frequency of 50280: as soon as I get a reply to my CQ, I switch qrg to 50285 and the QSO takes place there, rather than on the "calling" channel. Pretty standard stuff. Exactly the same with other modes: for JT6m, CQ236 GM4KLN IO77, initially tx on 50230.
    Its simply split vfo CQ, then setting tx to vfo2 once called.....then reverting to split once QSO complete etc.
    I think I am understanding your logic by thinking all I need is the Mini?
    73, Ian GM4KLN

    ReplyDelete
  3. Hi Ian,

    Yes, I think the Mini is what you need. It supports two VFOs on a single knob and you can switch between the two at will.

    In this particular case I might need to think about some additional code. The two VFOs aren't used for frequency hopping (Tx and Rx both on one or other VFO). Instead they are used to operate "split" where you receive on two separate frequencies and transmit on one of them. This is a subtle difference and it's only a small amount of code to effectively have two independent VFO channels that you swap between.

    73, John.

    ReplyDelete
  4. precisely John! that's the subtle difference I've mentioned since day one :-) we can chat thru this offline if preferred so I can expand a bit if needed? 73, Ian

    ReplyDelete
  5. It's not really a big difference. You can already swap Tx VFO at will using the VFO Tx buttons. The only additional feature is to disable or mute the calling channel Rx. One additional button press (VFO-A Rx) does that already. As there is no disadvantage in keeping the calling channel slice active, muting its Rx seems the most satisfactory solution.

    ReplyDelete
  6. Interesting - understood, thanks John. Looks like a Mini for me then :-)

    ReplyDelete