Harris P25 Patching Behavior

[Seagravebuff60]

I have a local Harris P25 system that I monitor, they are in the process of migrating from EDACS to P25. Now the system is still in the very early stages of migrating. The EDACS system has a big habit of having all kinds of TG patches done daily. And both UniTrunker and Trunking Recorder handle them greatly.

But moving onto P25 and SDRTrunk, since it is a Phase 2 System and UT Cant decode the audio...On the active call window in SDR Trunk and Trunking recorder will only show me the patch TG ID, which is in the 651xx range, and won't show me the Supper and Subgroups that are being patched with the 651xx talk group.

Further, Harris P25 systems that use Symphony consoles, which this system is using, use a feature called Simulselect when a dispatcher "patches" two talk groups together, which creates a third dynamic talk group in the 65xxx range. (Similar to how EDAC creates a 14-xxx or 15-xxx TG). The 65xxx range talk groups are members of a pool, meaning that they are not permanently assigned to any particular agency or talk group pair; they are created and torn down depending on demand.

This is a known Harris P25 obstacle. The Super and Subordinate talkgroups are not being displayed because Harris doesn't send out a Voice Patch Group Grant over the control channel as Motorola does. Motorola announces explicit patch calls. This is true both for 3600 baud Motorola trunking as well as Motorola's P25 offering. This means Motorola has the ability to issue a non-patched group call while a patch exists for that group ID, but Harris doesn't. Instead, it just sends out a plain old Group Voice Grant message for the Supergroup, leaving out any mention of it being a patch call. So as expected, so then SDR Trunk displays it as a normal group call without showing the subgroups in the display. EDACS (4800, 9600, and SitePro) uses implicit patch calls - meaning the presence of one or more patches imply the call is a patched group call. Before announcing a non-patched call on these systems the patch must be dropped. Otherwise, all subscribers will assume it is a patched call.

