396 -- ID SEARCH/ID SCAN -- Bug.

[ctrl]

I have read somewhere about this before, however I lost it and dont feel like searching for it.

With uniden keeping on top of updates for this scanner, how about we get an update that fixes a problem?

This problem happens, when using ID search mode, and scanning ANY other trunked system at the same time.

The problem:

Talk group ID's from the system being ID SCANed that are locked out show up on the OTHER system that is in ID SEARCH mode, and are displayed and played. These aren't even on the same control channel and yet, its showing up in the ID SEARCH system.


This really irritates me when trying to search for new ID's on a system, and still listening to known systems at the same time. Pretty much makes it impossible to do with the ammount of locked out talkgroups that keep popping up.


I know this has to bother more people then me?

If so, I'm sure there is someone that can explan it better..


Or maybe its just me?

-Jim

 

[Casey]

100 percent!! I have the same issue. The two systems i'm having that trouble with are both assigned the same quick key. I wonder if I seperate them to their own quick keys if it would fix the problem. I'm having the trouble in the current and prior firmware btw and these are 9600 baud/P25 systems.

 

[ctrl]

I dont think seperating is going to help, as I dont have any assigned to the same key.

And yes, I suppose mentianing they are BOTH p25 systems, is a good idea.

 

[rdale]

You might want to post a clone file - sounds like a programming issue. I've never had a problem mixing SCAN and SEARCH.

 

[VORTAC]

The BC796D will do the same thing when in search mode, you search between a APCO-16 digital Motorola system and a true P25 system. I called ghost ID...

 

[ctrl]

Here is 2 files that I have the problem with. 01-Phoenix Police.usd, is on SEARCH mode, and 03-Glendale Police.usd is on SCAN mode.

I end up with Talkgroups from 03-Glendale, coming up on 01-Phoenix if I have both systems enabled at the same time.
Even the talkgroups that are locked out in 03-glendale are displayed, and audible.

 

[Casey]

Has anyone forwarded this bug to Uniden yet? I will shoot it over as it seems like an obvious (andy easy to fix?) bug?

 

[DaveIN]

Well the UASD files are not mixed, nor are they near in number.

How close are these towers? Are they full signal strength?

If you remove one of the systems from memory do you still see the talkgroups come up on the other system?

 

[ctrl]

Well the UASD files are not mixed, nor are they near in number.

How close are these towers? Are they full signal strength?

If you remove one of the systems from memory do you still see the talkgroups come up on the other system?

I'm not exactly sure about how close the towers are. I am sure however they are pretty close. Full signal on them both.

No, If you remove one of the systems you dont see this problem. The thing is you dont even need to remove it, just disable the system that is in ID SCAN, and the ID SEARCH system works fine.

The problem happens when you scan a system in ID SEARCH, and a different system in ID SCAN at the same time.

The system doing the ID SEARCH, picks up talk groups from the systems being ID SCANed.

The system doing the ID SCAN, has groups with talkgroups locked out. The locked out talkgroups are the ones being displayed on the ID SEARCH system.


I know it sounds confusing, however I can re-create the problem at will.



This leaves the ID SEARCH option USELESS, unless you only scan 1 system while using it.

 

[rjschave]

I'm not exactly sure about how close the towers are. I am sure however they are pretty close. Full signal on them both.

No, If you remove one of the systems you dont see this problem. The thing is you dont even need to remove it, just disable the system that is in ID SCAN, and the ID SEARCH system works fine.

The problem happens when you scan a system in ID SEARCH, and a different system in ID SCAN at the same time.

The system doing the ID SEARCH, picks up talk groups from the systems being ID SCANed.

The system doing the ID SCAN, has groups with talkgroups locked out. The locked out talkgroups are the ones being displayed on the ID SEARCH system.

I know it sounds confusing, however I can re-create the problem at will.

This leaves the ID SEARCH option USELESS, unless you only scan 1 system while using it.

I have this problem with 2 systems that are both in ID SEARCH mode, regardless of the TG lockout status. Both systems are P25.

It seems the scanner is scanning frequencies in one system and checking the TGID's against the other system.

Have you tried locking out the TG's in the ID SEARCH system that are also locked out in the ID SCAN system?

 

[UPMan]

So, from your files above, only "16A Glendl Arena" TGID 323 shows up on the Phoenix search? (It is the only talk group locked out of the Glendale system.)

 

[ctrl]

So, from your files above, only "16A Glendl Arena" TGID 323 shows up on the Phoenix search? (It is the only talk group locked out of the Glendale system.)

Negative, The whole group "City Services" is disabled.

Dial a ride, Parks and Rec, All these show up too.

 

[UPMan]

Hmmm. The file above shows it as unlocked. Do you mean that it's GQK is disabled?

Trying to understand so that I can try to duplicate the issue...so far I'm not seeing it, but it sounds like there are factors that are not fully/clearly described in any of the threads carrying this discussion.

 

[ctrl]

Hmmm. The file above shows it as unlocked. Do you mean that it's GQK is disabled?

Trying to understand so that I can try to duplicate the issue...so far I'm not seeing it, but it sounds like there are factors that are not fully/clearly described in any of the threads carrying this discussion.

Glendale PD.usd = ID SCAN mode
Phoenix PD.usd = ID SEARCH mode

The GQK for "City Services" is Disabled in glendale. This system is in ID SCAN.

That group of talkgroups, Dial a Ride, Parks and Rec, Streets, ect.
Show up on the phoenix system (ID SEARCH) even though the GQK is disabled.


System1: To duplicate the problem, load a system with more then 1 GQK, but disable one of the groups. Run this system in ID SCAN.

System2: Load another system, and scan that in ID SEARCH.


Outcome: Watch all the talkgroups from system1 show up on system2.


It IS hard to explain. Actually re-producing the problem might be as easy as scanning 2+ systems in ID SEARCH at once. But having a GQK disabled in any of the systems, or having 1-2 locked out active talkgroups.

 

[UPMan]

So far, no joy. Send me a private email (popitz@uniden.com).

 

[UPMan]

We have isolated the conditions that can result in the improper TGID operation:

1) ID Scan a P25 system
2) The scanner just receives a TGID packet from control channel when the hold time expires.
3) The next system is P25 or P16 system and ID-search mode.

Which explains why I could not duplicate the issue...no P25 systems in DFW.

We will issue an update, however it might be several months away. There are a number of other minor issues we will be addressing at the same time, and this development requires coding, testing, etc that cannot be done overnight.

However, from the above, it looks like you can avoid the issue for now by creating a new conventional system that has at least 1 channel and giving it the same SQK as the P25 system (and giving it a hold duration of 0) so that it is scanned immediately after the P25 system and before the ID Search system. The conventional system will be scanned by so quickly as to be nearly invisible in operation, but should result in the issue disappearing.

Thank you all for your patience (and for helping to sort this out).

 

[Casey]

Sounds great, I want to thank Uniden once again for helping to further refine a great scanner!

 

[ctrl]

Sounds great, I want to thank Uniden once again for helping to further refine a great scanner!

So has this fix been working for you then?

I tried this fix with no luck..

 

[Casey]

Actually what I did was copy over list of talkgroups that were "bleeding over" into adjacent P25 system I was scanning and locking them out in that system. Temporary fix.