OP25 Talkgroup Priority

[Snoops94]

Putting this question out there to see if anyone has had similar thoughts.

I have OP25 successfully running on a dedicated xUbuntu machine and have explored it thoroughly. But I was wondering if implementing talkgroup priorities would be possible. I imagine this would be implemented in trunking.py (correct me if I am wrong) and it could be a task I might attempt myself (although I still have quite a bit to learn about python structure).

Has anyone thought of implementing this? Is it a planned future feature?

 

[boatbod]

Putting this question out there to see if anyone has had similar thoughts.

I have OP25 successfully running on a dedicated xUbuntu machine and have explored it thoroughly. But I was wondering if implementing talkgroup priorities would be possible. I imagine this would be implemented in trunking.py (correct me if I am wrong) and it could be a task I might attempt myself (although I still have quite a bit to learn about python structure).

Has anyone thought of implementing this? Is it a planned future feature?

How would you envisage trunkgroup priority working?

At present, when a voice_grant or voice_grant_update arrives, the trunking logic checks the tgid against the whitelist and blacklist files and if it passes, it changes frequency to the specified voice channel for the duration of the voice call.

For priority to work, you'd need to constantly decode the control channel to see when new grants were issued so that you could preempt any existing voice decode and switch to the new channel. This would require two independent p25_demodulator/p25_decoder chains and two separate RTL devices.

 

[slicerwizard]

For priority to work, you'd need to constantly decode the control channel to see when new grants were issued so that you could preempt any existing voice decode and switch to the new channel. This would require two independent p25_demodulator/p25_decoder chains and two separate RTL devices.

No, just decode and act on the group voice channel update messages (link control opcodes 2 and 4)

 

[boatbod]

No, just decode and act on the group voice channel update messages (link control opcodes 2 and 4)

Sure, assuming they are actually being sent on the voice channels. You can find that out right now by running at debug level 10 and watching the messaging that takes place while a call is in progress.

For phase 1 you'd see the prefix "LCW: pb=%d, sf=%d, lco=%d", where the %d's are replaced by the appropriate numeric value. In the case of lco=2 you'd also get the channel and grpaddr (tgid) in the log.

For phase 2 the info arrives in the MAC_ACTIVE messages. Slightly different format but same concept.

Now at present none of this info makes it up to trunking.py, but it's not hard to get it there. You just have to define a message type and then pack the info using json format.

 

[Snoops94]

Thanks for the replies. I clearly have a lot to learn about the inner workings of OP25 and how the trunking works as a whole. A two device setup would be something though, similar setup to what I was running with Unitrunker until the phase 2 switch. I image (with my limited understanding) that a second device could allow for sites with a wider frequency spread to be monitored.

 

[boatbod]

Thanks for the replies. I clearly have a lot to learn about the inner workings of OP25 and how the trunking works as a whole. A two device setup would be something though, similar setup to what I was running with Unitrunker until the phase 2 switch. I image (with my limited understanding) that a second device could allow for sites with a wider frequency spread to be monitored.

The frequency spread doesn't matter to OP25 because it will retune the dongle if the desired frequency is outside the existing sample range.

I will take a look to see if anything can be done with voice grants/updates *if* they are received on the voice channels. The P25 spec does allow for this, but it's probably a system configuration parameter whether they are actually sent or not.

 

[boatbod]

I've looked at this a little more and have added some additional decode to both phase 1 and phase 2 for the related voice channel messaging that will convey a group voice grant / group voice grant update message.

Three additional things need to happen before this can be used to implement trunkgroup priority: the low level P25 messages need to be put in a form that can be set to the trunking module, the tgid file needs to be extended to include an optional priority field and the trunking.py module needs to be modified to handle the new data schema and messaging.

 

[boatbod]

I've made some changes and added an optional numeric tgid priority parameter as the 3rd field of the TGID-tags.tsv file. (It's tab-separated formatting, so just hit tab and enter an integer after the existing tag string.) LOWER numbers have HIGHER priority. Default is 3 for anything with no tag specified.

Notes:
- A priority tgid will override a tgid "hold". I'm not sure this is necessarily ideal, but it's needed to overcome the 2 second automatic hold added to every call.
- If priority preemption takes place, you should see the message "voice preempt" in the log if you have logging level set to 1 or more.
- At present only "Implicit" voice grants/grant updates are supported. I'm planning on adding Explicit too, but this will be a little more work and not something I can personally test since my local P25 system does not ever generate that format.

 

[Snoops94]

Awesome! Thanks for looking into this, I listen to the TxWARN system in and around Harris County, Texas. In my mind it's a pretty big system and having the ability to prioritize talkgroups really helps.

I tend to most of my listening mobile so two things I have done to assist this are:
-Append talkgroup id to a file when lockout is requested (Recently saw the stats script so I am looking into incorporating the command into the logfile and adding another step in the script)
-A file for each site I monitor and a link to run OP25 for each site (I do this as sites are dense and far reaching here)

I was thinking for that last one could a key command be implemented that steps through the systems in the tsv. Also, displaying the system name in the terminal window would be nice (looking into that now)

 

[Snoops94]

Log lockouts

if command == 'lockout':
sys.stderr.write("%f Locked out: %d %s\n" % (time.time(), self.current_tgid, tsys.get_tag(self.current_tgid)))

Stats shell
# talkgroups lockout
echo "Generating list of locked out talkgroups: op25-locked-tgids.txt"
echo "# Locked out Talkgroups" > op25-locked-tgids.txt
grep 'Locked out:' $1 | cut -d" " -f4,5 >> op25-locked-tgids.txt

 

[jcook11]

I know the OP specifically asked about OP25, but just mentioning that SDRTrunk handles priority quite well. You can have multiple dongles, or a wider bandwidth device like an Airspy and it will decode the control channel all the time while processing voice calls in parallel.

 

[boatbod]

I know the OP specifically asked about OP25, but just mentioning that SDRTrunk handles priority quite well. You can have multiple dongles, or a wider bandwidth device like an Airspy and it will decode the control channel all the time while processing voice calls in parallel.

P25 phase 2?

 

[jcook11]

P25 phase 2?

No, it doesn't support phase 2 yet from what I can tell.