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?
27 December 2016
26 December 2016
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.
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.
20 December 2016
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!
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:
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!
14 December 2016
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?
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?
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:
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:
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.
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.
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.
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
- Filter width for VFO-A
- Filter width for VFO-B
- Filter width for selected VFO
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 |
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.
4 December 2016
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.
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.
Subscribe to:
Posts (Atom)