RSGB Convention

I will once again be presenting a paper at the RSGB Convention this coming weekend. My presentation, SDR - The station of the future is at 11:45am on Sunday in Lecture Room 4.

This is a completely new presentation that reviews the history of SDR and looks at the way the amateur radio offerings have changed over time.

I then discuss operational aspects of having an SDR in the shack, looking at issues such as performance, ergonomics, value proposition, applications and the API, etc. 

See you there?

More station integration

A while back, here and here, I discussed the idea of the integrated controller and mused that the single board computer therein could take on all applications associated with station operation.

Well, it's taken a while but I've finally achieved that objective. Yesterday I prised my logging program out of the venerable laptop it has run on for several years and transplanted it into the Udoo X86 Ultra that is built into the Maxi-controller. This was not without its problems, in particular, the need to support a USB to RS232 interface which wouldn't work under Windows 10 (eventually fixed).

The application line up on the Maxi-controller PC is thus:

• SmartSDR
• My FlexRadio Host controller
• DX Atlas
• IonoProbe
• StarLog

Of these, SmartSDR is by far the most CPU intensive, requiring around 25% of available processing power. The host controller is next up but only around 3% and the others are <3% most of the time.

There is still a little work to do. At the moment my antenna switching control is via a Velleman P8055 USB to parallel interface. This works OK but is an external unit that is now unnecessary. My plan is to use the Arduino functionality of the Udoo X.86 SBC to take over this function. That requires new code in StarLog and, of course, code for the Arduino. I'll also need to make a "shield" to fit onto the Arduino headers to hold the line driver IC that sends the switching signals out to the antenna switch at the base of the tower. Coming soon(ish).

Belated update

It's all been a bit quiet on the project front recently, in part because I have been busy with other things. I'm still waiting for the FlexRadio white paper on remote operation, so there has been no progress on that aspect of the project. As I received no feedback as to whether I should wait until this work was completed before making the project publicly available, I have chosen not to release it for now.

Of course the Maxi-controller has been in operation as my main station for around six months now and, by and large, it has proven highly satisfactory. I've discovered, and fixed, a few minor bugs, as is the way with these things - but no show stoppers. Just as well: apart from the Icom IC-7300 I have no other options, chez 'WGV.

There has been progress elsewhere.

I've started on documentation for the project. This is in the form of a Windows HTML help file, so it can be opened from within the controller program or directly. This will, in time, become the main repository for information specific to the controller and will complement this Blog. Effectively the Blog will be, as it is now, for discussion about the project and the help file will document the actual implementation.

The Profile Manager had got a bit behind the controller development cycle, so I spent quite a bit of time updating that. In so doing I realised that there were some inconsistencies in the structure of both the Profile Manager and, by association, the controller itself.

• The Profile Manager didn't always properly differentiate between logical functions and physical controls. This showed up in the layout of some forms and, importantly, in the naming of certain coding variables. 
• The profile files, similarly, used protocol language that could cause confusion.

This created quite a lot of coding work that has no real effect on the functional capabilities of the controller or the Profile Manager. I felt it was important though, especially as it is my eventual intention to make the code publicly available.

There have been some functionality changes too. A while ago I introduced the idea of long and short switch press functions but this enhanced functionality didn't extend to the encoder switches. It does now.

When controls are changed a pop-up message displays what the change was, which is mostly a good thing. Sometimes the pop-up would obscure the thing the switch had selected, for example, the band/mode form. That's not so good, and now each control function can be individually tailored to show/not show the pop-up as required.

Finally, as discussed last month, I have implemented the ability to fix by configuration the relationship between slices and VFOs. This has resulted in a big improvement in station integration, as everyday actions such as split selection from the logging program now work perfectly. As I discussed before, this is not an ideal solution but with the current Flex API it is the best I can do.

As we head into the winter I hope to have a bit more time to spend on the project.

Slice management

While I am waiting for the white paper on SmartLink, I've been giving some more thought to slice management strategy. The nub of the problem is twofold:

1. Slices are allocated from a pool on an as required basis, so there is no fixed relationship between a slice and its function. For example, if one opens a new slice for split working, you'll just get whatever the next free slice is. It might be slice 1 (slices are counted from 0) or it might not be, if slice 1 is already in use somewhere else.
2. There is no way to relate a slice to a particular function. So it's not possible to say that slices 0 and 1 "belong" to a specific controller/logging program combination.

