Unknown Talk Group Question

[K1TSL]

Hi All,

Apologies if this has been addressed. Did a search, was not able to find info on this specific issue.

I have a favorites list the includes my town's talk groups as they appear on the Massachusetts State Police system. They are tagged(named) thanks to existing info on the imported RR database. It shows TGID and name as they should.

I have a different favorites list in which I have ID SEARCH activated on the same system. When it sees these talk groups (or any others), it shows "Unknown" rather than the talk group name.

Does the SDS not have the capability to cross reference the TGID with the internal RR database to pull the name? I guess I'd like it to tell me when it lands on something what it is by name especially when it's something that's already in the database. I'd understand it displaying Uknown if it was not already elsewhere on the scanner. Otherwise, you have to go searching for info on what the scanner should already have access to. Not sure why this would be the case.

Am I missing a setting or is this just not a feature?

 

[hiegtx]

Hi All,

Apologies if this has been addressed. Did a search, was not able to find info on this specific issue.

I have a favorites list the includes my town's talk groups as they appear on the Massachusetts State Police system. They are tagged(named) thanks to existing info on the imported RR database. It shows TGID and name as they should.

I have a different favorites list in which I have ID SEARCH activated on the same system. When it sees these talk groups (or any others), it shows "Unknown" rather than the talk group name.

Does the SDS not have the capability to cross reference the TGID with the internal RR database to pull the name? I guess I'd like it to tell me when it lands on something what it is by name especially when it's something that's already in the database. I'd understand it displaying Uknown if it was not already elsewhere on the scanner. Otherwise, you have to go searching for info on what the scanner should already have access to. Not sure why this would be the case.

Am I missing a setting or is this just not a feature?

The scanner does not cross reference the main database. If you have the system programmed, without any (or at least, not all of the talkgroup IDs), then for those received by the system (on a separate Favorites list) are treated as 'new', showing only the TGID, not text tag. If, instead, you were using the Discovery feature, not normal scanning, then you have the option as to whether the scanner checks the main database to cross reference already identified TGIDs. But Discovery is only using one site, to check for any new activity, so that's not an option for normal scanning.

None of the Uniden scanners, nor for that matter any of the GRE/Whistler scanners cross reference the database for TGIDs. They all rely on what you have programmed. If your intention of using the separate Favorites list, with ID Search enabled, is to look only for new IDs, then add all of the identified talkgroups to that system, but set them, or the Departments they reside in, to Avoid status. ID Search will then only find TGIDs that are not identified and programmed, and you would only see true "unknown" IDs. ID Search skips IDs that are programemd, but set as Avoided (HP series scanners), or locked out (non-database DMA scanners).

 

[jonwienke]

You should never delete talkgroups from a system. They aren't scanned, so having thousands of talkgroups programmed has no effect on scan speed.

 

[K1TSL]

The scanner does not cross reference the main database. If you have the system programmed, without any (or at least, not all of the talkgroup IDs), then for those received by the system (on a separate Favorites list) are treated as 'new', showing only the TGID, not text tag. If, instead, you were using the Discovery feature, not normal scanning, then you have the option as to whether the scanner checks the main database to cross reference already identified TGIDs. But Discovery is only using one site, to check for any new activity, so that's not an option for normal scanning.

None of the Uniden scanners, nor for that matter any of the GRE/Whistler scanners cross reference the database for TGIDs. They all rely on what you have programmed. If your intention of using the separate Favorites list, with ID Search enabled, is to look only for new IDs, then add all of the identified talkgroups to that system, but set them, or the Departments they reside in, to Avoid status. ID Search will then only find TGIDs that are not identified and programmed, and you would only see true "unknown" IDs. ID Search skips IDs that are programemd, but set as Avoided (HP series scanners), or locked out (non-database DMA scanners).

This is what I suspected and I appreciate your detailed explanation here. I was concerned that there was a feature or option I had not enabled or there was a bug in the firmware on my unit. It's a bit odd (at least to me) that it wouldn't report the name of a TGID already recorded in the database but instead list it as unknown. Maybe I am in the minority of people who would be interested in that. I know it is also specific to how I use my scanner.

 

[jonwienke]

