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!
2 August 2017
1 August 2017
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 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.
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!
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!
17 July 2017
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:
- 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.
- 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.
- 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.
- 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.
- 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.
16 July 2017
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!
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!
19 June 2017
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:
The problem is finding a suitable Windows platform. Required attributes are as follows:
Here are the UDOO X86 Ultra CPU loadings for the above applications:
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...
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
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
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%
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...
16 June 2017
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.
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.
Subscribe to:
Posts (Atom)