When monitoring a Hariss P25 Systems the expected behavior is to show the Patched TG as well as the Supper and Subgroups that are being patched, Like this. (I can't reproduce a screenshot from SDRTrunk only TR)

Instead, only the 65xxx range talk groups show up, like this.

So this means that there is no way to tell where the patch call is actually coming from unless you are monitoring the system with something else to show it patches like Unitrunker. I, unfortunately, cannot capture an active screenshot in SDRTrunk as the patches are not active currently not active but when I can ill reply to this thread

Conclusion: Since this is a Harris P25 issue is it possible that SDRTrunk can handle Harris P25 Systems more like Motorola and/or EDACS?

[TRENT310]

Looking on the SDRTrunk Messages window where the raw opcodes should be displayed, we are not seeing any of the proprietary MFID A4 "M/A-COM_P/SS_ANN" being processed as compared to other software which is capable of handling these proprietary messages. As an extension or as an optional "high verbosity" level it should be possible to enable raw display of opcodes which are not currently supported or handled by SDRTrunk for the purposes of identifying any proprietary options in use.

These patch announcements are repeated continuously on all sites control channels (including sites where none of the talkgroups have active affiliations) for the benefit of late-entering Subscriber Units and while in Console Patch, the Subscriber Unit firmware is to follow the System Assigned ID both for following granted voice calls as well as for its inbound group voice channel grant requests (PTT). This is effectively a form of dynamic regrouping without any visual indication to the user SU. While in Console Simulselect, the SU firmware is directed to additionally unmute to traffic on the supergroup SAID but request its own group voice channel grants on the user selected talkgroup, not the SAID therefore allowing console dispatcher to be heard on multiple talkgroups but the radio subscriber user to be heard on their own talkgroup only.

On L3Harris systems migrating from EDACS using the Migration Gateway (EMG) this is fairly tight and slick integration as patching on the connected legacy system is preserved as well as source IDs, emergency, individual calls, etc. Post-migration, once the EMG is taken out of the picture - this continues to be relevant as the talkgroups are patched to the System Assigned ID there is a bit flag in the CC TSBK which determines if it is a Simulselect (One-way dispatcher to multiple talkgroups, while SU on those talkgroups continue to be granted their selected/affiliated talkgroup) or a Patch (Two-way dispatcher to multiple talkgroups including all users regrouped to the new SAID Group).

Both the MFID A4 (L3Harris) and MFID 90 (Motorola Solutions) methods are now described in TIA-102.AABH, additionally validating this behaviour may include some observation on a live system FNE. If raw I/Q samples of control channels are required for duplicating this at the developer(s) location in case they are not in range of a L3Harris VIDA FNE I may be able to provide some examples. Finally when the patch is torn down there is a matching CC opcode to assert this condition BUT also in the case where poor reception/errors in decoding resulted in the tear down to be missed, the receiver (SU) should eventually (within mere seconds) revert to the normal handling behaviour if the relevant Patch/Simulselect Announcement has not been received in some time.

Overall this is not just a SDRTrunk issue but a real issue for those of us working on mixed-vendor radio systems with subscribers having inconsistent patch handling behaviour. For example EFJ was particularly late to the party notably only finally implementing this MFID A4 patch handling on their subscriber devices in July 2020 after numerous use cases were raised and logging was submitted. Further complexity ensues when Supergroup patching a mix of encrypted and clear talkgroups which is a different mess altogether.

[Seagravebuff60]

I, unfortunately, cannot capture an active screenshot in SDRTrunk as the patches are not active currently not active but when I can ill reply to this thread

To further add to my original bug report with the screenshots I said I would. Here are some screenshots of SDRTrunk as the patches are currently active.

Notice how SDRTrunk only displays the patch 65xxx Talkgroup and not the Supper and Subgroups that are being patched. Ultimately whatever SDRTrunk spits out as far as TG and RID Information, Trunking Recorder will interpret.

For further analysis, Here is a comparison of the same group call with SDRTrunk and TR side by side.

[DSheirer]

@TRENT310 Can you provide a few recordings of an L3Harris (MFID A4) control channel that would contain the A4 patching messages? In sdrtrunk, please turn on bitstream recording for the control channel and send the bitstream recording files.

I don't have access to the TIA-102.AABH document ... I can try to figure out the content of the messages from any recordings that you might provide.

[repairfox]

The technicals of this discussion are a but over my head, but I too, have a harris P25 system and experience these patches. A work around for me has been to add ECC radio ID aliases, and use that instead of the the patch group range (65100-65299).

The patches are very frequent on my system. I should be able to get some recordings with your above instructions @DSheirer, maybe it can help.

[repairfox]

@DSheirer here is a zip with bitstream recordings. There are at least 3 patched calls in this set. Dropbox

[josephdambrosio]

I too have this behavior issue. I've toggled on logging and recoding and will try to get this traffic shared the next time this happens.

[lwvmobile]

@DSheirer Is this what you are looking for? Just the PDU itself? As far as I know (unless its been updated) this is the only MFID A4 PDU in the TIA manual. I also figured out a Talker Alias Opcode for A4 as well.

http://forums.radioreference.com/threads/duke-energy-p25-system.411183/post-3908078

You can PM me over there on RR if you need or want more specifics.

[DSheirer]

@lwvmobile Thank you very much! Working on code updates now.

[DSheirer]

@Seagravebuff60 @TRENT310 @repairfox @josephdambrosio
I just merged support for L3Harris patch groups into the master branch with this PR: #1677

If you are able, can you please build off of master and test against your L3Harris P25 system and let me know if the patch group support is working correctly? If you're not able to build against the master branch, I'll be releasing a new beta version in the near future.

Thanks to everyone for inputs/support for this and special thanks to @lwvmobile for the ICDs :-)

[Seagravebuff60]

Thanks, @DSheirer! I was able to build off of the master branch and test the system successfully. The System I'm working with isn't that active with patching, but I was able to find a few minutes where it was. After testing a bit, I can confirm that it is not working as fully intended.

In the Events window, you can see that when a patch is indicated, SDRTrunk treats it as a patched call but displays an unknown TG of 32768. It displays the 65xxx talkgroup correctly, tho. So, it is displaying the subgroups that are being patched incorrectly. It's showing 32768 being in the patch, while TG 102 & 104 should be displayed as those are the subgroups being patched. I am not sure where TG 32768 is coming from, as it is not a TG in use on the system. Also, the Event Collum is not displaying it as a Patched call but rater a regular Group Call.

Furthermore, when looking at Trunking Recorder, it shows the RAW output from SDRTrunk in the "Target Label" column. Then, it is not correctly Displaying the Subgroups 102 & 104 in the "Target" Collum.

While Trunking Recorder should look like this and stack the TGs in the "Target" and "Target Label" Collum.

I believe this to be an SDRTrunk issue rather than a Trunking Recorder issue because Trunking Recorder will display whatever SDRTrunk is outputting. But if not, I will gladly ask for a solution from the Trunking Recorder Developer.

Thanks again, Denny, for your attention to this issue!

[josephdambrosio]

Thanks, Denny! I was able to build off of the master branch and test the system successfully. The System I'm working with isn't that active with patching, but I was able to find a few minutes where it was. After testing a bit, I can confirm that it is not working as fully intended.

