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 :)
20 November 2016
9 November 2016
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:
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.
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.
8 November 2016
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:
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.
- 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).
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.
29 October 2016
Mk II progress (3)
And so my thoughts turn to the physical implementation options that the Mk II presents.
At a general level, it is clear that the Mk II offers far more flexibility in physical implementation, together with much less wiring complexity. I can immediately identify several possible configurations that would meet a variety of operating scenarios:
Full station controller: Effectively the Mk II equivalent of what I built as my Mk I implementation. This has a screen and two VFOs, with plenty of switches and encoders.Unlike the Mk I, the host PC could also be built into the cabinet, providing a complete station computing solution in a single package. Or, use could be made of an existing PC or laptop - the connection is, after all, just a single USB port.
Mini controller: A cut down version that could be perfect for travelling. Perhaps just one VFO and fewer encoders/switches. Still a display though. Same options for the host PC, although it seems more likely that one would use a laptop in this configuration. The controller could be put in a shallow box, perhaps a sloping panel, for ease of carrying.
Micro controller: Like the mini controller but without a display. The display would, instead, be shown on the host PC screen. Or perhaps not even displayed at all, as all the information you need would be shown on SSDR, which would have to be running in this configuration.
The upshot of all this is that a single set of code could be used to create a controller of any level of complexity, depending upon the user's requirements.
This is all very much a work in progress and I suspect it'll be Christmas before I have anything to look at. In the meantime the Mk I controller is doing a great job as my main station radio.
At a general level, it is clear that the Mk II offers far more flexibility in physical implementation, together with much less wiring complexity. I can immediately identify several possible configurations that would meet a variety of operating scenarios:
Full station controller: Effectively the Mk II equivalent of what I built as my Mk I implementation. This has a screen and two VFOs, with plenty of switches and encoders.Unlike the Mk I, the host PC could also be built into the cabinet, providing a complete station computing solution in a single package. Or, use could be made of an existing PC or laptop - the connection is, after all, just a single USB port.
Mini controller: A cut down version that could be perfect for travelling. Perhaps just one VFO and fewer encoders/switches. Still a display though. Same options for the host PC, although it seems more likely that one would use a laptop in this configuration. The controller could be put in a shallow box, perhaps a sloping panel, for ease of carrying.
Micro controller: Like the mini controller but without a display. The display would, instead, be shown on the host PC screen. Or perhaps not even displayed at all, as all the information you need would be shown on SSDR, which would have to be running in this configuration.
The upshot of all this is that a single set of code could be used to create a controller of any level of complexity, depending upon the user's requirements.
PCBs
My pal who does PCB designs for me was here yesterday. I have commissioned a Mk II PCB design with exactly the same control/screen layout as the Mk I he produced back in May. The cunning plan is to piggyback the Arduino onto this PCB, behind the display, so that there will be no physical wiring at all apart from the USB cable to the Arduino and HDMI cable to the display. This will make the controller very neat and easy to replicate. I expect to use the same approach for any other PCB layouts that I commission.This is all very much a work in progress and I suspect it'll be Christmas before I have anything to look at. In the meantime the Mk I controller is doing a great job as my main station radio.
Mk II progress (2)
In part 1 I wrote about the I/O controller. With this working to a sufficient extent to start doing useful development on the host, that's where my attention has been for the past few days.
It quickly became apparent that there will be much greater flexibility with the host code running on a PC. The display can be anywhere you chose to put it and there can be other windows open in the application as required. On the other hand, it would be desirable to be able to operate using a small 5" screen, as before, so I have once again set the form size to 800 x 480 pixels - the size of the 5" screen.
The screen capture shows the limited progress so far. I can display the VFOs, various settings such as Tx, Tx, noise blanker, mode and RIT/XIT. This is enough for me to experiment and see whether the combination of I/O controller (the Arduino), Host (PC) and radio play nicely together. They do.
You can see that VFO-A is the RX VFO, it is locked and muted. VFO-B is the Rx and Tx VFO (a typical spit frequency DX chasing set up). It shows the split value, and the VFO is neither locked nor muted. Clicking on the various parts of the screen allows various switch functions to be initiated, just as on the Mk I controller.
Using this embryonic set up I was able to work ZL7G on 40m CW this morning. Always nice when one can use one's new toy to good effect!
There is now a lot of code to write in the host to bring full functionality to the Mk II. This will be a project for the next couple of months, perhaps more. In the meantime, I've also been thinking about physical implementation and that will be the subject of part 3.
It quickly became apparent that there will be much greater flexibility with the host code running on a PC. The display can be anywhere you chose to put it and there can be other windows open in the application as required. On the other hand, it would be desirable to be able to operate using a small 5" screen, as before, so I have once again set the form size to 800 x 480 pixels - the size of the 5" screen.
You can see that VFO-A is the RX VFO, it is locked and muted. VFO-B is the Rx and Tx VFO (a typical spit frequency DX chasing set up). It shows the split value, and the VFO is neither locked nor muted. Clicking on the various parts of the screen allows various switch functions to be initiated, just as on the Mk I controller.
Using this embryonic set up I was able to work ZL7G on 40m CW this morning. Always nice when one can use one's new toy to good effect!
There is now a lot of code to write in the host to bring full functionality to the Mk II. This will be a project for the next couple of months, perhaps more. In the meantime, I've also been thinking about physical implementation and that will be the subject of part 3.
Mk II progress (1)
The last week or so has seen quite significant progress on the Mk II design, which now seems to be a feasible proposition.
Firstly, I stripped out unneeded code, some 90%, from the Arduino Mk I project, to create an I/O controller which just collects transactions from the VFOs, encoders and switches, then sends them on a serial port. I already had most of that code, so it didn't take long to get it working. Here's the serial I/O protocol I've ended up with:
At the top is the four commands that the Arduino sends to its host. These are sent every 20ms if there has been a change. Why 20ms? The Flex radio is not happy with updates much more often than once every 20ms, so there is no point collecting data from the controls any more frequently than that.
The protocol is deliberately designed to be as light as possible. The issue here is that we want the absolute minimum time between a control being changed and the effect of that change being processed by the radio. The Mk II design has added another series element in the chain and that must be made as fast as possible. This is how, say, a VFO frequency change progresses to the radio:
At 115,200 baud, say 10,000 characters per second, the serialisation delay of a VFO change command, which is 8 characters in length is about 0.8ms, which is perfectly fast enough.
You'll also see a small set of codes that are sent to the Arduino. These are needed to set the LEDs and static tune rates for the VFOs. There's also a restart function, that is called when the host starts up to ensure that the I/O controller is in a known state.
This pin out has the advantage that all pins are available along one edge of the Arduino, making it much easier to connect up to the physical controls, whether the controls are mounted on a PCB or are individually wired. I'll write more about this aspect of the design very soon.
Firstly, I stripped out unneeded code, some 90%, from the Arduino Mk I project, to create an I/O controller which just collects transactions from the VFOs, encoders and switches, then sends them on a serial port. I already had most of that code, so it didn't take long to get it working. Here's the serial I/O protocol I've ended up with:
At the top is the four commands that the Arduino sends to its host. These are sent every 20ms if there has been a change. Why 20ms? The Flex radio is not happy with updates much more often than once every 20ms, so there is no point collecting data from the controls any more frequently than that.
The protocol is deliberately designed to be as light as possible. The issue here is that we want the absolute minimum time between a control being changed and the effect of that change being processed by the radio. The Mk II design has added another series element in the chain and that must be made as fast as possible. This is how, say, a VFO frequency change progresses to the radio:
Control input > Arduino processing > Command serialisation > Host processing > Network transport > Radio processing.
At 115,200 baud, say 10,000 characters per second, the serialisation delay of a VFO change command, which is 8 characters in length is about 0.8ms, which is perfectly fast enough.
You'll also see a small set of codes that are sent to the Arduino. These are needed to set the LEDs and static tune rates for the VFOs. There's also a restart function, that is called when the host starts up to ensure that the I/O controller is in a known state.
I also defined the physical pin out from the Arduino to the various panel controls and indicators:
This pin out has the advantage that all pins are available along one edge of the Arduino, making it much easier to connect up to the physical controls, whether the controls are mounted on a PCB or are individually wired. I'll write more about this aspect of the design very soon.
16 October 2016
Mk II architecture
A wet weekend and nothing much on the wireless up here in sunny Cumbria has provided the opportunity to do some in-depth thinking about the architecture of the Mk II controller. I'm getting a better handle on it now and I think it will look something like this:
At the top is the Windows-based processor. You will note that this is now shown as potentially separate from the controller and this is possible because there is in effect only a single USB connection between the processor and the controller. This has very interesting ramifications: the Windows processor can now be any suitable machine: a single board computer which may, or may not, be physically integrated with the controller, or it might be a separate PC of any sort, including a laptop.
The controller is now merely a bunch of physical controls with an Arduino to marshal the various control inputs and aggregate them into a serial feed to the main processor. All the heavy lifting is now done in the Windows machine and the Arduino is merely an I/O processor.The Arduino code is very simple and would need no configuration. One could envisage it piggybacking on the back of the controller front panel.
Gone, now, are all the wires between Arduino and panel. Gone, also, is the complexity of having to configure the Arduino code. Because the I/O task is really quite easy, I am sure that an Arduino Mega, with its much slower processor compared to the Due, would be up for the job. The control interfaces amount to 32 I/O pins, so the smaller Arduinos will not do the job but a Due or Mega should both be just fine.
I think this is a very interesting looking architecture. Implementation become much simpler, there are numerous ways to build it that could make for extremely complex home-based controllers or simple "hotel room" systems, with or without a separate PC. Furthermore, I already have virtually all the Arduino code from the Mk I project that can be reused.
Because the PC manages the display(s), the controller display, if needed is simply another display in a multi-screen Windows environment. In other words, this architecture could implement everything from a simple control pod with no display right through to a dual VFO controller with eight encoders and 32 switches. In fact one could go further: with two Arduinos one could have twice the number of controls. Now that would be one big controller!
This architecture will also be considerably easier to implement for non programmers. The Arduino code will be simple and require nothing more than an upload to the device. The Windows application will be a standard Windows install package. Connect the two together with a USB cable, wire up a few controls and away you go.
I have some components on order... can't wait to get started on this!
At the top is the Windows-based processor. You will note that this is now shown as potentially separate from the controller and this is possible because there is in effect only a single USB connection between the processor and the controller. This has very interesting ramifications: the Windows processor can now be any suitable machine: a single board computer which may, or may not, be physically integrated with the controller, or it might be a separate PC of any sort, including a laptop.
The controller is now merely a bunch of physical controls with an Arduino to marshal the various control inputs and aggregate them into a serial feed to the main processor. All the heavy lifting is now done in the Windows machine and the Arduino is merely an I/O processor.The Arduino code is very simple and would need no configuration. One could envisage it piggybacking on the back of the controller front panel.
Gone, now, are all the wires between Arduino and panel. Gone, also, is the complexity of having to configure the Arduino code. Because the I/O task is really quite easy, I am sure that an Arduino Mega, with its much slower processor compared to the Due, would be up for the job. The control interfaces amount to 32 I/O pins, so the smaller Arduinos will not do the job but a Due or Mega should both be just fine.
 | |
| Possible serial I/O command structure for Communication between Arduino and X86 processor |
Because the PC manages the display(s), the controller display, if needed is simply another display in a multi-screen Windows environment. In other words, this architecture could implement everything from a simple control pod with no display right through to a dual VFO controller with eight encoders and 32 switches. In fact one could go further: with two Arduinos one could have twice the number of controls. Now that would be one big controller!
This architecture will also be considerably easier to implement for non programmers. The Arduino code will be simple and require nothing more than an upload to the device. The Windows application will be a standard Windows install package. Connect the two together with a USB cable, wire up a few controls and away you go.
I have some components on order... can't wait to get started on this!
Subscribe to:
Posts (Atom)