Recently just downloaded Trunk88, an awesome program so far. However the system I'm decoding has 5 digit long tgid's and trunk88 is showing 4 number ones, and they don't look anything like the ones in the db. So am I just not looking at the software right or is there something else I should be doing?
Trunk88 tgid's
- Thread starter Gezelle007
- Start date
- Status
RKG
Member
This needs to be amplified a bit:
Assuming we are talking about a Type II SmartNet/SmartZone system, there are three ways to express the same TG ID:
The Motorola native format is a 3-digit hexadecimal number. For instance, the MSP A-PTL-1 TG ID is 819h. (Valid range: 001h through FFFh, or 4,094 possible values.)
Some Motorola radios express TG IDs as the decimal equivalent of the hex number (e.g., GTX). So 819h becomes 2073. (Valid range: 1 through 4095, or 4,094 possible values.)
These systems also have a "status bit" that may signify an additional bit of status information (e.g., simulcast). A number of "trunk tracker" consumer-grade receivers would take the byte equivalent of this bit and append it to the 3-digit hex number (e.g., an A-PTL-1 group channel grant in normal mode would be treated internally as 8190h), and then convert that to decimal (e.g., 8190h becomes 33168). (Valid range: 16 through 65520 in 16 unit steps, or 4,094 possible values.
Three different ways of denoting essentially the same thing. But note that dividing 33168 by 16 yields 2073, not 819, so the "divide by 16" rule has to be applied with an understanding of what it is you are dividing.
One further wrinkle: when the SmartNet II feature set came out, it introduced priority trunk scanning. To do this, the radio was limited to using TG IDs that were hexadecimal "even" number (i.e., ending in 1, 3, 5, 7, 9, B, D or F). That is why "valid" SM II TGIDs have to be evenly divisible by 32.
Assuming we are talking about a Type II SmartNet/SmartZone system, there are three ways to express the same TG ID:
The Motorola native format is a 3-digit hexadecimal number. For instance, the MSP A-PTL-1 TG ID is 819h. (Valid range: 001h through FFFh, or 4,094 possible values.)
Some Motorola radios express TG IDs as the decimal equivalent of the hex number (e.g., GTX). So 819h becomes 2073. (Valid range: 1 through 4095, or 4,094 possible values.)
These systems also have a "status bit" that may signify an additional bit of status information (e.g., simulcast). A number of "trunk tracker" consumer-grade receivers would take the byte equivalent of this bit and append it to the 3-digit hex number (e.g., an A-PTL-1 group channel grant in normal mode would be treated internally as 8190h), and then convert that to decimal (e.g., 8190h becomes 33168). (Valid range: 16 through 65520 in 16 unit steps, or 4,094 possible values.
Three different ways of denoting essentially the same thing. But note that dividing 33168 by 16 yields 2073, not 819, so the "divide by 16" rule has to be applied with an understanding of what it is you are dividing.
One further wrinkle: when the SmartNet II feature set came out, it introduced priority trunk scanning. To do this, the radio was limited to using TG IDs that were hexadecimal "even" number (i.e., ending in 1, 3, 5, 7, 9, B, D or F). That is why "valid" SM II TGIDs have to be evenly divisible by 32.
From the "read me" file included with the program:
I haven't used program for a few years but I believe you have to edit trunk88.ctl file with a text editor. Can also be done within program if you know the commands.
Using a text editor find
; 0=hex, 1=hex w/leading zeroes, 2=decimal, 3=dec w/leading '8', 4=TT decimal:
Talkgroup Display Format = 4
Change the talkgroup display format.
The database uses the above or 4 (TT decimal) I think.
Thanks, that fixed it.. I guess I should have read the instructions first?? Lol.
Heh, no problem 
- Status
