Maestro!

I decided that I needed to check out the "competition", so I've bought a Maestro. And very nice it is too. The logic in this perhaps baffling decision is that I can probably learn a few good (and, no doubt bad) points about the approach that Flex Radio has taken to the problem. Time will tell whether I decide to keep the Maestro but there is certainly no plan to stop development of the G3WGV Flex Controller.

So, some immediate observations...

The VFOs. I am very much surprised to find that Flex has only used 64 step encoders for the VFOs. That compares with 400 step devices that I am using. 64 steps means that the knob has to rotate 5 degrees per frequency step and it gives the tuning a very soggy feel compared with, say, my FT5000. This is largely mitigated by a rather excellent wheeze in which the tuning rate is speeded up if you spin the knob, so it's easy to get around the band, even with the otherwise very slow tuning rate. I think I know why they have done this but I will keep my counsel for the time being, pending more investigation.

The display. It is truly impressive. The 8" touch screen is big enough for a proper pan adapter display, although perhaps a little small to run two. In some ways it makes me wish I had decided to go for a bigger display as well. Perhaps version 2!

Encoders. There are ten, in the form of five dual concentric controls. Like my design, each has a push button that selects fixed options appropriate the the control. Unlike my design these are not programmable. The key functions (AF gain, shift, width, CW speed, mic gain, TX power are all there and there are separate controls for the A and B VFOs. I can't really find anything to fault here.

Push buttons. Only three on the Maestro, with a shift function giving six in total. Not many (I have 16) but the range of things that can be allocated to these buttons is very limited, so perhaps not a problem. Changing band and mode is achieved by pressing the VFO knob, which sort of makes sense. This brings up a huge menu of touch buttons that permit most of the receiver functions to be changed. Similar approach to mine really.

Size. The Maestro is pretty big! Its front panel is pleasingly uncluttered but compact it is not. Much of this is down to the big screen, which is more than 50% of the panel real estate. No problem with this as such but I think there is a need for something smaller, e.g. my proposal for a mini-controller.

Main issue. I notice that some of the controls, including, sometimes, the tuning, results in a faint but irritating clicking sound in the received audio as the control is moved. I have noticed the same thing with my controller, so this is obviously an issue with the radio/Ethernet interface. This is going to be part of a major investigation as it is, to my mind, not acceptable.

My initial conclusion? It's a very fine piece of kit and I think Flex has done a great job. It has some things that would irritate me, notably the VFO encoders and that provides renewed impetus to get my controller running. There are a few neat ideas that I might decide to "steal"...

Architecture rethink

I have been spending some time thinking about the overall architecture of the controller.

At the moment I am using two Arduino Due processors, one for all the control stuff and the other for managing the display functions. The two processors are connected via a byte-wide bi-directional parallel bus with a simple packet protocol that I devised to manage communications. This is OK but a number of architecture-specific issues arise:

1. Fast though the byte wide comms channels are, they will probably struggle with the data rates needed to support pan adapter displays.
2. I'm finding that there is rather a lot of additional code associated with splitting the work between two processors.
3. The display processor is very underutilised and it is therefore something of a waste of good hardware. Arduino Dues are cheap enough but the reality is that everything can be done from a processing perspective with a single processor.
4. It's proving difficult to get the parallel interface to work reliably. It's not clear why but it seems to be something to do with the way that power is managed on the Arduino Due processor boards.

The reason I went to a dual processor architecture was because of difficulties with the physical implementation of all the components onto a single processor stack. Specifically, the interface board for the display cannot interwork with other boards such as the Ethernet controller. There is a secondary issue that these boards also fight for resources on the SPI bus, as discussed in an earlier posting.

Well things are changing. A new display interface board is soon coming to market that will permit proper "stacking" of all the boards. I have been working closely with the developer and it looks like this will solve the physical implementation issues. The problem with SPI resource management is still there and is a nuisance. However, I have access to all the code and it should be possible to find a fix. Not for the faint-hearted as it involves messing around in the drivers.

I would really like to get back to a single processor configuration if possible. My experience so far is that the dual processor solution creates more problems than it solves!

What with this and the PCB work in progress, it's unlikely that there will be much progress to discuss here for a couple of weeks.

PCB is in Fab!

Today I received and approved the final PCB layout. It has now been submitted to the PCB shop for manufacture. I'm getting two boards done so I have a spare in case of disasters! If anyone else decides that they want one to play with then it will be easy and comparatively inexpensive to have more made.

In the end I accepted a 12 day turn around for the PCB as it was quite a lot cheaper than the five day turnaround. The PCBs are costing GBP98, of which GBP50 is a one off set up charge. That doesn't seem unreasonable for what is really quite a large double-sided fibreglass board with a proper silk screen.

It's been a time consuming and surprisingly complicated process to get from the basic idea of a PCB to one that can actually be fabricated. I could have just done it with bits of Veroboard but now I look at the complexity of the wiring I am glad I decided to do the job properly!

The front panel design is also ready to go to production and I should have that back at about the same time as the PCBs. It will be really nice to get the rat's nest that is my current prototype all neat and tidy. I've more or less got as far as I can with the rat's nest anyway.

PCB tracks

The last week has seen rather little activity on the development front because I've been away at Bletchley Park, getting some flying in and working at the airport to pay for same. The PCB layout work has more or less been completed however, so it's time for an update.

This is the component layout drawing. The rotary encoders and push button switches are mounted on the front of the board (the side facing the panel). The encoders help to mount the board to the panel but in addition there are mounting points shown by + signs to stop the board flexing too much.

This is the track layout on the front of the board - the side nearest to the panel. This side will also have silk screened legends.

Finally, the track layout on the rear, facing away from the front panel. This side of the board also holds the various headers for connection to the processor, etc and the two switch multiplexer boards.

We decided that the LCD display should be mounted onto the PCB rather than being separately mounted on the front panel. This reduces the number of mounting holes but also means that the complete ensemble can be constructed and tested away from the chassis and cabinet.

I'm hoping that we can get this into the PCB fabrication shop early next week. There is a two week lead time for production and in the meantime we should be able to get the front panel milled. A lot of things will start coming together in a couple of weeks time!

PCB layout

Here is the first draft of the physical layout for the PCB. This is fiendishly difficult to get exactly right because the physical dimensions and relative placement of components is so critical. We're not quite there yet but it's a good start. We are thinking that we'll get the PCB layout right and then use it as the template for the panel.

Power supply

The arrival of some goodies from RS Components this morning prompted me to get on with the power supply side of the project. The issue here is that on power down it is necessary to cleanly close the Flex radio interface and save configuration/operational data for next time. It's not acceptable to just dump the power!

I fabricated the circuit on a prototyping board. A 7.5VDC "wall wart" provides the raw power and this is regulated down to 5V, as required by the system, by a 7805 voltage regulator.

When the power switch is set to ON the solid state relay conducts and sends power to the equipment. The control processor then sets pin 48 to high which lights the LED and also makes the transistor conduct, holding the relay closed.

When the power switch is set to OFF, this sends a shut down request via switch 31 to the control processor, which then closes everything down cleanly before dropping Pin 48 to low, thus removing power from the equipment.

A simple circuit that does exactly what is needed.

PCB update

This morning I have approved the final PCB schematic and we now move on to the next phase, which is the layout of the parts on the PCB.

This, of course, is the schematic for the maxi controller, with dual VFOs and eight general purpose rotary encoders. The mini controller circuit/layout is not yet on the drawing board!

Do you want one?

When I started this project it was because I saw a need for me personally that I thought I could see a way to making a reality. Various conversations with others led to me starting this Blog and, as a result, a few people have expressed an interest in having their own 'WGV Flex controller. Here are some thoughts on how this might work.

Firstly, I think it is highly unlikely that this will ever become a commercially available product. There are numerous reasons for this, notably that some of the code libraries that I employ are on the basis of non-commercial use and the fact that I am not keen to get into selling amateur radio software - I've been there and done that and have no wish to do so again.

But... There are ways and means.

Firstly, let's look at the software. I would be perfectly content to make my software available at no charge, on the clear understanding that its value is what you paid for it and the support entitlement is limited to that value.

The way Arduino code works is that you get the complete source code and have to compile it (using the free Arduino IDE) and then load it on to the Arduino board. This effectively means that this is no turnkey solution. Anyone using the software would have to be willing to compile it and do configuration, etc. at the very minimum. In many cases the user would need to modify the code to his own requirements. So a reasonable level of computer literacy and a willingness to experiment will be essential.

Next, let's consider the hardware. Much of the computing side is easy to define. It comprises a pair of Arduino Due processors, a display, high resolution VFO rotary encoders, various push buttons, multiplexer boards and general purpose shaft encoders. All these components are readily available from the likes of Rapid Electronics and RS Components, with the possible exception of the VFO rotary encoders, which may require a bit of research.

Some sort of enclosure will be required and this is very much a matter of user preference. I have so far identified two layouts, maxi and mini, but neither design is fixed (yet). It may be that we could come up with a couple of standard layouts for specific enclosures. In that case I would probably be able to arrange for CNC milling of the panels, at cost.

Another possibility with standardised layouts is the production of PCBs. In one off quantities, these are extremely expensive but the unit cost rapidly reduces even with quite small quantities. Of course there is no absolute need to have a PCB at all - it can be done, albeit nowhere near so nicely, with Veroboard.

So there you have it. This is more of a DIY project than an off the shelf solution. Still interested? It would be very useful if you would let me know, without commitment, of course, so I can gauge the actual level of interest.

Mini controller?

A key design criterion for the G3WGV Flex Controller is that it can be physically implemented according to personal taste. The software is designed from the outset to work with essentially any number of controls, all of which can, within reason, perform any function.

Right now, my development work is focussed on a physically quite large controller and I discussed the logic of this approach in some detail here. As I start to see light at the end of the long tunnel of concept through initial development, my mind is turning to the possibility of a more compact form of controller. The main driver for this is the prospect of operating remotely, perhaps from a hotel room when I'm away from home.

The debate quickly boils down to ergonomics, convenience and the resultant physical size of the panel. My thoughts are tending towards the idea that the mini-controller would only need one VFO knob (capable of controlling either VFO at the press of a button), four rotary encoders and eight push button switches. For numerous reasons, I would want to retain the 5" TFT display. This could give rise to a physical layout something like this:

In dimensional terms, this panel would be about 200mm wide by 130mm high (8" x 5"). As there is very little "inside the box", there is no real need for depth and the controller could go in a sloping panel console style of enclosure, perhaps something like the one below.

This would make a quite compact controller that could easily be taken on trips or, as the Flex radio permits multiple controllers, used as a secondary controller - an intriguing prospect.

I would be interested to hear what my readers think about this (if any remain - you're mostly somewhat uncommunicative for much of the time!).

PCB design

I received the initial draft schematic for the panel PCB last night. Even though there is virtually no logic involved it is still moderately complex and I think it is a good plan to have all this wiring on a PCB rather than trying to do it with Veroboard or point-to-point wiring.

There's a few minor changes to be made before my friend starts laying out the board itself but this is a good start.

Eureka!

I have discovered what was causing one of the VFOs to tune slowly and I have also learned how to make my Flex controller work independently of the Smart SDR PC application. Both had been causing much head scratching!

The VFO problem turns out to be a known bug in the flex API, which results in numerous spurious messages about the status of the ATU being interspersed with response messages from the VFO tuning. These ATU messages should normally be very infrequent and they seem to take quite a long time to be issued, hence slowing everything down. For the time being I have unsubscribed from ATU messages and the problem has gone away. In due course I imagine that Flex will issue a new version of the radio's firmware that will properly fix the issue.

The matter of being able to operate the controller in stand-alone mode was mainly a case of understanding how Smart SDR works. I now know that SSDR closes all slices when it exits, resulting in, effectively, no radio. So the solution was simply to detect that there were no active slices and create one. There's a bit more to it than that and I am sure I shall find more things that I need to attend to but this is still a significant step forward in my project, as it means the controller can run in stand alone mode (possibly remotely) or in SSDR integrated mode.

In other news I spent a couple of hours this evening discussing the design of a PCB to go behind the panel for mounting all the panel controls with a pal who runs a small business doing this sort of thing. It would be a very neat solution but it certainly isn't a cheap option! It seems that it will probably have to be a double sided PCB and that adds cost to an already expensive prototype. I should have a quote in about 10 days and the ouch! factor will have to be evaluated at that time.

More coding

Progress on various fronts this week. Firstly, I completed the parallel I/O link from the display processor to the control processor. This means that bi-directional communications are now possible and it has enabled me to get started on some new sections of code.

First up was the band selection logic. This is accessed via a physical push button, revealing a page on the screen with touch screen "buttons" for each band and a separate frequency entry keypad. The touch screen logic that I was working on a week or so ago can now directly control the Flex radio. Touching a band button activates X/Y screen positioning logic that determines which button was pressed and constructs a band change request that is then sent to the control processor via the parallel I/O link. Here is is translated into the correct format command for the Flex radio and sent to the radio via the Ethernet link. The process is more or less instantaneous.

Flushed with success, it was a comparatively simple process to do the same thing for mode control. This, too, is now working.

Along the way I discovered and fixed a particularly exasperating bug that resulted in the wrong filter bandwidth numbers being displayed on the screen... sometimes. As so often is the case with real time systems, it was a matter of timing between two separate processor threads.

I've also unearthed an odd fault that sometimes results in the first slice tuning very slowly. This has me stumped at the moment, all the more so because I hadn't seen the problem before the radio went on vacation to DL. I'm beginning to suspect something in the Flex/SSDR set up, as I cannot see anything in my code that would give rise to such an effect..

Finally, I've wired up and written some code to support the LED push button switches that manage the VFO Tx/Rx configuration. The intention is that this will work in the same way as the red & green LED switches on the FT5000, which is simple, easy to understand and very effective.

Next up will probably be more radio controls, now that I have the touch screen system working. There are also numerous minor rotary encoder functions such as RIT & XIT yet to be implemented. Each of these is relatively simple now that the infrastructure software is in place but there are rather a lot of them!