Unitrunker Priority Idea

[jlanfn]

...An explanation of how priority settings currently work:

...
The listening priority is a threshold that filters out calls whose priority is numerically greater. There are some exceptions to the threshold. The logic is outlined below.

There are eight things used to qualify a voice call for for listening.

Source's hold state (call assumes highest priority to preempt all other calls)
Source's Listen state (if checked, the call assumes the source's priority; in this case, the target is ignored)
Source's Lockout state (if checked - and we've gotten this far, the source is ignored)
Source's Priority (if numerically less than the current priority, the call assume's the source's priority)

Target's hold state (call assumes highest priority to preempt all other calls)
Target's Listen state (if checked, the call assumes the target's priority)
Target's Lockout state (if checked - and we've gotten this far, the source is ignored)
Target's Priority (if numerically less than the current or source's priority, the call assume's the target's priority)

Notice that the call's source (the speaker) is evaluated before the call's target (the audience). This means the target gets "last crack" at influencing the call's overall priority.
...

It would be more effective for my monitoring environment if target and source priorities were given equal weight in determining overall priority. This could be accomplished by simply summing the target and source priority values to obtain a total priority value.

I hope to soon post an example showing the advantages of this idea when applied to what is a common situation for me, only the complexity is making it too difficult to explain clearly.

 

[jlanfn]

For example...

An example of how the summing priority method would be effective...

First a couple of notes:

1. I never turn on hold, listen, or lockout states, so only source and target priorities matter.
2. The closer the total priority value is to zero, the higher the priority.
3. Neglect individual calls so the source is always the transmitting radio, and the target is always the talkgroup.
4. Source priority values range from 0 to 100 with all new (unmodified) sources having program default priority 50.
5. Target priority values range from 0 to 100 with all new (unmodified) targets having program default priority 50.
6. All transmissions numerically higher than the listen priority will not be heard. The highest total priority transmission out of all transmissions less than or equal to the listen priority will be heard.
7. Listen priority, accounting for the sum of source and target priorities, ranges from 0 to 200, with program default value 100.

Now, I set target PD Disp to priority 10, target PD Tac to priority 15, and listen priority to 99. In this configuration I will hear only transmissions on PD Disp and PD Tac (source + target < 100) and PD Disp transmissions (source + target = 50 + 10 = 60) will always preempt PD Tac transmissions (source + target = 50 + 15 = 65).

However, what if I want new or unidentified sources on either target to preempt the other target? With the configuration above the problem would be with new/unidentified sources on PD Tac. I can solve this problem by setting all identified sources to priority 65. Now new/unidentified sources on PD Disp (source + target = 50 + 10 = 60) preempt new/unidentified sources on PD Tac (source + target = 50 + 15 = 65) preempt identified sources on PD Disp (source + target = 65 + 10 = 75) preempt identified sources on PD Tac (source + target = 65 + 15 = 80).

Confused? :twisted:

 

[SCPD]

I read your post and was hoping to hear others' comments. How would this work for direct I-calls? Would you treat them as they are handled now?

 

[jlanfn]

Yeah, I'll admit that I-calls pose a problem. They certainly wouldn't work well in my example (source + target = 65 + 65 = 130, meaning you would not hear I-calls between identified radios). The only way I see around it would be to allow two different priority settings for radio ID's, one priority level for the radio as the source and one priority level for the radio as the target...could get complicated.

 

[jlanfn]

Just to summarize, assuming hold, listen, and lockout are retained, the overall priority order could be:

1. Source's hold state
2. Target's hold state
3. Source's listen state
4. Target's listen state
5. Source's lockout state
6. Target's lockout state
7. Source and target combined priority (using radio ID's target priority for I-calls)

Any comments?

 

[SCPD]

How would you handle priority for patched group and multiselect calls?

Groups A and B are patched. A is the super group (so patched calls to A can be heard by both group A and group B radios). Assuming A and B have different listening priorities, which priority should apply? Would you average them? Sum them? Pick highest or lowest?

 

[jlanfn]

How would you handle priority for patched group and multiselect calls?

Groups A and B are patched. A is the super group (so patched calls to A can be heard by both group A and group B radios). Assuming A and B have different listening priorities, which priority should apply? Would you average them? Sum them? Pick highest or lowest?

Out of curiosity, how do you handle patches in the current software version (assuming no hold, listen, or lockout settings activated and all source priorities equal)? Do you just always use the supergroup's priority?

For multiselects, it seems clear to me that you would pick the highest priority (lowest numerical value) of the supergroup and subgroup(s) and use that for the patch target priority. Say group A is the super of group B, and B has higher priority than A. From a priority perspective, how would a multiselect A + B be all that different from the multiselecting radio just transmitting on group B without any patching? (assuming my understanding of multiselect is correct)

For normally patched groups it is slightly different. Assuming a certain level of responsibility on the scanner listener's part to keep abreast of what channels are patched, I see no problem in, again, picking the highest priority out of the supergroup and subgroup(s) and using that as the patch target priority.

In any case, summing the supergroup and subgroup priorities would not work with the source + target = total priority formula, because the target priority would end up being a really high value. And averaging the supergroup and subgroup priorities just seems far too confusing to be useful.

If it doesn't complicate things too much, maybe users could be given a choice whether they want highest or lowest supergroup/subgroup priority to govern, or to just always use the supergroup priority as the patch target priority.

 

[SCPD]

picking the highest priority out of the supergroup and subgroup(s) and using that as the patch target priority.

That's how it is supposed to work now but there are some bugs in this area.

One alternative to you sum-of-priorities schema would be to assign a priority displacement to the radio id. Normally it would be zero - but could be positive or negative - adjusting the overall call's priority accordingly.

Trying to explain this (or the sum of priorities) mechanism to users could be a challenge.

 

[kevins669]

Trying to explain this (or the sum of priorities) mechanism to users could be a challenge.

Could be done in the wiki.... with a very detailed description. jlanfn could probably do a good job authoring that section.

Good ideas, though.

-- Kevin

 

[jlanfn]

Another benefit I see to the summing method is that users can continue to use the program the way they use it now, if they prefer. In the current version, modifying source priorities to a higher or lower value than 50 will cause source priority to primarily govern call priority, per the priority logic cited above. If, however, they leave source priorities alone and only modify target priorities, then target priorities will govern call priority.

You can do both of these with the summing method, either by leaving all target priorities the same at 50 or leaving all source priorities at 50.

I can imagine this topic would generate significant confusion for those who are used to the current priority method, although I like to think that mastery of addition is something that all Unitrunker users possess. It would be nice to be able to say, "Here's how to use the priority settings just like you're used to," and, "For those who are willing to handle the extra complexity in exchange for greater control over priority, here's how to work with the extended priority logic."

The biggest change that users who are used to the current logic would be faced with is now the listen priority is a 0 - 200 scale rather than 0 - 100.