TTTP - Hewlett Packard TRS

Status
Not open for further replies.

b52hbuff

Member
Premium Subscriber
Joined
Dec 19, 2002
Messages
1,742
TTTP - Totally Trivial Trunking Project ;)

I am playing with the Uniden HP-1 Exteme Edition to flesh out some of the trunked systems I can receive from home. Granted these systems aren't the most exciting TRSs in the Bay area, but I can't get many of them from my home and I haven't had an opportunity to travel.

One of the systems I can get is the HP TRS:
Hewlett Packard (Palo Alto) Trunking System, Palo Alto, California - Scanner Frequencies

When I first saw the TGID list, I thought it was totally broken. I knew that none of the TGIDs were legal. Here is a small snippet:
1 000 A Security 1 Security 1 Security
3 000 A Security 2 Security 2 Security
25 001 A Custodial 1 Custodial 1 Business

Those of us familiar with TGID format will recognize that these are 'illegal' numbers, since they have the status bits set and they are not divisible by 16. I was going to recommend that all of these TGIDS get deleted and using the HP-1 Trunking Discovery, that we simply start from scratch.

But then I noticed something, the three active TGIDs I found were:
16, 48 and 400.
Which if you divide by 16, I think come out to 1,3,25.

I think someone must have submitted the TGIDs in 'M3 Format', as described here:
Motorola Talkgroups - The RadioReference Wiki

I propose that we multiply all of the TGIDs by 16 and reinstall them into the database.

Comments?

Anyone care to step up and say who volunteered the data? It looks like an inside job. After two days of monitoring, I only saw three TGIDs. And to let you know how little activity there is, TGID 16 had less than 30 seconds of audio. So much like the NASA/Ames system, it looks like the original architect of the system setup capacity that never appears to be used.
 

kma371

QRT
Joined
Feb 20, 2001
Messages
6,204
Looking at the original submission, the submitor said his numbers were the hex numbers read from the radio, the conversion was done accordingly, but obvisouly something is not right.

TTTP - Totally Trivial Trunking Project ;)

I am playing with the Uniden HP-1 Exteme Edition to flesh out some of the trunked systems I can receive from home. Granted these systems aren't the most exciting TRSs in the Bay area, but I can't get many of them from my home and I haven't had an opportunity to travel.

One of the systems I can get is the HP TRS:
Hewlett Packard (Palo Alto) Trunking System, Palo Alto, California - Scanner Frequencies

When I first saw the TGID list, I thought it was totally broken. I knew that none of the TGIDs were legal. Here is a small snippet:
1 000 A Security 1 Security 1 Security
3 000 A Security 2 Security 2 Security
25 001 A Custodial 1 Custodial 1 Business

Those of us familiar with TGID format will recognize that these are 'illegal' numbers, since they have the status bits set and they are not divisible by 16. I was going to recommend that all of these TGIDS get deleted and using the HP-1 Trunking Discovery, that we simply start from scratch.

But then I noticed something, the three active TGIDs I found were:
16, 48 and 400.
Which if you divide by 16, I think come out to 1,3,25.

I think someone must have submitted the TGIDs in 'M3 Format', as described here:
Motorola Talkgroups - The RadioReference Wiki

I propose that we multiply all of the TGIDs by 16 and reinstall them into the database.

Comments?

Anyone care to step up and say who volunteered the data? It looks like an inside job. After two days of monitoring, I only saw three TGIDs. And to let you know how little activity there is, TGID 16 had less than 30 seconds of audio. So much like the NASA/Ames system, it looks like the original architect of the system setup capacity that never appears to be used.
 

b52hbuff

Member
Premium Subscriber
Joined
Dec 19, 2002
Messages
1,742
Looking at the original submission, the submitor said his numbers were the hex numbers read from the radio, the conversion was done accordingly, but obvisouly something is not right.

My guess is that the hex numbers were converted to decimal w/o multiplying by 16.

As you can see, the TGIDs I found match the db after multiplication...
 
Status
Not open for further replies.
Top