Toggle channel exclusion outside of scanning

[mrkusypl]

I came up with the idea of being able to exclude channels from scanning outside of scanning mode. There is exclusion removal, but the option to add exclusion outside of scanning would be a good idea.

However, in order to be able to implement, I needed to move the exclusion from the MENU button to EXIT, where there is no action under the long button (not counting exiting DTMF input).

Along with changing the exclusion button to EXIT, I had to change the function from the EXIT button so that holding the button down for a long time while scanning does not exit scan mode (something like the MENU button, which changes modulation when held down for a long time, but does not enter the menu).

This also managed to save 64 bytes! :)

Modified code: 6beed07

[prokrypt]

Personally I don't think being able to exclude a channel from the main screen has much use, but I had implemented something a bit similar in my fork:
monitor mode can be enabled while scan is running, then you can use up/down to go through the scanlist. long press M will add it to exclude list.
my target feature was letting monitor mode remain enabled in scan mode. the ability to exclude like that was only a happy accident.

[mrkusypl]

@prokrypt, I was thinking of being able to exclude channels from the main mode so that I don't receive them when scanning. You won't have to wait for the RX of these channels to exclude them, you can just do it manually from main mode.

[armel]

While the ability to exclude a channel during a scan seems important to me, excluding a channel outside of a scan seems very secondary. I am not sure if I will implement it.

[mrkusypl]

In my opinion, such a function can sometimes be useful. For example, I sometimes scan myself for channels that are in the 0 list. A couple of them are reapeters on which there are calls, and I don't want to include them in the scan. By adding the exclusion of channels from the scan like this, you can exclude them straight away without having to wait for RX.

And 64 bytes saved ;)

[prokrypt]

I have repeaters on their own list.

Also, I had been thinking about having 8 scanlists, with each channel able to only be in a single list. Then the user can toggle individual scanlists while scanning...

[armel]

@prokrypt Several approaches are possible. It's easy to have 8 scan lists, with each channel appearing in only one list. But I think that offering the possibility of mixing lists is also interesting. And today, counting list 0, we have 4. That's not bad. I've never used all the memory banks on my transceivers.

[mrkusypl]

@prokrypt I have repeaters in a separate list (list 0). Sometimes I need to exclude some of them because there are frequent calls. By excluding these channels, I can listen for channels with less frequent calls.

Sure, it would be possible to set a list for these channels to disappear from list 0. However, the exclusion is temporary, and by changing the channel's list, you would have to set the previous state after the scan.

[mrkusypl]

Exclusion using PMR channels as an example:

8mb.video-Pwy-3KtLAqkm.mp4

[mrkusypl]

I also created a commit in which I restored the old operation. I am referring to line 568 in app/main.c:

Before (exclusion outside scanning):

if (!gDTMF_InputMode) {

After (without excluding outside scanning):

if ((!gDTMF_InputMode)&&(gScanStateDir != SCAN_OFF)&&(FUNCTION_IsRx())) {

The version with channel exclusion removed except for scanning is 12 bytes smaller than @armel's feature_update_v3 branch. But...

There is a 44 byte difference between the changes above with the benefit of my proposal to exclude outside scanning! Adding (gScanStateDir != SCAN_OFF)&&(FUNCTION_IsRx()) to the code increases the code by these 44 bytes.

And modified code with "after": 9ed2541

[armel]

You're forgetting an important detail: user habits 🤗

I wouldn't change the exclude key from M to EXIT. If I do, I'm guaranteed to receive dozens of e-mails/issues/what else... indicating that the exclusion doesn't work.

Look at the effect of the first VOXLess v3.0, which required pressing the 7 key rather than the 5 key. A real hell to deal with. Never again 😂

The gain of a handful of bytes isn't worth it.

[mrkusypl]

@armel You are right. User habits are an important thing - I hadn't thought of that.

I have put back the exclusion as it was before - under a longer press of MENU. This code will allow some function to be inserted under a longer press of EXIT (as is done with the MENU button).

The code saves 8 bytes.

Modified code: 8816510

[mrkusypl]

I contribute nothing more to the discussion, so I am closing it.

If anything, all ideas are possible for future use.