These two factors make it nearly impossible to implement a proper SO2R using two controllers and a single Flex 6xxx radio. It would be possible if we were certain that both the controllers would always use a fixed number of slices - in that case we'd just open those slices as part of the setting up of the station and allocate them accordingly. To my mind that is too constricting a solution.

There isn't a solution to this at present. I have a proposal in with FlexRadio that introduces the concept of logical slices. Each logical slice can be allocated an identification string that is persistent, that is it survives physical slice creation and destruction and also survives radio power down. When that logical slice is instantiated as a physical slice then we know the logical mapping to controllers, logging program or whatever. All that is then needed is that the clients associated with a logical slice are aware of its identification - a simple configuration matter.

I have no time scale for implementation, nor, indeed, any indication that it will be implemented, although this is a definite, known problem that FlexRadio acknowledges and some sort of fix will surely be necessary in due course.

At a more parochial level, the way I have currently implemented slice management is that the user manually sets the relationship between slices and VFOs at run time. This is OK when the radio is in simplex mode - most likely slice 0 becomes allocated to VFO-A. There is no problem either, if split mode is in operation at that time. Simply allocate the VFOs as needed - most likely Slice 0 = VFO-A and slice 1 = VFO-B.

The problem comes when, say, you're in simplex mode and click on a spot with the logging program that shows split operation. My logging software interprets split information in the comments field. For example, if it sees "Up 2" in the spot comments then it starts a new slice and sets the transmit slice to that slice so you're all set to call the DX on the correct split. All well and good but the controller (which does see the new physical slice being created) doesn't know that the new slice is part of its bailiwick. So you then have to manually tell the controller that yes, this new slice is indeed, for now, its VFO-B.

You see the problem?

I need to think about this some more but I am coming to the conclusion that I need to implement an optional mapping  system that permits me to map physical slices to virtual VFOs. That's a nuisance and it would mean that a multi-controller system working on different slices (e.g. an SO2R station) would not work but it's the only way I can think to handle the lack of virtual slice identifiers.

I'm planning to write some test code in the next few days.

Remote update II

Things are moving on. I now have two Internet accounts with different static IP addresses, so I can test remote access.

As earlier tests suggested, my controller code doesn't work remotely, even if it is running on the same PC that has negotiated a remote connection. That was somewhat disappointing but now I think about it, it would have been surprising (and probably not a good thing from a security perspective) had it worked.

The SmartSDR radio
connection page for V2

The key to remote operation is a new FlexRadio service called SmartLink. SmartLink brokers a one time only, single use connection between the radio (server) and a client application and having done so disconnects and is no longer part of the session. It's quite a neat solution that removes the need for a VPN.

So I need to understand how SmartLink works. FlexRadio has provided some code in the latest FlexLib API package but there is insufficient detail for me to work out how to code it myself. Or perhaps I'm just not good enough at reading code written in C!

The technical guys at FlexRadio are, apparently, putting together a white paper that will explain the interface for developers to code to but as yet there is no time scale for publication. Meanwhile, adding remote operation capability to my controller code is on the back burner.

How important is remote operation to you? If you're thinking about using my code, would you prefer to wait until it's available or should I release a non-remote version sooner?

Remote update

The UKSMG presentation seemed to go well but I wasn't able to do any sort of demonstration because, as I discovered when I got away from my own network, my controller code doesn't work with the new remote feature in Smart SDR V2. To be honest I am not surprised.

So there is new code to write! I have today made arrangements with my Internet Service Provider to get another broadband account set up with its own static IP address. This will enable me to test any new code that I write across the Internet, from one user account to the other. It will be a generally useful thing to have. Fortunately, I run one of the network nodes for our broadband service here at 'WGV Towers, so it's just a case of setting up a new account (already done) and connecting up another router. I should have it all working tomorrow, when the new router arrives.

I also contacted FlexRadio about the API for the new SmartLink features. Hopefully some documentation will be published soon and I can then see what needs to be done.

That's the thing with software... there's always something new to play with.

UKSMG talk & demo

This coming Saturday I'll be giving a presentation at the UK Six Metre Group AGM & Barbecue.

Wittily entitled "SDR and the Strange Case of the Disappearing Front Panel" it builds on my earlier presentations, reflecting my recent experiences and the changes that have been taking place in the industry.

I'll also attempt a remote demonstration back to my 6500 here in Cumbria. That should be, erm, interesting. The presentation is at 12:00 and will be the only thing standing between the audience and the pig roast. Wish me luck!

Integrated Maxi update

A while ago I discussed the idea of an integrated Maxi controller, which would include the Windows processing power to run Smart SDR, the Host controller application and other station software such as logging a program.

