SDS100 Favorites List - Some TG or departments not always being scanned.

[jonwienke]

You should never have a talkgroup entered multiple times in a system. It's a logical error that shouldn't be allowed in Sentinel or the scanner firmware. @JoeBearcat, please consider that a feature request for Sentinel and all future firmware updates.

 

[JoeBearcat]

You should never have a talkgroup entered multiple times in a system. It's a logical error that shouldn't be allowed in Sentinel or the scanner firmware. @JoeBearcat, please consider that a feature request for Sentinel and all future firmware updates.

It was discussed previously. Not for that exact issue, but more along the lines of "how should the scanner act if the same TG is entered more than once". The result of that discussion was "enabled in any list should allow monitor" (the other choice was avoided in any list should lock out). I argued that any time I have a TG enabled I should be able to hear it.

What the OP is describing sounds like it could be a bug if it is operating the way that was rejected.

I have Departments programmed similar - sometimes I want to listen only to some fire ops channels and sometimes all without individually enabling them all. I disagree this is a logical error just as entering a conventional frequency more than once is not a logical error.

 

[jonwienke]

I disagree this is a logical error just as entering a conventional frequency more than once is not a logical error.

In the context of a trunked system, having multiple conflicting definitions for talkgroup ID xxx is indeed a logical error. Or multiple definitions, conflicting or not. Allowing duplicate definitions leads to all sorts of unpredictable results, particularly if they are are in different departments, are tagged with different service types, have different text labels, etc. Best practice is to not allow duplicates, and then there is clarity when you want to enable or disable--no confusion as to which avoid or service type takes precedence, or which of multiple conflicting text labels should be displayed, etc.

 

[JoeBearcat]

In the context of a trunked system, having multiple conflicting definitions for talkgroup ID xxx is indeed a logical error. Or multiple definitions, conflicting or not. Allowing duplicate definitions leads to all sorts of unpredictable results, particularly if they are are in different departments, are tagged with different service types, have different text labels, etc. Best practice is to not allow duplicates, and then there is clarity when you want to enable or disable--no confusion as to which avoid or service type takes precedence, or which of multiple conflicting text labels should be displayed, etc.

Let's say that is done. How do you deal with the following:

Jim wants to program his local fire districts and police channels (19 of the former and 10 of the latter) in a single Department, but wants a way to only QUICKLY monitor one fire district for major incidents along with continuing to monitor all police channels.

How does Jim program his scanner?

Currently he could:
Program all fire in QK 1
Program all PD is QK 2
Program each fire district as a separate QK (say 21-39).

Normal scanning is QK 1 and 2.

Major events is QK 2 and the one assigned to that district. (say 21 ENTER 1 ENTER)

How is that possible without TG duplication?
(and 22 ENTER 23 ENTER 24 ENTER 25 ENTER 26 ENTER 27 ENTER 28 ENTER 29 ENTER 30 ENTER 31 ENTER 32 ENTER 33 ENTER 34 ENTER 35 ENTER 36 ENTER 37 ENTER 38 ENTER 39 ENTER is not an option)

If you understand that a TG enabled in ANY Dept will scan, there is no logical error - the scanner only scans what is enabled to scan and (and this is the key) will always scan what is enabled to scan.

 

[jonwienke]

There is no scenario where duplicating talkgroups is the best solution. Playing traffic if any instance of a talkgroup is enabled causes at least as many problems as is solves, because if you want to avoid a talkgroup, now you have to avoid EVERY instance of the talkgroup. And allowing the possibility of conflicting text labels, service type definitions, location coordinates, and so on for a talkgroup ID is still a logical error, and creates all sorts of opportunities for needless confusion on the part of the user.

• "Why do I have to Avoid Podunk Sanitation 3 times before it quits spamming me?" (It was accidentally entered 3 times)
• "Why do I hear the same traffic on Podunk City Fire and Pudunk County Fire?" (The description was changed in the RR database, and the creation of a duplicate TG entry was triggered as a result)
• "Why am I still hearing Podunk County Fire after turning off all of the fire service types?" (same as previous, except service type was changed instead of description)

And of course, duplicating talkgroup entries means additional memory and storage is required, as well as additional processing before a play/skip decision can be made for calls on a duplicated talkgroup ID.

In your example, the best solution is to allow the entry of a range of QKs as follows:

Incident start:
1.2.22-39 Yes (turns OFF all department quick keys from 1.2.22 to 1.2.39)
1.2.27 Yes (toggles on department quick key 1.2.27)

Incident end:
1.2.22+39 Yes (turns ON all department quick keys from 1.2.22 to 1.2.39)

