G4/5 receiving unprogrammed talkgroups

[ResQguy]

Has anyone experienced a G4 or G5 receiving P25 talkgroups that aren't even programmed in?

Example: Scanning a handful of fire talkgroups in the decimal 9000 range on a P25 800MHz system with one site. Frequently, police talkgroups in the 9100 range will unmute even though they are not contained anywhere in the loaded profile. Since they aren't intentionally programmed, obviously they don't have group aliases. This is super annoying on busy days as I have no interest in hearing police communications. This only occurs on one system, and is reproducible on multiple devices and firmware combinations- programmed by different people using different profiles.

 

[troymail]

Haven't seen that but it sounds a bit bizarre.

The closest thing I see is occasionally, when monitoring only fire/ems talkgroups for my area, I'll hear the dispatcher talking to a law enforcement unit on another talkgroup but it comes across the fire talkgroup (as an example). I got so interested in figuring it out, I fired up Pro96Com and monitored and found that for unknown reasons, occasionally a brief (like < 1 second) patch was being set up to carry the traffic on multiple talkgroups....

In my case, the patched talkgroup (fire) was programmed so it all made sense... not sure why, as you've described, you'd receive unprogrammed talkgroups... Is there any type of all call or emergency talkgroup on the system? Maybe a setting that is detecting something along those lines? How you looked at it on Pro96Com?

 

[NebraskaCoder]

I would say either a patch or you set the scanlist for P25 Monitor vs P25 Scan.

Sent from my SM-G965U using Tapatalk

 

[ResQguy]

It is not P25 monitor otherwise it would be unmuted 24 hours a day on this system.

The police and fire dispatchers on this system are geographically separated and don't have access to each others daily usage talkgroups on their consoles to make such a patch.

I don't have a radio compatible with Pro96com currently.

 

[APX8000]

There was a known firmware bug where this would occur. I set up Unitrunker and ran it side by side with the G5. The talkgroup was holding on the frequency instead of following the channel grants of the system for the talkgroup. So, Fire talks, stops talking, and then next transmission moves to the next available frequency. But G5 held on the current frequency of the last transmission too long, so if PD was talking and their next available frequency on the channel grant was Fire’s last one, the audio would come through. It seems to have been fixed with the Phase II firmware. What firmware are you running ?


Sent from my iPhone using Tapatalk

 

[ResQguy]

Running 1.00-T08 on all units. It seems this phenomenon occurs mostly in the evenings. I am going to run Unitrunker side by side with my rtlsdr and seen if I can catch it.

 

[APX8000]

If you are seeing it with that version, see if you can run the diagnostic tool and send the file to Unication David. I’m also guessing you see it more in the evening as the system gets busier at a certain time of the day, therefore more channel grants.


Sent from my iPhone using Tapatalk

 

[Uni1]

Could it be multiselect? Groups can be patched from the same system or even two systems.

 

[ResQguy]

Could it be multiselect? Groups can be patched from the same system or even two systems.

It shouldn't be, as the dispatchers don't have those resources available on their consoles

 

[IAmSixNine]

There was a known firmware bug where this would occur. I set up Unitrunker and ran it side by side with the G5. The talkgroup was holding on the frequency instead of following the channel grants of the system for the talkgroup. So, Fire talks, stops talking, and then next transmission moves to the next available frequency. But G5 held on the current frequency of the last transmission too long, so if PD was talking and their next available frequency on the channel grant was Fire’s last one, the audio would come through. It seems to have been fixed with the Phase II firmware. What firmware are you running ?


Sent from my iPhone using Tapatalk

To add to this the OP mentions its mainly on one system. I too have rarely had this issue happen but its also with 1 system. Running trunking i can see the number of channel grants for a few frequencies is much higher then others. So im thinking the system is assigning TG to those freqs on a much higher basis. Since the G4/5 can sometimes pass audio on a frequency with TG not matching i would lean towards that as the cause.

 

[ffexpCP]

I've seen it. Dealer said the site is "too busy and confuses the pager'.