My evaluation of the Udoo X86 Ultra concluded that it was man enough for the job, so I set to designing the beast. My friend with the CNC milling machine cut me a new back panel and this evening I managed to get it all constructed and working.

 The big advantage of this approach is that it considerably simplified station design. Instead of two or more PCs, with lots of connections to the radio, controller and other peripherals, a large proportion of the station is now in just two boxes - the Flex radio and the integrated controller. Time will tell whether this is a sensible layout but I have a good feeling about it, at least for the sort of station I want to build.

The additional components, over and above the Maxi controller are:

• The Udoo X86 ultra single board computer, running W10
• A 7-port USB hub for external connections
• A built in 12V PSU

The PSU wasn't really necessary, as the power draw is low enough that a simple 12V 2A "wall wart" PSU unit would suffice but it seemed to me that as I was building an integrated system the PSU should be integrated as well. The USB hub is mounted on the back panel and provides connectivity to peripherals such as mouse, keyboard, sound card, WiFi dongle and so on. I think seven ports will be more than sufficient.

Other connections on the back panel are two HDMI outputs, each capable of supporting a 1920x1080 display, a wired Ethernet port and, of course, the mains power input socket.

I plan to take the new controller down to the G3WOS bash this weekend, so if you'll be there you can see it in the flesh.

Smart SDR V2

FlexRadio released its long awaited version 2 of Smart SDR a few days ago and, after a short hiatus while the techies sorted stuff out, I am now running the new version on my 6500.

V2 has a subtly updated API specification but I had been pre-notified of the small change and had already coded in the new facilities. I was pleased to fine that all my software, including the API library and host controller work just fine with Smart SDR V2.

I need to get my stuff away from chez 'WGV and onto a different network from the radio, to see how the remote capabilities in V2 work, both with Smart SDR and with my controller. More on that when I've given it a try but I am not expecting any issues *.

* Update: famous last words. New code required!

PCB and software update

A while ago I suggested that I would make PCBs available for those who wanted to build their own 'WGV FlexRadio controller. This is still my intention but on reflection I think that it is too soon for me to rush to production. Here's my current thinking:

1. The software really isn't complete yet. It's good enough for my style of operating (HF CW only) but I feel nervous about letting it out into a more general user environment. And, of course, I know where the quirky features are and I'm willing/able to work around them. There are several Flex control functions that I still need to write, mostly to do with modes that I don't really use or functions that I haven't found much personal need for. 
2. The hardware development, including PCB design, appears to be complete but I can't really be sure that there won't be another revision if software advances change the requirements.
3. There is a pile of documentation that I will need to write to give others a reasonable chance of building to my design. I'm not really ready to start on this yet.
4. I only have a very few people showing interest so far, certainly far fewer than is needed to justify a PCB production run of either mini or maxi boards.
5. I don't have a lot of time at the moment! Too many hobbies demanding my retirement time, especially during the summer months. This sort of thing is really a winter project.

So my plan is to aim for PCB manufacture and release of the software towards the end of the year, perhaps around RSGB Convention time, although that might be somewhat optimistic. If you are one of those keen to get started, I hope you will understand.

New features

It's been a bit of a busy time chez WGV recently, so I've not been able to make much progress on the controller project. The last few days has, at last, seen a flurry of activity and there are new features to report!

Firstly, I had been concerned for some time that the number of switch functions that could be supported, especially on the Mini-controller was insufficient. There is, of course, an easy solution that is fairly common in modern equipment - short and long presses of the same physical switch for differing functions. So that's what we now have. This effectively doubles the number of switch functions for a given number of physical switches and I think that should be adequate.

This involved quite a few changes! Firstly the I/O controller code had to be changed to recognise different hold times and respond accordingly. It still has no idea what these switch presses mean - it simply passes on the fact that the switch has been pressed for a long or short period. This in turn has created a minor change in the I/O protocol to the Host controller but it's been possible to do this without sacrificing backwards compatibility.

Of course the Host controller needed quite a fair chunk of new code, as did the Profile Manager. This is all completed and the code is now in use as my main station system, so I should tease out any bugs quite quickly. So far so good!

Next, I realised that it is quite hard to always know what a switch press has done, a problem that is exacerbated with the new long/short press code. I already had a solution in the way that encoder changes are shown as a pop-up note on the controller screen, so I have adapted that code to also show switch press functions.

