Starting a numbered slice

  • 3
  • Idea
  • Updated 2 years ago
  • (Edited)
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.
Photo of John G3WGV

John G3WGV

  • 189 Posts
  • 36 Reply Likes
  • like writing some more code, with band conditions being so poor

Posted 2 years ago

  • 3
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 4025 Posts
  • 1248 Reply Likes
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
Photo of Bob G   W1GLV

Bob G W1GLV

  • 676 Posts
  • 114 Reply Likes
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.
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 4025 Posts
  • 1248 Reply Likes
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
Photo of John G3WGV

John G3WGV

  • 189 Posts
  • 36 Reply Likes
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
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
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.
Photo of John G3WGV

John G3WGV

  • 189 Posts
  • 36 Reply Likes
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
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
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."  
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
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.
Photo of John G3WGV

John G3WGV

  • 189 Posts
  • 36 Reply Likes
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.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
OK I added your comments to issue #3700 (multi-client) for consideration when we do the work.  Thanks
Photo of John G3WGV

John G3WGV

  • 189 Posts
  • 36 Reply Likes
This is why I find it so satisfying to be dealing with FlexRadio. Can anyone imagine YaeKenEleCom doing that?
Photo of Winston VK7WH

Winston VK7WH

  • 248 Posts
  • 42 Reply Likes
Hear hear!