+ and - are entered by Function, No and Function, Yes respectively.

That would require a firmware update, but it would probably be a smaller one than changing talkgroup ID lookup behavior so that it looks at all instances of a TGID and performs a logical OR on the result of the play/skip matrix for each instance before making a final decision on whether to play or skip the call. Current behavior is the play/skip decision matrix (is the department avoided, service type enabled, etc) is only run on the first instance found, leading to the current confusing and random results when duplicate talkgroup definitions are programmed.

Enabling the entry of a range of quick keys at the favorite list, system, and department levels, and allowing the desired quick key state to be explicitly stated (so the user is not limited to "toggle the current state) would have many other benefits. In the real world, the scenario you described above might not fall under a single trunked system. Each district might be in separate systems, perhaps even in different favorite lists organized by city, county, township, etc. Allowing duplicate talkgroup IDs in a trunked system would be useless in that case. But allowing the user to toggle a range of quick keys on and off at any desired level (favorite list, system, or department) would solve the conundrum you posited, even if the "districts" were split across separate systems, or even across multiple favorite lists. You could do things like:

1- Yes (turn on all system and department quick keys in the favorite list with quick key 1)
1.2+ Yes (turn on FL key 1, system quick key 1.2, and ALL department quick keys starting with 1.2)

That turns off everything in FL 1, except for system 1.2 and all of the departments under it.

1+ Yes would turn on FL key 1, and all system and department keys within FL 1.

1-7 Yes (turn off FL quick keys 1 through 7)
5 Yes (turn on FL quick key 5)

That turns off FLs 1 through 7, except for 5.

1+7 Yes turns on FL quick keys 1 through 7.

And so on. IMO that is a far better, more flexible, and more powerful approach than allowing duplicate talkgroup ID entries because it allows the same sort of functionality across multiple systems and favorite lists (not just departments within a single system), but without any of the ambiguity and confusion that will inevitably arise if you allow multiple conflicting definitions for a talkgroup ID.

 

[kirk5056]

I program the same TG in several "dept" groupings. All are "avoided" but one. One example is when fire and EMS are dispatched on the same TG. I want to have the ability to listen in both my "fire" "dept" group and in my "EMS" "dept" group to that TG and I put a different number tag on each. In my organization FL.Sys.0 is always EMS dispatch and FL.Sys.301 is always fire dispatch. So that no matter where I am I can have direct access to a channel type if I know the FL(state) and Sys (county) number tag (which is included in each alpha tag).

 

[JoeBearcat]

There is no scenario where duplicating talkgroups is the best solution. Playing traffic if any instance of a talkgroup is enabled causes at least as many problems as is solves, because if you want to avoid a talkgroup, now you have to avoid EVERY instance of the talkgroup. And allowing the possibility of conflicting text labels, service type definitions, location coordinates, and so on for a talkgroup ID is still a logical error, and creates all sorts of opportunities for needless confusion on the part of the user.

• "Why do I have to Avoid Podunk Sanitation 3 times before it quits spamming me?" (It was accidentally entered 3 times)
• "Why do I hear the same traffic on Podunk City Fire and Pudunk County Fire?" (The description was changed in the RR database, and the creation of a duplicate TG entry was triggered as a result)
• "Why am I still hearing Podunk County Fire after turning off all of the fire service types?" (same as previous, except service type was changed instead of description)

If you program a channel multiple times, it is not unexpected to have to avoid it multiple times.

There is no practical way to update FLs. For ever case you can come up with, the opposite argument can be made. For example, do you update that tag or did the user clarify that tag and doesn't want it updated?

There is no fix for erred programming.

And of course, duplicating talkgroup entries means additional memory and storage is required, as well as additional processing before a play/skip decision can be made for calls on a duplicated talkgroup ID.

The memory used by a TG is trivial. Look at how much memory the entire USA database uses.

In your example, the best solution is to allow the entry of a range of QKs as follows:

Incident start:
1.2.22-39 Yes (turns OFF all department quick keys from 1.2.22 to 1.2.39)
1.2.27 Yes (toggles on department quick key 1.2.27)

Incident end:
1.2.22+39 Yes (turns ON all department quick keys from 1.2.22 to 1.2.39)

+ and - are entered by Function, No and Function, Yes respectively.

While I like the concept, and will add that to the feature request list, it does not adequately address the issue.

In the end, I don't foresee a change to the exact opposite operation that currently exists. That would be too confusing for users.

Case 2: A user has two Departments - one for county north and one for county south. But they use the same dispatch channel. Your method would prevent him from being able to program in the dispatch channel for one of the zones. Then we would have to field "Why can't I hear dispatch on North zone"? Again, for each case of benefit, there is a case of disadvantage.

That would require a firmware update, but it would probably be a smaller one than changing talkgroup ID lookup behavior so that it looks at all instances of a TGID and performs a logical OR on the result of the play/skip matrix for each instance before making a final decision on whether to play or skip the call. Current behavior is the play/skip decision matrix (is the department avoided, service type enabled, etc) is only run on the first instance found, leading to the current confusing and random results when duplicate talkgroup definitions are programmed.

The easiest/smaller firmware change is no change. The logic is simple: Is the TG in a Department that is enabled? If so, let the user hear it. Otherwise, move on to the next active one and evaluate.

Your case of multiple tags and multiple channels can exist exactly the same for conventional channels. More than one instance of a frequency must be allowed, so it makes sense allowing for multiple instances of the same TG is not a big deal by comparison. The logic is the same for both.

Enabling the entry of a range of quick keys at the favorite list, system, and department levels, and allowing the desired quick key state to be explicitly stated (so the user is not limited to "toggle the current state) would have many other benefits.

As I said above, I like the range idea.

In the real world, the scenario you described above might not fall under a single trunked system.

When you start discussing duplicate TGs across separate systems, that is a short discussion. Why would you ever mandate a change of one system to affect another unless they are all in the same FL? (in which case enabling/disabling the FL disables both systems in their entirety (unless programmed/duplicated in a different FL).

Each district might be in separate systems, perhaps even in different favorite lists organized by city, county, township, etc. Allowing duplicate talkgroup IDs in a trunked system would be useless in that case.

It would not be uselsess if those systems use duplicate TGs for different users. Again, no change to one System should ever affect another.

But allowing the user to toggle a range of quick keys on and off at any desired level (favorite list, system, or department) would solve the conundrum you posited, even if the "districts" were split across separate systems, or even across multiple favorite lists. You could do things like:

Again, I do like the range idea. But it is not an alternative to duplicated channels (TGs) - especially when it would eliminate a feature many users may currently be using.

 

[ofd8001]

I have a similar scenario that I have a workaround for.

The "important" channels are programmed into a Department and the "ho hum" channels are programmed into a separate Department. If I want to limit scanning to the important channels, the other Departments are Avoided or turned off via Department Quick Key.

For example:

Police 1 is Department 2 with Quick Key of 2
Police 2-4 is Department 21 with Quick Key of 21

(Police 1 is not duplicated with the other police talkgroups).

Another option is to mark those talkgroups that are important as Priority Channels, with Priority ID Scan enabled. Then to listen to just important channels, do a channel hold to where only the priority talkgroups would be "available".

Long time ago, Upman was mentioning duplicating talkgroups can give the scanner a headache is one is avoided but the other is not. I think he might have had the Direct Channel Entry process in mind. If you went to talkgroup ID 1 via this method and do something like Avoid, which one of the talkgroup 1s will you be Avoiding - the one in Department A or the one in Department B?

 

[JoeBearcat]

I have a similar scenario that I have a workaround for.

The "important" channels are programmed into a Department and the "ho hum" channels are programmed into a separate Department. If I want to limit scanning to the important channels, the other Departments are Avoided or turned off via Department Quick Key.

For example:

Police 1 is Department 2 with Quick Key of 2
Police 2-4 is Department 21 with Quick Key of 21

(Police 1 is not duplicated with the other police talkgroups).

Another option is to mark those talkgroups that are important as Priority Channels, with Priority ID Scan enabled. Then to listen to just important channels, do a channel hold to where only the priority talkgroups would be "available".

Long time ago, Upman was mentioning duplicating talkgroups can give the scanner a headache is one is avoided but the other is not. I think he might have had the Direct Channel Entry process in mind. If you went to talkgroup ID 1 via this method and do something like Avoid, which one of the talkgroup 1s will you be Avoiding - the one in Department A or the one in Department B?

You will be avoiding the one that was active when you hit AVOID. You are avoiding that CHANNEL, not that TG. For Direct Channel Access (number tags) you would go to the first, then the next matching tag, etc. If you use the TG entry method, I think it will hold on the first instance of that TG in the list. So yes if you tag the same TG differently you might get either of those tags. You should know what it is since you tagged it.

 

[ofd8001]

You will be avoiding the one that was active when you hit AVOID. You are avoiding that CHANNEL, not that TG. For Direct Channel Access (number tags) you would go to the first, then the next matching tag, etc. If you use the TG entry method, I think it will hold on the first instance of that TG in the list. So yes if you tag the same TG differently you might get either of those tags. You should know what it is since you tagged it.

I may not have explained this too well. I thought Direct Entry (page 57 of 436 manual), was different than Number Tagging.

For example, talkgroup ID is 1501. I can program it in two departments and use differet number tags. First number tag is 1.1.21 and the second entry's number tag is 1.1.99.

I can go to this talkgroup by pressing Channel, 1501 and be on this talkgroup, but I don't know if its the one having the number tag of 1.1.21 or number tag 1.1.99.

Again I'm not saying duplicate entries is good, rather saying how duplicates can be confusing to the scanner and user.

 

[JoeBearcat]

I may not have explained this too well. I thought Direct Entry (page 57 of 436 manual), was different than Number Tagging.

For example, talkgroup ID is 1501. I can program it in two departments and use differet number tags. First number tag is 1.1.21 and the second entry's number tag is 1.1.99.

I can go to this talkgroup by pressing Channel, 1501 and be on this talkgroup, but I don't know if its the one having the number tag of 1.1.21 or number tag 1.1.99.

Again I'm not saying duplicate entries is good, rather saying how duplicates can be confusing to the scanner and user.

It should go to the first instance of TG "1501".

 

[u2brent]

Duplicates should be permitted as they are now, for numerous reasons. However, something I believe everyone should agree with is the added ability in Sentinel to locate a duplicate TGID (frequencies too) within a system (or FL) by some search option. In instances where the user may be unaware of the duplicate and take action if desired/warranted..

 

[JoeBearcat]

There are lots of areas where Sentinel could be improved. I would love it to have all the capability of ProScan. But, I believe that is asking too much. I will see if some search functionality can be added.

 

[jonwienke]

If duplicate talkgroup entries are allowed in a trunked system, then all of the following changes need to happen:

• Radio firmware needs to be checked and updated to insure that all entries for talkgroup xxx are checked before deciding whether to play/skip traffic. That is not consistently the case; a more common outcome is that only the the first entry found is checked, leading to odd and inconsistent behavior when the duplicate talkgroup entries have conflicting Avoid status, Service Type tags, and so on. Note that inconsistent handling of duplicate talkgroup entries is why this thread was created in the first place...
• There needs to be a function in Sentinel (minimum) and scanner firmware (preferable) to identify duplicate talkgroup entries within a system, and notify the user when a duplicate talkgroup entry is being created. In most cases, duplicates are not desired, and creating them should never be accidental or unintended.
• When avoiding a talkgroup with duplicate entries, avoiding all duplicates of the talkgroup should be one of the options, e.g. cycle through Temp Avoid / Temp Avoid Dups / Perm Avoid on-screen if Avoid is pressed repeatedly. Permanent Avoids should always Avoid all entries for the talkgroup. When reviewing existing Avoids, offer Clear Avoid and Clear Avoid Dups as options for duplicated talkgroup entries.
• For consistency, do all of the above for duplicate frequency entries within a conventional system. Also, if a conventional frequency is duplicated in a system, don't scan it multiple times. Scan it only once, then display the closest matching channel entry based on DCS/CTCSS if multiple tones are programmed.

 

[jonwienke]

It should go to the first instance of TG "1501".

"First" defined how?

First entry found when doing a sequential search from the beginning if the system?

First active (system department, and channel not avoided, not disabled by location control, all applicable quick keys on) entry?

Wouldn't next be preferable, so that if you jump to the wrong duplicate, you can go again to get to the right one?

 

[MStep]

Duplicates should be permitted as they are now, for numerous reasons. However, something I believe everyone should agree with is the added ability in Sentinel to locate a duplicate TGID (frequencies too) within a system (or FL) by some search option. In instances where the user may be unaware of the duplicate and take action if desired/warranted..

I like the idea of Sentinel being the "place" where issues of duplicates are addressed, rather then having the radio "wondering/worrying" what the user's intention were in setting duplicate conventional channels, TGID's, etc.

Skip the rest of this post if you aren't interested in my philosophical take on the situation.

The human mind (the user) conceives the "program", Sentinel forms and sets the data received from the users input, and a possibly upgraded Sentinel (as per "u2brent's suggestion") to allow the upgraded Sentinel to "recommend" or "suggest" areas where potential conflicts may exist for user intervention, and then sends the "load" over to the radio itself, which just performs/executes the user's intentions as understood by Sentinel.

There is a final "line of defense" for last minute quick-fixes built into the radio via the "Avoid" key, where necessary. The user, who has to be sharp enough to have programmed Sentinel to his/her desires, may come across a Sentinel human-induced programming error which can be temporarily "fixed" during a scan session using Avoid. The user also has to be sharp enough to document for his/her self the programming error which caused the radio to be "confused", and repair the error during the next Sentinel session. As a backup plan, the user should also send all corrections made during a scan session on the radio to a new Sentinel file in order to preserve the changes, compare the old file to the new file, and then allow the user to determine which programming scenario is correct, and allow for reconciliation. Of course, if the radio fails several times to perform the expected desired result, then we may have a "bug" in either Sentinel or the radio.

While this may sound a little more philosophical, isn't that an admittedly over-simplified explanation of how the world works? The human mind conceives the plan, a program is set forth to execute the plan, and the messenger (the radio) delivers the plan.

Another quick note before I take my fifth tranquilizer of the night (jk folks); we are, for the most part. a hobbyist community. Life and death situations are not determined by our radios stopping numerous times on a frequency or talkgroup; or missing a priority here and there--- it's a nuisance and not a threat. And so I can understand why some requested implementations have not been made over the course of weeks, months, even years. If we were professional life savers and not hobbyists, and issues came up with duplicates or priorities not being correctly implemented, it would be not a hobbyist company who would have to deal with the issues, but a professional Motorola (or equivalent) type company, who would have the resources to fix the problems much faster.

All the usual caveats-- FWIW, YMMV, et cetera, ad-nauseum. Have a great morning/afternoon/evening, wherever and whoever you are. -Mike

 

[MStep]

There are lots of areas where Sentinel could be improved. I would love it to have all the capability of ProScan. But, I believe that is asking too much. I will see if some search functionality can be added.

Yes, that would be great Joe. Sentinel could certainly be more powerful in many respects, as I and others in this thread have suggested.

But some might ask, "Why reinvent the wheel?" I've used Proscan in the past, albeit many years ago. I have not found the need to use it currently under my own monitoring conditions with my own SDS200. But if it solves many, if not all, of the suggestions/complaints/enhancement issues that most of the users seek, perhaps a deal can be struck with the folks at ProScan to offer to make it available to SDS users at a reduced price with some "affiliate" program to Uniden.

That might already have been attempted-- I'm not privy to ProScan's or Uniden's dealings, but it would seem a much quick and easier "fix" to allow Uniden to concentrate on the more important stuff like hardware and firmware issues.

Just a thought.

 

[IAmSixNine]

Original poster here. Wow i didnt think it would create this much discussion.
Follow up - I deleted the list that was causing issues. I created a new one and instead of making lots of changes i am doing them in segments and testing it. Im trying to see if i can replicate the issues i had previously.

New list is PAWM 2 and all i have done is move departments around (moving the city services to the bottom of the list and avoided them).
Things work.
Next i re-arranged some channels in the departments I scan.
Things still work.
Next I have set volume to +2 on all the talk groups as this system is a bit more low volume compared to a few other P25 systems i monitor.
Currently testing. Waiting for Allen fire to have activity on their TGs.
If all is good.
Next is to create new Dept. called All Fire Dept. and test.

Just as @JoeBearcat mentioned we all scan stuff differently.
I focus on fire dept stuff and them sometimes police.
So for me to have an ALL Fire Dept, department made sense. This way when im out and about i can hold on that department and get all the agencies fire dept on this system.
However if an agency, Plano for example kicks out units for a fire. I will then hold on the Plano Fire Dept, department.
For this reason i will have duplicate TG entries in my scanner.

Unfortunately i am happy scanning with out location data or favorites lists.

 

[JoeBearcat]

"First" defined how?

First entry found when doing a sequential search from the beginning if the system?

First active (system department, and channel not avoided, not disabled by location control, all applicable quick keys on) entry?

Wouldn't next be preferable, so that if you jump to the wrong duplicate, you can go again to get to the right one?

First two questions are good. You can try that to see.

It will not be first ACTIVE since you can go directly to a TG that is avoided.

If you go to the first one then enter it again, it WILL (or should) go to the next one if another exists.

 

[JoeBearcat]

...perhaps a deal can be struck with the folks at ProScan to offer to make it available to SDS users at a reduced price with some "affiliate" program to Uniden.

Just a thought.

Not a bad idea. Of course then you would have other authors complaining.

And I don't know the full history of Sentinel development. I believe I know who originally wrote it, and it was not Bob.

Quick aside from this topic: Before scanners had priority I used a pseudo-priority scheme where I programmed the same conventional channel multiple times so it was scanned more often than other channels. If that was channel X, I would program X-2-3-4-X-6-7-8-X-10-11-12. That is an example where duplicate conventional channels served a purpose. At the time there was no CTCSS/CDCSS either. This scheme will not work with trunked system BTW.