10 August 2017

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?

7 August 2017

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.

2 August 2017

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!

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 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!

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:
  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.

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!