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.