With this work completed, I realised that I could afford the luxury of a few new switch functions, so we now have zeroing functions for the APF, noise blanker, wideband noise blanker and noise reduction functions. These can usefully be the long press functions of the existing, respective on/off switches. That's how I have configured it on my controller and it seems logical enough.

Finally, I have significantly improved the code around radio connection, detection of radios that have disappeared off the network and reconnection. This is really a tidy up exercise but the code is now much more robust in this area.

It's nice to be back cutting code!

The integrated Maxi

Briefly recapping, the Flex controller project has two principal components: the I/O controller and the Host controller. The I/O controller is effectively a firmware system that is logically part of the physical hardware. The host controller is any Windows-based system that does all the heavy lifting work of the controller application.

For the Mini controller, it makes sense that the host controller might be something like a laptop, thereby creating a portable package for remote use in hotels and the like. It seems to me that the Maxi controller is more of a base station beast and that is the logic behind the concept of The Integrated Maxi.

A typical FlexRadio-based station (mine, as it happens) has the following amateur radio software applications:

• Logging program
• Mapping application (e.g. DXAtlas)
• Propagation application (e.g. IonoProbe)
• Smart SDR
• Maxi Controller application

...and so on. With the exception of Smart SDR, none of these programs are particularly demanding in terms of processor power or memory. It therefore seems reasonable to run all these applications on a single Windows system. And if we are doing that then why not integrate it with the Maxi controller?

The problem is finding a suitable Windows platform. Required attributes are as follows:

• Sufficient processing power and memory to handle all required applications
• Support for up to three screen: one for Smart SDR, one for the logging and support applications and one for the controller display
• Low power consumption
• Good connectivity (network, USB)
• Small physical size

That's quite a shopping list. I've started experimenting with the UDOO X86 Ultra, which appears on the face of it to meet all the above requirements. With 8GB of RAM, memory isn't going to be a problem but processing power might be. Connectivity and the other attributes are satisfactory.

Here are the UDOO X86 Ultra CPU loadings for the above applications:

• Logging program (StarLog): up to 3%
• Mapping application (DXAtlas): <1%
• Propagation application (IonoProbe): <1%
• Smart SDR: Typically 27% *
• Maxi Controller application: Up to 4%

* The Smart SDR CPU demand is very much dependent on the application's display settings . The figure given is at 20 frames/sec and 70% average, which are values that I seem to like. A reduction in FPS has a corresponding reduction in CPU load and is not really visually noticeable until FPS<14.

With all applications running, total CPU load is around 36% which gives good headroom for peaks. Here's a picture of my test lash-up:

I'm using a SATA III SSD, which has more performance than I'm ever likely to need but rotating discs are so last year and SSDs are getting cheaper all the time. I happened to have an unused copy of Windows 10 Professional lurking in the shack so despite my misgivings about the W10 platform, I have decided to use it here. Needless to say I have turned off every bit of snoopware that I can, disabled Cortana and so on!

Power consumption at average load of 33% is around 0.9A at 12V, which is very satisfactory, given that the PC is likely to be on 24x365. At 33% CPU load the CPU heatsink is not quite sufficient on its own, so a small temperature controlled fan has been added, which only runs about 25% of the time.

So far so good. Testing continues...

Belated update

I've been rather remiss in updating this Blog over the past couple of months, although the truth is that not much has been happening on the FlexRadio Controller front.

The USA trip went well and it seems that my presentation at Visalia CA was well received. The visit to FlexRadio in Austin TX was somewhat abbreviated due to staff availability and not helped by a configuration c***up on my part which meant that I was unable to demonstrate the controllers properly. It wasn't until I got back to the UK that I realised what I'd done wrong!

Now safely back in Cumbria, I've been gaining some hands-on experience using the controllers to chase DX and on the whole everything seems to work admirably. A few minor problems have been teased out and the code is moving forward as a result but at nowhere near the pace of a couple of months ago.

My mind is now turning to integration of the host processor into the Maxi Controller cabinet. The key component of this is a Windows Single Board Computer (SBC). I have received and am evaluating the Udoo X86 Ultra SBC for this role. Early indications are promising. The idea, if there is sufficient processing power, is that the SBC will run Smart SDR, the controller host program, logging program and any other ancillary programs needed for DXing. I'll write more about this soon.

Going international

It was great to see lots of people at the GMDX convention last weekend. My presentation seemed to be well received and generated a good number of in-depth questions. It was the right decision to not do a demonstration as part of the presentation: there wasn't enough time and it would have been too disruptive. Instead I set up a demonstration station in the coffee area and had a large number of interested visitors with often quite technical questions. It is clear that there is a lot of interest in SDR these days.

