General progress report

I see it's almost ten days since I updated the Blog and that will never do! This is what I've been up to:

The single Arduino architecture is now working fully (that is, it has all the functionality that the last version of the dual processor solution had). That's encouraging, as it means the architecture model is pretty well fully validated now. I do not expect to be changing again! (but see below...)

The PCB has been fully populated with push buttons, the two multiplexer chips and eight encoders. The multiplexers and switches are all working and I'm just waiting for a couple of components to arrive so that I can finish the connections, to encoders, VFOs and the VFO LED switches. Meanwhile, the front panel shouldn't be too much longer in the machine shop.

I've written some new code in the Arduino and a separate Windows Delphi application that lets me upload profile and configuration files to the on-board memory card. Previously, if I made changes, I had to remove the SD card from the Arduino stack, plug it into my PC, copy the new file across and then put the SD card back in the Arduino. Something of a palava and I am happy not to have to do that any more.

Finally, I've been looking into the possibility of displaying a panadapter/waterfall on the Flex Controller display. This is not as easy as it appears at first sight. The Flex radio shapes the FFT data to a specified width and height in pixels for the controller to display. That's marvellous but it makes it very difficult to support more than one panadapter display unless they happen to have identical dimensions. That is unlikely, especially with the relatively small screen on my controller. For the time being, Flex Radio has, understandably, ducked the issue, although there is talk of support for multiple FFT displays at some stage in the future.

Of course this isn't a problem if the controller is being used in parallel with SSDR - probably the most common configuration. It would, however, be quite nice to have a pan display when the controller is operated in stand-alone mode. Experiments have shown that unfortunately the Arduino Due processor and, particularly the display just do not have sufficient power for this to work in practice. So I've reluctantly decided that my controller will not have its own panadapter or waterfall display.

This in turn has started me thinking about the possibility of a mark II controller. There is a huge choice of single board computing systems out there, including some astonishingly powerful machines that would eat the FFT data display problem alive. The big problem is the quite serious amount of I/O that the controller needs and in that regard the Arduino is excellent. Something that combines the connectivity of Arduino with the processing power of a modern multiprocessing engine is what is needed. Something like this, perhaps!

This is what always happens when I start developing things. I can always see the next couple of versions stretching out into the future. I suppose that's the reason I've been building things since I was a kid and programming since my early 20s!