Starting a numbered slice

John G3WGV

At present, when one starts a new slice the radio just starts the next free slice. There is no way to tell the API to, say, start slice 2, unless slices 0 & 1 are already in use.

I suggest that it would be useful to be able to specify which slice is to be started. The reason is to do with support for multiple clients:

If, say, I have a 6500 then I have four slices available. Generally a single client will only use two at most but there is nothing to prevent us from having more than one non-graphical client. If we could specify slice numbers then we could allocate, say, slices 0 & 1 to controller A and 2 & 3 to controller B, starting them and stopping them on a per-client basis as required.

Why is this useful? In a single radio multi-operator environment, a second op could have his own client to scan around the band while the main op works stuff. The two clients could easily cooperate to determine which client is the TX client/slice to further enhance flexibility.

The slice create API command could have an optional slice number parameter, which if present starts the specified slice. If absent then the next available slice is started. There would need to be an error response if the client tries to start a slice that is already in use.

Ken - NM9P

I would find that handy in SSDR.  

It I could have an option when opening a new pan or slice...perhaps right-click on the +PAN or +RX button instead of left-clicking it, and be asked which of the available slices I would like to add, that would solve a lot of hassles.

For example:  I like to have A & B available on my 6500 for working split when hunting DX, etc.
But I have Slice C designated in the CAT profiles as assigned to WSJT-X with auto-switch enabled.
Then here is the snag scenario...

* I am out and about on 40 SSB on slice A, but don't have a split running on B.
* I decide to run some JT65 on 160 while I tune about.
* I open a new panadapter and it opens a new slice...as 'B'.  (But I want 'C')
* I either must open another one for C and move it to 160, then close the unneeded 'B'...
...or I must first open an unneeded B on pan 1 before opening a new pan, which will automatically open a correct 'C."  But then i need to close the unneeded 'B."
...or I must accept the slice B previously opened and reconfigure my WSJT-X program to use a different CAT/TCP port which is assigned to B.

All three options are viable, but time wasters.

Having an option to designate a new slice when opened would be wonderful.

It would be even more hand when multi-clients are implemented... the "rig admin" could assign particular slices as available to particular users or client devices, which could access a list of available slices and select which one they want to open...important if they also have assigned particular COM/TCP ports to particular slices.....

My 2 cents...

Ken - NM9P

Bob G W1GLV

Ken, I hear you. Slices should be profile specific. The global specificity does not work well with multi slice radios. I just had a conversation with Eric on this subject.

Ken - NM9P

Thanks, Bob.
I never thought about this much until I recently started getting back into the JT modes.  

Some folks might answer my post with "Just set up a profile for that."
The problem is that using a Global Profile would change what I already have on Slice A/B and pan 1.  I just want to open a new pan with Slice C, without messing up what I already have gong.

But...I DO understand that this is an extremely complex system, and something that seems simple usually isn't!  ha.

Hopefully that can add this one to "the list."

Ken - NM9P

John G3WGV

So... the question is, is it technically feasible? And if so, could it be added to the roadmap? One for Eric I think.

73, John, G3WGV

Steve-N5AC

John,

The original way I conceived this working is that slices are numbered in the radio 0..N.  Then as we support multiple clients, clients will receive a mapping between numbers and letters.  So for example, client #1 might get slices 0, 1 and 3 and client #2 might get slices 2 & 4.  They would receive the mappings A, B, C and A, B respectively.  My rationale here was that you would not know how many each client could have and reusing the letters for a given client is the most comfortable for the operator.  This is why there are both numbers and letters in the operation of the system.

John G3WGV

Hi Steve,

Thank you for the interesting insight. I had not come across the idea of lettered slices and they don't seem to be exposed in the API, which deals only with numbers as far as I can see, so I think this must be an internal mapping.

What I think this tells me is that I have approached the slice concept from the wrong angle. In my controller design I effectively allocate slices to VFOs (by configuration rather than in code). So in a two VFO controller, I might allocate slices 0 and 1.

It seems that a better approach would be to treat the slices as a "pool" from which controllers acquire slices as required, returning them to the pool when no longer required. So there is a dynamic relationship between each VFO and its slice number for the time being.

I need to think about this some more because there are probably ramifications that are not immediately obvious. It seems logical enough and I cannot fault your approach as originally conceived. Just need to think how to do it at my end!

Thanks again.

73, John, G3WGV

Steve-N5AC

Yes, they should be treated as a pool.  Lettered slices are all that appear in the clients (SmartSDR and the like).  The letters are not discussed/exposed in the TCP/IP API today, but there is an implicit mapping in the single-GUI-client world, namely 0=A, 1=B, etc.  Part of the challenge (of adding multi-client) will be to identify the non-GUI clients that map to GUI clients.  For example, assume two GUI clients (SmartSDR, Maestro) each with a couple of slices operating virtually autonomously off of the same slice pool in the radio as we discussed before.  Each of these clients might want to use CAT so that their logger will be able to track their operations.  Now we must map a CAT client to a GUI client and not "cross the wires."  

John G3WGV

Part of the challenge (of adding multi-client) will be to identify the non-GUI clients that map to GUI clients.

Yes! That's exactly what I am pondering at the moment. Typically I have SSDR running together with my non-GUI controller and logging software as separate API clients that work with the same slice(s). Mapping the relationships between slices and these clients is an interesting challenge. I'm not entirely sure that the API provides me with sufficient information to do that unambiguously in all situations. My initial thoughts are that I need the client mapping letter to be exposed (even better would be some sort of client defined identifier) but it's early days yet.

Are there some changes afoot in this area?

Steve-N5AC

Yes, we've fairly broadly promised a multi-client capability that allows multiple GUI clients to talk to the radio at the same time.  The original SmartSDR code in the radio was written this way, but we abandoned the code when it appeared to unnecessarily complicate things as we were nearing our first release of the software.  So we will be circling back around after our WAN release and working on delivering this functionality.  Part of that task will be to determine the best way to handle this specific challenge and make it as backward compatible as possible.  In other words, we don't want to break any existing clients if we can avoid it.  I expect to expose the API details of this as we start this work so that others' clients can participate.

John G3WGV

Great, Steve, thanks.

May I suggest:

1. A set_clientname <string> command
2. When there are slice in use changes, in addition to the slice in_use field send client <clientname> and <sliceletter> <sliceletter> fields

That would be backwards compatible and would provide much useful information for awkward folks like me! It's not just for multi-GUI capability - this is important for any client that needs to be aware of its surroundings.

Steve-N5AC

OK I added your comments to issue #3700 (multi-client) for consideration when we do the work.  Thanks

John G3WGV

This is why I find it so satisfying to be dealing with FlexRadio. Can anyone imagine YaeKenEleCom doing that?

VK7WH Winston

Hear hear!