Uniden Not Answering Product Support Question

[tglendye]

I have a BCD436HP with the ProVoice update and overall, I love the scanner. It would work perfectly on my local ProVoice system (Harrisonburg/ Rockingham, VA), but there is an issue when TG's are patched together, and the only way to hear the traffic is in the ID search mode.

That's the problem with the scanner. The problem I have with UNIDEN is I submitted a ticket to their "Support Center" on 2/1/16 and have not heard back from them. I resubmitted the question on 2/15, asking if the original went through... and still nothing. Their automated email message from my ticket says it may take up to 7 business days from the date it is received to respond. I get that, that's great, but we are way beyond that.

Before I submitted my question to Uniden, I created a new topic on RR's forums and asked this question and did not receive any answers from our members. No problem. I get that UPMan cannot monitor all of these forums all of the time, and I feel it is a unique problem that most members probably don't know of a solution- and there may not be a solution other than "ID Search mode". So, I turned to Uniden Product Support for the answer...

I know there are a lot of Uniden bashers here. I do not want to be one of them. But as a customer, I would like them to step up to the plate and respond to my question. It's been nearly a month. UPMan- if you're here, my Uniden Question Confirmation number is: W412529-020116.

Thank you.

 

[UPMan]

We don't typically discuss the status of development (whether something is being worked on or is not being worked on).

 

[Citywide173]

http://forums.radioreference.com/uniden-tech-support/311780-p25-patch-following.html

Search is your friend. It is a known problem, and UPMan's reply, although ambiguous, at least indicates they are aware of it.

 

[sparklehorse]

NM. Answered already.

.

 

[tglendye]

We don't typically discuss the status of development (whether something is being worked on or is not being worked on).

Thanks. I didn't realize it was considered development. Would have been nice to hear that from Customer Support when I posed the question.

http://forums.radioreference.com/uniden-tech-support/311780-p25-patch-following.html

Search is your friend. It is a known problem, and UPMan's reply, although ambiguous, at least indicates they are aware of it.

I followed that thread. Just didn't know if EDACS ProVoice was a separate issue than a P25 system.

I did look for different settings (status bit, etc.). There does not seem to be any settings to adjust. Like I said, it does track fine in ID Search mode when the TG's are patched. You just don't know what TG the traffic will show up on. So... this is fine for now and in the future if an update is engineered, it would be great.

 

[Citywide173]

I followed that thread. Just didn't know if EDACS ProVoice was a separate issue than a P25 system.
.

I think it's more of a patch issue than a format issue. A scanner will always be a foreign radio that monitors the trunk system, not an active, affiliated unit. I am probably way off, but I would think that an affiliated radio which is on a dedicated talkgroup doesn't even realize that two or more talkgroups are patched together, as the data that is necessary to control that radio is minimal, i.e. the radio and the system communicate with each other the exact tower/frequency/TG that is involved, whereas the scanner, without the benefit of affiliation, has to monitor all traffic on the control channel and compare it with the user supplied data to determine if it should stop and unmute on a specific talkgroup. If the datastream has conflicting info such as two talkgroups (the patch), the scanner may be set to ignore as a failsafe to avoid unwanted unmuting in ID Scan, where ID Search doesn't have as strict a guideline for unmuting.

 

[tglendye]

That's how I look at, as well. However you explained it a lot better than I could.

I also wonder if its M-A/Com / Harris's way of limiting the system frequencies that are used per transmission. IE: City PD 1 and Sheriff Patrol 1 become "patched". They end up on a TG that seems to "float" (for lack of a better description). There are several of these TG's that show up and they can be fire & rescue during one transmission and then law enforcement the next time you see them.

But at least Uniden is aware. But my main concern was I did not have something set correctly.

Thanks!

 

[Citywide173]

Dynamic regrouping is a possibility that I hadn't thought of. Subsequently, that would make it almost impossible to monitor in ID Scan due to the transient nature of the TG.

 

[tglendye]

Dynamic regrouping is a possibility that I hadn't thought of. Subsequently, that would make it almost impossible to monitor in ID Scan due to the transient nature of the TG.

You've hit the nail on the head. In my original email to Uniden (which I tried to keep short in this post- because it was more about Uniden not responding), I wrote that someone with knowledge of the system did refer to these as "dynamic talk groups".

I found very little information on the subject at the time, but more searching today includes results with both Motorola and EDACS "dynamic regrouping". The thread I read was 11 years old... but that is the time frame this system was being built.

Thanks again!

 

[Citywide173]

The only time I have ever personally seen dynamic regrouping used was the Memphis Fire Department. Enroute to a call, dispatch could dynamically reassign all radios that were on the call. The radios would make a sound that I can only attempt to describe as a "buzzchirp," which usually let the responding crews know that it was most likely a confirmed incident.

I'm sure if you used radio IDs instead of talkgroup IDs you could follow a little easier, but you would still be limited to the conversations of those units, and only one side, but it might provide you with the TGID of the regroup for temporary addition/unlocking in the scanner. A lot of work for what is probably used very seldom.

 

[tbiggums]

It's been awhile since I used it, but I think my old 396XT properly followed EDACS patched talkgroups, where the scanner would automatically decode the patch message on the control channel and know to look for your desired talkgroup(s) on the system assigned patch ID, even if you didn't have the range of system assigned patch ID's enabled.

Did they really "break" this EDACS patch functionality with the new x36 series? If so, that really sucks...

No Uniden scanner has ever properly followed patched talkgroups on P25 systems, which is why I never bought a x36 model. It sucks when you're trying to listen to a specific few talkgroups that sometimes are patched to others. With a Uniden, you have to listen to any talkgroup that could be involved in the patch on Motorola P25 systems, or the entire system assigned patch ID range for Harris P25 systems. On large systems you'll have to listen to lots of unwanted traffic until you can figure out where your desired talkgroup(s) ended up, and temporarily lock out the other stuff. Whenever the dispatcher alters the patch, you'll have to start that whole process over again...

I can't believe more people don't complain about this.

 

[ecps92]

MA Metro (da METS) PD used it, but that was back in the 16 Channel/TG Days, to Regroup users for Special Events. Altho it is generally still in many radios, I don't think it really get's used now with the newer radios having at a minimum 3 Zones of 16 channels

The only time I have ever personally seen dynamic regrouping used was the Memphis Fire Department. Enroute to a call, dispatch could dynamically reassign all radios that were on the call. The radios would make a sound that I can only attempt to describe as a "buzzchirp," which usually let the responding crews know that it was most likely a confirmed incident.

I'm sure if you used radio IDs instead of talkgroup IDs you could follow a little easier, but you would still be limited to the conversations of those units, and only one side, but it might provide you with the TGID of the regroup for temporary addition/unlocking in the scanner. A lot of work for what is probably used very seldom.