The solution is simple: don't delete talkgroups when you export systems from the main database to a favorite list. There's no benefit in doing so, and several drawbacks.

 

[K1TSL]

I think that would be helpful if I had indicated that was the issue. I haven’t actively deleted anything. I simply have a situation in which I have separate favorites lists to target certain towns under the same system so I can customize my listening experience. I was just asking why if I do an ID search on either one of those lists, the scanner is not smart enough to cross reference the existing database with the alpha tags on talk groups as opposed to saying unknown. If I was not clear, I apologize but I did review my post and I didn’t indicate anywhere that I was actively deleting talk group content. If by delete, you mean “not importing” then I guess we are looking a the same issue from different ends
It makes no sense for me to dump all of the talk groups into a single favorites list when I’m simply trying to target a specific region within a larger system.
The Massachusetts state police system in my area covers several towns as well as state wide. I like to keep them separate. I don’t want to have to listen to all of it and I don’t want to have to go in and enable or disable several different options within a list.

 

[K1TSL]

You know, your response got me thinking about just re-organizing how I maintain my lists. It actually wouldn’t be that much effort to put some of these under a single favorites list as sublists and I think that would solve the problem.
I still think it’s odd that the software will not cross reference its own tgid database outside of a favorites list, but I can see the workaround.

 

[hiegtx]

You know, your response got me thinking about just re-organizing how I maintain my lists. It actually wouldn’t be that much effort to put some of these under a single favorites list as sublists and I think that would solve the problem.
I still think it’s odd that the software will not cross reference its own tgid database outside of a favorites list, but I can see the workaround.

That would require a second step before displaying the active TGID, and likely would increase the amount of time the scanner spends on a specific system. We already see complaints when someone has far too many sites in a system, slowing scanning speed. If the scanner was also called on to check the main database before receiving a TGID & playing the audio, that would be another drag that slows down speed.

The only real advantage in using ID Search (adding a Wild Card on the Whistler or GRE Object Oriented scanners does the same thing) is that you find TGIDs that are not already identified. If that's you goal. then add all the ones currently identified, but set them (or the Department they reside in) to Avoid. As I noted above, the avoided TGIDs will not show up, but anything not in the database would. Another potential issue that might crop up, if the scanner had to verify IDs both with the Favorites list and the main database, is that in some cases, the System name, Department name, or TGID text tag has been modified to something other than what the main database contains. A number of scanner users, including myself, alter the name to something that makes more sense to us than the default name from the database. That's one reason that Sentinel does not update Favorites lists when a database update is written to the scanner. That way, Sentinel does not overwrite whatever text tags were changed by the user. While, by no means have I changed the names on everything, nor even a substantial number, there are some that I have changed.

 

[werinshades]

It makes absolute sense to delete talk groups when you have no interest in it. If you know what it is, and you don't want to hear it, put only those talk groups of those departments you'd like to hear and ID Scan. The best part about these scanners is if you own it, you can set it up however you'd like and no method is wrong.

I use the database as a guide, and rarely download from it. Too much unnecessary information for my listening needs and I set it up/text tag it to my preferences. Besides that, I get to learn more about using Sentinel and the scanner itself. If I make a mistake, edit and send to scanner. Whatever works the best for you.

Just to add...if you're intent is to find new talk groups, you can also set up departments within a system and lock them out. Similar to what Steve said, but another way.

 

[jonwienke]

You know, your response got me thinking about just re-organizing how I maintain my lists. It actually wouldn’t be that much effort to put some of these under a single favorites list as sublists and I think that would solve the problem.
I still think it’s odd that the software will not cross reference its own tgid database outside of a favorites list, but I can see the workaround.

Any time you're scanning the same system more than once, you're wasting scanner time. A trunked system should only appear in your active scan rotation once. If it appears multiple times (e.g. once for police traffic, and once for fire traffic) then if a fire call comes in while the scanner is scanning the police instance of the system, it will be ignored until the scanner gets around to scanning the fire instance of the system. Program the system only once, and if need be move talkgroups from on department to another so you can toggle stuff by department if Service Types aren't precise enough. Anything els bogs down the scanner unnecessarily, and is guaranteed to miss more traffic.