26 August 2017

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.

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!