My mind now turns to the International DX Convention, more commonly known simply as Visalia. I will be giving a broadly similar presentation there on Friday 21st April at 10:30 in Charter Oak, rooms A/B/E. Again there will be no demonstration but the plan is to have my controllers on the FlexRadio booth. If possible I will try to connect one of them up to a Flex radio - I am sure they'll have one or two there!

If you're a delegate at the convention, please do come by and say hi.

GMDX Convention

I'm starting to pack up everything ready for the GMDX Convention tomorrow. I'll be presenting my paper at 15:30 but there will not be time to attempt any sort of demonstration during the presentation. Instead, I hope to be able to set up a demonstration in the adjacent room, where coffee is served and I will try to man that during break times.

I will have both mini and maxi controllers running but as my laptop is somewhat video ports challenged I'll only be able to display either the mini OR the maxi screen actually on the controller's built in display.

Looking forward to seeing lots of you there.

PCB update

I now have a few requests for PCBs and am planning to place an order for 10 of each board - mini and maxi - in the next few days. The cost difference per board between 10-off and 25-off quantities is under $1, so there is no real advantage in taking the risk with a larger quantity.

If you think you might want a board or two please do let me know - full details are a few posts below this one.

Update 2017-04-09: The PCB order will not now be placed until I return from Visalia.Too many issues to resolve in the time available and it was always going to be tight on delivery time scale, so it's better to wait until I am back from my travels.

Mini controller finished

The mini controller is in its box and looks great! This should be a really good form factor for remote operation away from the shack.

Showing VFO-B as the control VFO (note underlined frequency!)

I'll be taking both the Mini and the Maxi controller to the GMDX convention this coming weekend. All I have to do now is finish my presentation...

Maxi controller QRV

Today I completed construction of the Mk II Maxi Controller and put it into service as my main station radio controller. This involved moving the host controller code over to my station PC - the first time the code has been fully separated from its development environment.

The development environment is a considerably more powerful system, so I was interesting to see how the controller would work on a less powerful and, perhaps, more commonplace processor. In fact only one problem emerged - it was necessary to add a few lines of code to ensure that the default  Windows time slice was set correctly so that the many timers in the code would work reliably. This had not been a problem on the development machine but it was soon readily apparent on the station system!

So this is a big step forward today. The Mk I controller has been retired and I am now fully operational with the Mk II hybrid architecture. So far it seems to work just fine, although conditions are poor and there's not much to work.

Big empty box! All the Maxi hardware is on the panel PCB

At least the box can be used as a base for the microHAM

A general view of the 'WGV station

PCBs 4 U?

As long term followers of this Blog will know, I have now designed and prototyped two printed circuit board designs: A single VFO knob mini-controller and a two VFO knob maxi-controller.

The mini-controller PCB

These PCBs work well and the time has come to decide whether to make them available for others to build their own controllers. In some respects it would be nicer for potential builders to come up with their own physical layouts, in pursuit of one of the main objectives of the project: a fully bespoke solution.

The maxi-controller PCB

Not everyone will want to do that, of course. For those that want to brew their own I will publish full source code for both the I/O controller and the Host controller. I'll make the PCB "Gerber" files available and I'll also publish DXF files for the panels I have designed, suitable for CNC milling.

I'm looking into PCB production costs. Perhaps unsurprisingly but disappointing, nonetheless, I can order PCBs from China and have them here inside a week for less than half the cost of an equivalent UK-based service, even after import duties and VAT are accounted for. Costs, landed in the UK, look likely to be in the order of

Mini controller: £12.00
Maxi-controller: £15.00

These costs are based on minimum orders of ten of each. The price comes down somewhat at higher volumes.

Who who wants one (or more)? Contact me via e-mail (see QRZ.com). I'll start putting a list together and see where we get to.

Mini controller built

Things have been a bit hectic at 'WGV Towers recently, so there hasn't been much progress to report on the mini controller. I did get it built and have spent some time playing with the software.

In fact rather few issues remained and the mini controller works very well indeed. I have a few minor additional functions that I'd like to implement to make the mini controller more flexible but in general I think we're pretty well there.

I'm just waiting for the mini controller and Mk II maxi controller aluminium panels to come back from CNC milling. I'll then be able to spray them and mount the PCBs, ready for the trip up to Stirling for the GMDX Group presentation at 15:30 on 1st April, A couple of weeks later I'll be heading off to the IDXC at Visalia, where I'm giving a similar presentation on Friday 21st April at 10:30. I'll post more about that in due course.

