Erroneous Talk Group 42280

[N7YUO]

The following TGRP is listed in the UCAN DB for Utah County:
42280, a52, A, UtahCo Car 7, Utah Co Car to Car (Alpha 7), Law Talk

First, all UCAN TGIDs are evenly divisible by 32, but
42280/32=1321.25. This is not a valid TGID.
Second, hex ID a52 (actually a520) converts to 42272, not 42280.
TGID 42272 belongs to DOT R-1 Shop.

My old listing shows 42880, a780, Utah Co C2C.
Conclusion: 42280 is a typo for 42880.

 

[kf7yn]

I concur with Mike.

 

[Junior1970]

42880

TG 42880 is Utah County Countywide C2C 2. They don't use it much but it is in the county radios as Ch 7.Other agencies have the Tg in a different place hence the labeling as UTCO CWC2C 2.

 

[jim202]

Maybe your system ends up with the decimal TG coming out with an even number. The system
I just looked at the numbers come out with a xxx.5 when divided by 32. I know the system HEX
numbers are correct. So now explain to me why the xxx.5 number comes up and not an even
number as you claim it should.

Jim

The following TGRP is listed in the UCAN DB for Utah County:
42280, a52, A, UtahCo Car 7, Utah Co Car to Car (Alpha 7), Law Talk

First, all UCAN TGIDs are evenly divisible by 32, but
42280/32=1321.25. This is not a valid TGID.
Second, hex ID a52 (actually a520) converts to 42272, not 42280.
TGID 42272 belongs to DOT R-1 Shop.

My old listing shows 42880, a780, Utah Co C2C.
Conclusion: 42280 is a typo for 42880.

 

[JoeyC]

A correct talkgroup will be evenly divisible by 16, not 32.
42280 is indeed an incorrect TG. 42880 is correct.
You should submit the change via the submit button in the database. Talking about it in the forum won't get it fixed unless the UT DB admin sees the thread and decides to act.

 

[bneilson]

A correct talkgroup will be evenly divisible by 16, not 32.

This is where local system knowledge comes into play. N7YUO is 100% correct that a TG on the UCAN 7202 system will be divisible by 32 as the system administrators do not assign every talk group. It is true that Moto allows for a base 16 system, but in this specific case our system is a base 32.

You should submit the change via the submit button in the database. Talking about it in the forum won't get it fixed unless the UT DB admin sees the thread and decides to act.

Also we always talk about things in the forum first to work out the details and make sure we all agree on the update. Simply submitting stuff causes problems as there are many users on the system and all of us know little bits here and there.

 

[N7YUO]

Jim202 and BNeilson are both correct. In the database: Utah>/trunked systems>Utah Military, the talk groups are odd and even (divisible by 16). The Utah Communications Agency Network only uses even (divisible by 32) talk groups.
I prefer to discuss these issues here in the Utah forum and if we get agreement, I let someone else make the change. I am not comfortable messing with the DB or the Wiki.

 

[bchris]

If I were setting up a new MOT system, I COULD start assigning TGs at 16, then count in multiples of 16, ie: 16, 32, 48, 64, 80, 96, 112, 128. These are all valid TG #'s on a Motorola system.

On the Utah system they started at 32, then counted in multiples of 32, ie: 32, 64, 96, 128. All these #'s are still multiples of 16 and 32. All are valid #'s, but there are only half as many. If Utah runs out, maybe they will start to use every other /16 that they had previously skipped. At least the #'s within each agency could remain grouped together if desired.

Maybe your system ends up with the decimal TG coming out with an even number. The system
I just looked at the numbers come out with a xxx.5 when divided by 32. I know the system HEX
numbers are correct. So now explain to me why the xxx.5 number comes up and not an even
number as you claim it should.

Jim

If ALL the TGs on the above system are xxx.5 when divided by 32, then they must have started with 16 and then counted by 32, ie: 16, 48, 80, 112. If only SOME of them are xxx.5 and the others are xxx.0, they are using all the multiples of 16 (although surely they are not all assigned and in use yet). Any of these strategies would still result in valid MOT #'s.

It seems like I read some Motorola literature a while back that indicated the 5th binary bit on a type II system could be used alternatively as a status indicator, along with bits 1-4, or it could be used as part of the TGID along with bits 6-16 . If this is true it would sure explain a lot.

--bc

 

[N7YUO]

Maybe your system ends up with the decimal TG coming out with an even number. The system
I just looked at the numbers come out with a xxx.5 when divided by 32. I know the system HEX
numbers are correct. So now explain to me why the xxx.5 number comes up and not an even
number as you claim it should.

Jim

Even and Odd TGs, The Motorola TGs begin this way:
first 16
second 32
third 48
fourth 64

The first, third, fifth, etc are odd.
The second, fourth, sixth, etc are even. UCAN uses all even TGs.

 

[JoeyC]

The second, fourth, sixth, etc are even. UCAN uses all even TGs.

until they run out...

nonetheless, the correct way to determine if a talkgroup is correct on a Motorola type II system is even division by 16.

 

[theaton]

Ucan tg 42880

Thanks for catching this N7YUO. I changed the TG# and also modified the description to better fit Junior1970's explanation.

Luckily I do monitor here on occasion.

-Tim

TG 42880 is Utah County Countywide C2C 2. They don't use it much but it is in the county radios as Ch 7.Other agencies have the Tg in a different place hence the labeling as UTCO CWC2C 2.

 

[kf7yn]

One great feature of Trunker is that you can look through all TGs and see which ones have been active over the entire period you have had it. I started running Trunker in the late 90's when SLC first started using 800 MHz. And since 2000 when UCAN started putting the system on the air. I show a few TGs that were logged in 2000, 2001, 2002 that have not been heard at my location since. Some of those were "odd" TGs that were erroneously assigned by UCAN and later corrected.

That still happens every once in awhile, I logged a few in the last year that fell in between legit TGs, Maybe just testing or erroneous assignment, who knows. But we do know that UCAN's legitimate TGs are "even" (divisible by 32). That pattern is easily verified logging TGs all the way back to the beginning.