8 exclusive (as in ex OR) scan groups instead of 3 scan lists

[das-Iro]

With the recent change to add another bit to the scan list a wish I had came closer, scan groups.
I have my channels organized in groups, e.g. [simplex, 2m relays, 70cm relay, 10m & 23cm, PMR, Freenet, Sea Radio, open]
Most of my channels are either important/simplex or of a certain group.
Instead of having each channel have the attribute to be part any of the scan lists, I would prefer to flag groups of channels.
Instead of interpreting the 3 bits as individual scan list participation bits, they are interpreted as an exponentially growing (with number of bits) integer.
The 3 bits would allow for 8 groups, a channel could only be part of a single group, rather any combination of the 3 scan lists.
Example of scan groups:
0: dummy for channels that are not relevant (eg. Air Radio)
1: simplex
2: 2m relays
3: 70cm relays
4: 10m & 23cm experimental stuff
5: PMR
6: FreeNet
7: Sea Radio

Currently it is possible to select the scan lists with the keypad. Same could be done with the replacement of scan groups. Making the selection simple.

Additionally if a bit could be stolen from the compander (currently RX and TX are independent, that would be removed). Then a "favorite" bit would be possible.
8 scan groups + one independent scan list participation (favorites).

Would a patch with this feature change be in your favor?

[armel]

I've already thought about this, but it makes it impossible to link a channel to several lists. Sometimes, it's usefull. I don't know what users would think. About compander, no way, many user use it (not me).

[prokrypt]

A nice feature would be that multiple lists can be enabled for scanning, eliminating the need to put a channel in multiple lists.

I had wanted to do this on my fork, but I have 0 experience with graphical interface design so making the indicators would be very difficult for me 🫠

[armel]

@prokrypt In terms of UI (User Interface), it would be a nightmare to do... More seriously, we already have 3 combinable lists and a fourth with list 0, to store 200 memory channels. That's good enough.

[das-Iro]

You don't loose capabilities with the reorder.
scan group 0 = scan list []
scan group 1 = scan list [1]
scan group 2 = scan list [2]
scan group 3 = scan list [2,1]
scan group 4 = scan list [3]
scan group 5 = scan list [3,1]
scan group 6 = scan list [3,2]
scan group 7 = scan list [3,2,1]

so scan list 1 would be emulated by selecting scan group 1 3 5 7 (uneven bit)
so scan list 2 would be emulated by selecting scan group 2 3 6 7 (2 bit)
so scan list 3 would be emulated by selecting scan group 4 5 6 7 (high bit)
Obviously this is hard to use in the general case, but it shows that it does not reduce the capabilities.

Here is a special use case that would show what I understood from you, and how to use it with the scan groups the double use channel symbolized by "favorite relays".
You would not add the channel to multiple lists, you would have that channel grouped separately, as there are more groups than lists.
scan list 1: simplex + favorite relays
scan list 2: all relays
scan list 3: PMR, FreeNet
unlisted: rest
would become
scan group 0: rest
scan group 1: simplex
scan group 2: favorite relays
scan group 3: non favorite relays
scan group 4: PMR
scan group 5: FreeNet
scan group 6: extra
scan group 7: extra

emulation would look like this:
scan list 1 = scan group 1 + 2
scan list 2 = scan group 2 + 3
scan list 3 = scan group 4 + 5
scan list 1 + 2 = scan group 1 + 2 + 3

The added flexibility should be apparent.

Could be possible to software swap the meaning of the 3 bits, so the user can decide. In chirp both interpretations could be shown at the same time. However it would cost firmware bytes.

With compander, I think compander is all ways used RX+TX at the same time, currently it allows Off, RX, TX, RX+TX. Removing a bit would result in Off, RX+TX.

Edit:
A nice feature would be that multiple lists can be enabled for scanning, eliminating the need to put a channel in multiple lists.
Yes toggling the groups/lists would be my approach.

In terms of UI (User Interface), it would be a nightmare to do
I think it would be possible to display the scan groups on the top left, which has space for 3 numbers. They could rotate over time, which is not hard to implement. Each channel will only have 1 group assigned to it making it simpler for that display.

[armel]

My use case is this one,

List 0 : Miscellaneous
List 1 : HamRadio (simplex, relays)
List 2 : PMR, LPD, Freenet (public bands)
List 3 : Air, Sea (for RX only)

But I have several frequencies that I feel are important to watch out for. Some are in list 1, some in list 2, some in list 3. For example, distress frequencies (121.500 Mhz Aero, etc.). I therefore place these "special & strategic" frequencies in list 1, 2 and 3. That way, whatever list I scan (except 0), I won't miss anything.

To do the same with your approach, I'd have to create a special group dedicated to these important frequencies. And add this group to any scan list.

By the way, your approach would require a huge work:

• update current scanlist attribute to manage 8 groups from 0 to 7 instead,
• update current menus ScAdd1, ScAdd2, ScAdd3,
• update current menus SList1, SList2, SList3,
• add a menu (or something else) for managing scan lists by selecting 1 or more groups,
• probably many UI/UX upgrade,
• update current scan code (and exclude),
• and of course, update Chirp,

What impact will this have on memory? I don't know.

And all that just to go from 4 to 8 lists? Is it really worth it? I doubt it.

In short, I'm puzzled.

Last, but not least, I agree with you about Compander, 1 bit should be enough: OFF, ON (RX/TX). And I was just keeping this bit in reserve.