Failing to Receive VHF Trunk System

[fmulder13]

I am attempting to scan the Maine State Communications Network (MSCommNet, link to RRDB below, and experiencing an odd phenomenon. A GRE scanner decodes and receives the system fine. A 436hp shows full signal strength, but has no audio. An HP-1 will not show an active site while holding on the system.

The link to the system in the RRDB is as follows:

Maine State Communications Network (MSCommNet) Trunking System, Statewide, Maine - Scanner Frequencies

A video demonstrating all of the above is below:

https://youtu.be/KU66sGbkQFs

(The spoken voices are my family members, ever patient to converse over scanner chatter!)

The Unidens are programmed directly from the HPDB, updated 7/26/15. My next move is to manually program the system from scratch on one of the Unidens, hoping for change.

In the meantime, I would greatly appreciate any advice on how to proceed. Both Unidens have received the system on and off in the past few hours, but since turning all 3 scanners on and taking the video, the GRE has been consistently receiving, the Unidens have been consistently silent.

Thank you for your help!

Chris

 

[fmulder13]

Update: creating a new system from scratch on the 436hp has failed, yielding only the same results as before. You'll notice the GRE does not register a RadioID when it receives, which is another puzzling issue, perhaps having implications towards whatever is causing the Unidens not to receive this system? I'm fairly savvy with this kind of thing, but this has me completely confused.

 

[phask]

Are tge service types on?

WHICH site and TG in case location data is wrong.

Does the Fav. have location enabled?

 

[fmulder13]

Yes, correct service types are enabled. The site is Cook Hill, and all Law Dispatch, Law Talk, and Law Tac are enabled. I'm not using a favorites list at this point.

 

[fmulder13]

Update on the problem: If I hold on a channel (Zone 2A, TGRP 721, for example) I will OCCASIONALLY get audio. However, about 7-8 times out of ten, the GRE will receive traffic on the same talkgroup, while the 436hp remains silent. This remains the same whether I use the stock rubber duck antenna or a VHF antenna mounted to the car.

 

[talkpair]

Are you able to run Unitrunker or Pro96Com on this site with your Uniden?

This may help determine if the radio is decoding the control channel or not.

I noticed the control channel for Cook Hill is in the 152 MHz paging band, which isn't good from an interference standpoint.

 

[fmulder13]

I have not had a chance to run Unitrunker of Pro96Com yet, but I will give that a try.

Update: Taking a trip through other sites found this problem all but eliminated on other sites, with no adjustment to any settings or setup on my part. However, the 436hp continuously missed second transmissions in a conversation. It caught the first fine, ignored the second, and came into the third transmission late, while the GRE caught everything.

Later last night, I tried UPMan's suggestion in this thread, (http://forums.radioreference.com/uniden-owner-tech-support/285012-test-p25-decode-improvement.html) and that got the 436hp to behave as it did on other sites, receiving first transmissions, missing seconds, catching thirds late.

As I sit watching both scanners work, I notice one thing that might have some bearing on this current issue. When the 436hp receives a transmission, it continues to display the unit ID, past the end of the audio, through the second transmission that the GRE catches and the 436hp misses. Does this maybe point to another setting that can be adjusted? I can't think of one off the top of my head...

 

[fmulder13]

I also notice that right after a first transmission in a conversation, the signal strength meter will drop, and the DAT will drop off from the screen, all while the UID from the previous transmission hangs on the screen. After 2-3 seconds the signal strength meter will return to full bars, DAT will return to the bottom of the screen, and the UID will drop. All the while, the GRE acts completely normal. Surely there is something to adjust here that I'm just missing. I have never seen the 436hp behave like this scanning any other P25 trunked system.

 

[talkpair]

It sounds to me like the scanner isn't returning to the control channel as soon as the voice channel is released.

For trunked systems, the scanner should not assume that the followup transmissions will occur on the same voice channel, therefore it's important to get back to the control channel as soon as the voice channel goes idle to get instructions for the followup. If there are no followups and the delay time is reached, scanning can resume.

I don't own a Uniden, but I would check the manual for any settings applicable to timings.

 

[fmulder13]

I can't seem to find relevant settings relating to that sort of timing, though I suspect that is the problem. The strange, strange thing is the way the UID remains on the screen after the audio stops, as though there's a per-channel delay on the UID itself set. It happens in this order: Transmission received, audio stops, UID remains on screen, SSM drops, DAT disappears, UID disappears, SSM goes back to full, DAT reappears, scanner receives audio normally again. This has happened using the full database, a FAV list compiled from the database, and with a system constructed from scratch.

I have noticed from looking at the GRE that every transmission uses a new voice channel: no subsequent transmissions ever use the same VC two times in a row.