Stable identifier for API Slice object?

Wayne, W5XD

I am working on a program that wants to cooperate with SmartSDR while monitoring/controlling the FlexRadio. The key object in the API my program has to deal with that I want to understand better is the Slice. I prefer my program not duplicate SmartSDR's ability to present the user with the details of getting a Panadapter associated with the antenna selections for both transmit and receive, along with the associated radio-model-specific limits to how many and what associations are possible.
The problem I have is there appears to be no stable and persistent association between a Slice object and its mapping into Panadapters. By "stable and persistent" I mean, among other things, an identifier that survives an exit of SmartSDR and starting it over. The only identifier I see in the API is the Slice.Index property. Just watching SmartSDR's behavior it appears (and there is no documentation I see to this effect) that the Smart.Index property is mapped exactly to its on-screen letter label: "A" is Index==0, "B" is Index==1, etc. But even that user display--without my program involved at all--is not stable with respect to an exit and restart of SmartSDR. If I use SmartSDR to delete the Slice labeled A and exit. When I restart SmartSDR, it seems to know about its Panadapters and Slice's from before its exit, but on restart it letters them starting with A. What if my external program did not exit. My program has no trouble noticing via the Flex API that Slice objects disappeared with SmartSDR, and reappeared when SmartSDR returns, but it has no (reasonable) way to figure out the correspondence between the Slice objects it was monitoring/controlling before SmartSDR's exit and those it has after the restart.

Here is another scenario: I think its reasonable that my program model split-frequency operation with a pair of Splice objects: one of them is mapped to my receive frequency, and the other is mapped to my transmit frequency (also known as the frequency I hope the other station is receiving). And consider at the same time a slightly simplified scenario, I think its also reasonable for my program to model tranceive operation on a single frequency with just one Splice object. So, as the programmer, I conclude I should delete and create an "extra" Splice object as my user switches between operating transceive and split. But the API does not, as far as I can tell, offer me a way to identify those Splice objects that "belong" to my program. I see in the Api that, given I have found a Splice object for tranceive operation, I can request the API create a new one on the same Panadapter (which lets me defer the antenna selection to the SmartSDR GUI.) But the API doesn't just give me back a reference to "my" Splice object. Instead, I have to request its creation, and figure out at event delivery time if the Splice.Index not-negative that got added is, in fact, the one I requested.
Another thing I mean when I say "stable and persistent identifier" is that it should make sense to the SmartSDR user that what appears in my program as something that seems to have properties like a Slice does (like a frequency and mode and antenna selection) is exactly the same thing as something she sees in her SmartSDR GUI. I would be willing to settle for the convention that slices of a certain letter label are those being used by the external program. (Maybe it would be better to have a way to extend this with longer text descriptions and/or custom icons that SmartSDR woudl display?) But I am pretty sure I cannot make this concept work with SmartSDR's current convention of insisting that any newly created Slice takes on the lowest letter currently not in use (or did I get that wrong? there is no documentation to this effect--its just what I see on my screen). Simply the ability to set the on-screen identifier to any letter not currently in use would be a big help, along with having it survive an exit and restart of SmartSDR.

Or is there some other way to solve this problem?
Thanks,
Wayne

James Whiteway

I think you are going to find that having the first Slice labeled A is the default action in SSDR. Also, as long as your program is not the GUI client (API.isGUI= true) And at present there can only be one GUI client, others can run concurrently, but only one panafall client, and once SSDR is shut down, the radio will no longer be able to be controlled by your app. Maybe some of that will help. james WD5GWY

Stu Phillips - K6TU

Wayne,

The slice.index property identifies the slice instantiation and by convention, slice 0 is referred to as slice A, 1 to B etc.  SmartCAT then follows the convention that slice A is VFO A, slice B is VFO B for VFO minded radios.

The radio allocates slice index numbers sequentially as they are created.

The radio itself maintains state information based on when SmartSDR last ran.  There is a little wrinkle to this - the radio persisted state is saved based on the last active client which identified itself as a GUI client.  Currently there can only be one GUI client connected to the radio at a time.

If you have a client attached to the radio while running SmartSDR, you will notice that when SmartSDR exits, all open slices are removed.  Your client can create slices independently from pan adaptors (and you don't need SmartSDR running to do this) but again, they are allocated sequentially and you can't say "create slice X at frequency/mode" - X is always determined by the radio.

Split mode works as you describe - one slice for TX, one for RX but all slices belong to the Radio - not to the client.

The radio was written to work with one GUI client (at least currently).  All the API behavior reflects this.

Currently, there isn't a way to have client specific slices.

Stu K6TU