In the Events window, you can see that when a patch is indicated, SDRTrunk treats it as a patched call but displays an unknown TG of 32768. It displays the 65xxx talkgroup correctly, tho. So, it is displaying the subgroups that are being patched incorrectly. It's showing 32768 being in the patch, while TG 102 & 104 should be displayed as those are the subgroups being patched. I am not sure where TG 32768 is coming from as it is not a TG in use on the system.

Furthermore, when looking at Trunking Recorder, it shows the RAW output from SDRTrunk in the "Target Label" column. Then, it is not correctly Displaying the Subgroups 102 & 104 in the "Target" Collum.

While Trunking Recorder should look like this and stack the TGs in the "Target" and "Target Label" Collum. I believe this to be an SDRTrunk issue rather than a Trunking Recorder issue because Trunking Recorder will display whatever SDRTrunk is outputting. But if not, I will gladly ask for a solution from the Trunking Recorder Developer.

Thanks again, Denny, for your attention to this issue!

Are you able to send over the distribution build? I've been trying to build off master all morning but hitting wall after wall with JFX issues to build.

Thanks!

[josephdambrosio]

Was finally able to build off master, and have it running now. Will advise when the next patch goes up on behavior.

[Hermite123456]

Hi, With the new Beta 3, I am also seing some confusion on the parsing. SDRTrunk or Trunking Recorder issue?

[Seagravebuff60]

Hi, With the new Beta 3, I am also seing some confusion on the parsing. SDRTrunk or Trunking Recorder issue?

Im not sure, but I think it's an SDR Trunk issue. Il look into it.
Is this with a Haris P25 System? @Hermite123456

EDIT: I just downloaded Beta 3 and can confirm the same issue and what you are seeing.

[Seagravebuff60]

Just finally got around to installing the nightly build of SDR Trunk. Anyway, the Parsing issue seen above in the Trunking recorder display was actually an issue with trunking recorder. My mistake. Installing the latest beta of Trunking recorder will fix the issue.

Anyway, I am still noticing That SDR Trunk is displaying the wrong subgroup(s) that is in the patch.

For example, SDR Trunk (and then ultimately TR) will display the wrong subgroup. In this example, the supergroup is displayed as TG 32768 when the actual subgroups that are being patched are TG 102 and 104.
SDR Trunk:

Trunking Recorder:

Is there any workaround to this?

[DSheirer]

@Seagravebuff60 (edit - I just reread what you posted previously).

Can you create a bitstream (.bits) recording of the control channel while these patch groups are active and send it to me? Along with that recording, can you also please indicate which patch groups and sub groups I should be seeing in the recording?

[Seagravebuff60]

Correct. Im seeing the subgroup info on Unitrunker, and they are 2 known talkgroups on the system.

Anyway, the patching is infrequent and i have to catch it at the right time, but when i do i will upload the recordings you requested.

[josephdambrosio]

@DSheirer

Hey Denny,

Not sure if you saw my comment on #1677 but I uploaded a ZIP with a recording of the patch activity https://github.com/DSheirer/sdrtrunk/files/13382709/pathrec.zip

System TG 2350 is patched using the Harris Dynamic Patch TG of 65132

[Seagravebuff60]

@Seagravebuff60 (edit - I just reread what you posted previously).

Can you create a bitstream (.bits) recording of the control channel while these patch groups are active and send it to me? Along with that recording, can you also please indicate which patch groups and sub groups I should be seeing in the recording?

Thanks, @DSheirer I was able to grab a bitstream recording of the patch, I attached it in the Dropbox link below.
https://www.dropbox.com/scl/fo/uq5ftl9e90bkof2u2mq63/h?rlkey=vuh37zczugh8z52dbqi1kp7py&dl=0

Talkgroups 102 & 104 are the actual subgroups that you should be seeing being patched to the supergroup 65139.

[Seagravebuff60]

@DSheirer were you ever able to look into this?

Thanks, @DSheirer I was able to grab a bitstream recording of the patch, I attached it in the Dropbox link below. https://www.dropbox.com/scl/fo/uq5ftl9e90bkof2u2mq63/h?rlkey=vuh37zczugh8z52dbqi1kp7py&dl=0

Talkgroups 102 & 104 are the actual subgroups that you should be seeing being patched to the supergroup 65139.

[DSheirer]

@Seagravebuff60 apologies, I haven't had a chance to look at the recordings yet.

[Seagravebuff60]

Hey, @DSheirer, I'm wondering if this issue here can be reopened as I'm still having this issue in V 0.6.0 Final. Were you able to look into the bitstream recordings i sent on December 3rd?