Mini PCB

The PCB for the mini controller has at last arrived! Of course it would turn up when I have a ton of other things to occupy my time but I hope to get around to populating the board in the next couple of days. Meanwhile, some pictures will have to suffice...

The new panels are in for CNC milling and should, hopefully, be with me in the next week or so. Not really an urgent thing, as I can do all the software testing I need to do with just the PCB.

I have three mini controller PCBs and will probably construct two of them, so I can test multi-controller capabilities.

Mini controller PCB update

I have now finalised the mini controller PCB design and it has gone into production today, so I should have three PCBs by the end of next week. Next up is getting the front panels for the maxi and mini controllers CNC milled, hopefully by no later than the middle of March.

It won't take long to build the mini controller board but I fully expect to uncover some new software issues once I have it running. The main issues will probably be around the use of a single physical VFO encoder to control two logical VFOs. Watch this space!

Mini controller PCB

The (hopefully) final design of the mini controller PCB is now completed and should be going into sample production this week. The mini controller has a single VFO control which can be switched between VFO-A and VFO-B, eight push buttons and four encoders with optional push switches. The plan is that it will fit in a small sloping front instrument case and be suitable for remote operation from a hotel room or wherever.

The mini-controller circuit diagram

PCB layout

Panel layout

My plan is to have examples of both Maxi and Mini controller available for demonstration at the various talks I am giving this year, starting with the GMDX talk on 1st April.

G3WOS 6m BBQ

I've been asked to present on SDR and my controller project at Chris, G3WOS's 6m BBQ on 5th August 2017. This talk will be somewhat different, with a 6m slant and probably more operational anecdotes, with a little less technical content. Although I've been QRV on 6m for many years and always get on the band for the summer Es season, I wouldn't really consider myself to be a 6m aficionado, so I shall have to watch what I say :)

See you there?

Maxi PCB II

Hurrah! The maxi PCB arrived on Saturday and I've fully populated it with controls. Everything works exactly as it should, which is something of a relief.

At the front are all the switches and rotary encoders together with the display. Not visible are the four VFO Tx/Rx control switch/LED units and the two VFO encoders. These fix directly to the aluminium front panel and are connected to the PCB with header pins.

The back of the PCB has the Arduino Due piggybacked onto the board, behind the LCD display and the two 16 bit switch multiplexers, which are also piggybacked onto the main board. On the left you can see the HDMI ribbon cable which attaches to the display on the other side of the board.

I can now get on with finishing the software, a task that was on hold because I needed the full hardware environment for testing. I'm also working on the Mini PCB, which I am hoping to get into fab early in February, although these things always seem to take longer than I expected. The two aluminium front panels, one Maxi and one Mini are also in for CNC machining.

Plenty to be getting on with ahead of the lecture series planning for April.

Maxi PCB

It's been too long coming for all sorts of perfectly valid reasons but at last I have the completed PCB design for the Maxi-Controller.

The Arduino I/O processor is mounted on the PCB, behind the display and this means that all the connections to the various controls can be printed as tracks, considerably reducing the amount of wiring required. Of course it makes the board a lot more complicated and that is one of the reasons it's taken a while to get it right.

Most of the problems aren't, in fact, anything to do with the PCB circuitry. Mainly it's a case of getting all the components to fit without getting in each other's way and, notably, ensuring that the few cables that are required don't snag on other parts of the board.

For example, it has proved necessary to move the two vertical columns of pushbutton switches about 4mm further away from the display so that the display's HDMI cable can be fitted. Similarly, we had to move switch multiplexer 0 from the top of the board down to the bottom in order to make room for the USB cable to the Arduino.

The good news is that in fixing the maxi-controller board layout we have now solved pretty well all of the problems we are likely to come across on the mini-controller PCB. Once the maxi board is into fab we can get started on the mini PCB and should have it done in a few days (famous last words!).

Here are a few more views of the PCB

HNY

Happy New Year to all my readers.

I finally did it! As a new Year's present to myself I've at last made the Flex 6500 and my Mk I controller the main station radio. In truth I've been using it for several months and the FT5000 hasn't been turned on in as long but today I moved the FT5k out of the shack and the Mk I controller took its place at the main operating position.

I've made a bunch of QSOs to check that everything is working OK. It is. Of course this isn't the end of the story, not even by half - there's the Mk II on the horizon and to be honest I really need to redesign the layout of my station rather than just plonking the controller in place. But that's for another day. Right now, I'm off to make some more QSOs.