Database TG Reporting

Status
Not open for further replies.

RayAir

Member
Joined
Dec 31, 2005
Messages
1,925
I would like to suggest that unidentified TGs be permitted for the RR database.

Especially for medium to large sized TRS.

It is extremely difficult to get an exact user ID for TGs, especially systems like Connect Plus.

Many times I am passing through a town and I'll snag several active TGs, but cannot run the many hours of signal surveillance on each TG to "maybe" get an ID other than what it is used for in general.

It would be nice to be able to submit unid TGs to say, hey, these TGs exist on this system and maybe some other RR users would be interested in monitoring them thus increasing the chances of getting an accurate user ID.

Connect Plus systems are the worst to ID users. There are a lot of TGs and the users can be pretty much anything. I've heard TGs speaking Spanish (farming ops) all the way to public safety TGs.

Let's get the info out there.

Also, I see many TRS listed in the db that have been off the air for years.

Thanks for reading this and I enjoy this site very much.
 
Last edited:
D

DaveNF2G

Guest
True, but the Wiki is not able to load a complex trunked system directly into any scanner.
 
D

DaveNF2G

Guest
Adding a level of complexity to what are supposed to be "entry level" scanners and their interface with RRDB. Separating good data (even if short on certain details) into different parts of the site, with different user interfaces, reduces the utility of the site IMO. Perhaps the "unconfirmed" entries could be assigned a particular type or flag, like the encrypted and other non-scannable modes, so that the user could decide whether or not to download such data.
 

RayAir

Member
Joined
Dec 31, 2005
Messages
1,925
I got ya. I was thinking more about submissions for systems that cannot be downloaded into current market scanners and require the use of specialized software.

I can see the problem unid TGs would cause for P25 systems and users downloading possibly unwanted TGs to their scanner.

I'll check out the wiki. I was unaware of it.

Thanks.
 
D

DaveNF2G

Guest
My point is that it should be up to the scanner user to decide what is "unwanted" and not the DB Admins at Radio Reference.
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
My point is that it should be up to the scanner user to decide what is "unwanted" and not the DB Admins at Radio Reference.

I understand and partially agree, because for those who want a more convenient capability of selectively downloading that data into their scanner, having it in the RRDB would be nice.

But, can you imagine the increased work-load for the "handful" of volunteer DBAs (who already have plenty of confirmed data to enter into the RRDB), if they were to be expected to enter into the RRDB all of the unconfirmed TGs currently stored in the Wiki, and then later expected to update each one as partial-updates were submitted, and again later when full confirmation existed? By keeping the unconfirmed/unknown TGs in the Wiki, it puts the data-confirmation workload on the person who observed/listened, and then only after confirmation is complete does it impact the DBAs workload. I might be wrong, but it seems that burnout of the volunteer staff would likely go up if unconfirmed data were allowed in the RRDB.

Just one opinion,
 
Last edited:

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,354
Location
Bowie, Md.
As long as the data is kept in a column or table like format, many scanner programs can pick this data up without much trouble. Examples include FreeScan's EZ-Grab, or Paste Special for BuTel programs (I think). And you should be able to use Excel (and similar) for those that don't have these capabilities. We have an article in the wiki that describes just such a procedure.

So while putting these unknowns in the database would be nice simply because the web service could easily pick them up, you can import them from the wiki. Granted, it's not as slick as the web service, but it works. No manual (and error-prone) re-typing is really necessary, except for some cleanup of descriptions and things of that nature (remembering that most descriptions are limited to 12 or 16 characters...). Mike.
 
Last edited:
Status
Not open for further replies.
Top