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.

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.

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:

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.

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.

Possible serial I/O command structure for
Communication between Arduino and X86 processor

 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!

Quo vadis?

As I've said before, my software projects never really finish. There's always another must-have just over the horizon and so it is with my controller project.

I've previously discussed the idea of moving to an X86 and Windows-based solution but without any real analysis of why that might be a good thing. It turns out that the Mk I, Arduino-based controller does a great job, as far as it goes, so there need to be other drivers for change.

Mk I controller 
The Mk I controller has all the control functions that one might reasonably need physical controls for. It has a decent 5" touch screen that displays all the things anyone is likely to require except panadapter and waterfall. The controller can operate standalone or in conjunction with SSDR or the Maestro. Of course, in standalone mode there is no panadapter/waterfall, which limits its usefulness (once you've got used to them you'll be loathe to manage without).

The Mk I can't operate via WiFi - it requires a wired Ethernet connection. This is primarily because of weaknesses in the Arduino WiFi libraries, which don't play nicely with other services using the Arduino SPI interface. I could probably fix this if I put a load of effort into the driver code. The lack of WiFi means that /P operation, say in a hotel room, is not feasible.

My original design proposal for the Mk I controller was as a base station controller operating in conjunction with SSDR. It does this job admirably but has major limitations in other environments.

Mk II controller options
For the moment, I will assume that the Mk II will be windows-based, on an X86 platform.

The move to an X86 platform will make development and deployment far more straightforward. The Arduino ecosystem is not really designed for complex projects like this. Factors include the rather poor (and slow!) development environment and the lack of any proper quality control over essential libraries, which makes for tricky problems that shouldn't really exist. The Arduino platform was great for concept development but it's not really the way forward for the bulk of the controller.

As it happens, the Mk II controller will almost certainly still have an Arduino component. The Arduino is particularly good at supporting lots of I/O and that is definitely needed for the control interfaces. This is a comparatively low level requirement so the code should be very simple. An obvious solution is the Udoo X86 board, which has an Arduino processor built in. A standard X86 machine, with an Arduino connected via its serial port would work just as well.

I see two possible directions of travel:

1. Same functionality as the Mk I but with the addition of WiFi
2. A full controller that replaced SSDR completely

Option 1 is not particularly exciting although it does overcome a significant shortcoming of the Mk I. It would also be possible to run the logging software and other station control functions on the same processor, with a fairly useful reduction in station complexity.

Option 2 would be much more fun and, of course, far more complicated. In this option, the controller will fully support panadapter and waterfall displays and, by inference, a big enough subset of SSDR's functionality to render SSDR no longer necessary for day to day operation.

The issue here is that in any one set up you can, practically speaking, only have one panadapter/waterfall display per radio. This is because the radio itself does all the display sizing, so all displays must have the same pixel sizing. I suppose one could scale the display downwards but the results would probably look pretty awful. There is also talk of FlexRadio supporting more than one display in due course but time scales are elusive.

Now, if I do my own panadapter/waterfall then all sorts of interesting possibilities start to become apparent. For example, I could overlay the panadapter with call signs obtained via packet cluster, RBN or a local Skimmer. With closer integration between logging and controller software I have no doubt that there would be other fun things I could do.

Option 2 would, in normal use, not work alongside SSDR, although I could code an option to have the controller run in "control mode" where the panadapter/waterfall displays were disabled, permitting SSDR to be run. I think this might be necessary, as I suspect that software updates and other maintenance functions are likely to require continuing ability to use SSDR occasionally.

What to do?
Perhaps unsurprisingly, I am tending towards option 2 in the long run and, of course, a move to the X86 platform will be an essential enabler for that. In the short term I think the first task is port my Arduino code to the X86 environment (option 1) but with an eye on the bigger picture to avoid making any design decisions that might prejudice option 2 in due course.

I feel a winter project coming on...

SDR with knobs on! II

Well that was quite something! When I saw the size of the lecture room that I'd been allocated at the Convention I though I'd be doing well to fill a few rows at the front, with a bunch of hecklers lurking at the back. In fact the room was packed, with a few standing at the back and of hecklers there were none.

I had decided that I would do a quick demonstration and that involved quite a fair bit of setting up, with not much time between the end of the previous lecture and the start of mine. In the end it seemed to work out OK. There were plenty of interesting questions and lots of delegates came up to me afterwards to say how much they had enjoyed the talk.

It was a real pleasure to meet Gerald, K5SDR who came to my presentation and who then gave a complementary presentation of his own in which my controller got a mention. Gerald and I talked for some time about the emergence of SDR into mainstream amateur radio use. All in all a fascinating experience and I hope to follow it up with a visit to the FlexRadio HQ soon.

Unfortunately the talk was not officially videoed and there was an embargo on unofficial videoing. However, you can download the Powerpoint presentation materials from my Dropbox for a taster of what it was all about.

SDR with knobs on!

My presentation at the RSGB Convention is on Saturday 8th October at 11:45-12:30, in lecture room N138/N141. I look forward to seeing lots of you there. 

The theme of my presentation is the emergence of SDR as mainstream amateur radio technology and the way that has brought into focus mouse & keyboard ergonomics issues, resulting in products like Maestro. 

I will demonstrate that there is nothing that restricts SDR to panel-less operation and that, on the contrary, the advent of open source APIs such as the Flex API has created a vast opportunity for radio amateurs to create and customise their own radio front panels. I will use my own Flex API-based controller as a case study.

Gerald, K5SDR, the President and CEO of FlexRadio, will also be presenting at the convention. His slots are Saturday 13:30-14:15 and Sunday 14:30-15:15. We're working together to ensure that there isn't too much overlap.