THE FOLLOWING WAS POSTED TO THE SCAN-L LISTSERVER
BY GREG KNOX, THE PERSON WHO DEVELOPED THE PROGRAMMING USED BY
THE UNIDEN 235XLT TRUNKTRACKER. It was then posted on a newsgroup,
where I got it.
Trunktracker displays Motorola talk group IDs as decimal values. It was not possible to make a 7 segment LCD character, gracefully handle the alphanumerics that would be required for a HEX display.
If you want to convert the decimal value displayed
by the scanner to its equivalent Motorola talkgroup value, divide
the decimal value by 16 and convert the result to a 3 place (leading
zeroes may be required) hexadecimal result. Some examples:
Trunktracker Motorola
---------------------------
16 001
32 002
48 003
496 01F
1040 041
2416 097
11536 2D1
12880 325
65520 FFF
Note that this assumes that the decimal value is an integral multiple of 16. This should be the case for a Type II group ID. If you've got a system with lots of even and odd IDs then you probably need to set your fleet map up as a Type I or Hybrid System.
If you want to go in the other direction and convert the Motorola hex value to the Trunktracker value, do this: Convert the hex value to decimal and then multiply the result by 16. Don't add any leading zeroes here.
Some examples:
Motorola Trunktracker
hex dec mult
------------------------------
003 = 3 *16 = 48
07D = 125 *16 = 2000
097 = 151 *16 = 2416
AB9 = 2745 *16 = 43920
FFF = 4095 *16 = 65520
********************************************************************
The patent(s) pertaining to TT have not yet issued. Therefore you will find nothing on them from the patent office. The patents listed on the TT box refer to other scanner related stuff. I can tell you for sure that there will be no actual CPU code shown in the TT patent(s).
*************************************************************
>I am occasionally getting multiple group IDs for the same talkgroups >on some of the local SMRs. For example, a particular talkgroup on
>Kodak's system will show up as 47703 (most often) or as 47692, 47661,
>47691, 48215, or 48152. All of the IDs correspond to the same group
>of units and sometimes occur during the same conversation.
-----------------------------------------
This means that you have defined a Type II fleet map for a system that is either a Type I or Hybrid (Type I and Type II) system. Here's an answer I sent to another user regarding the mixing of Type I and Type II IDs in the same system. Perhaps it will answer some questions for others. It's possible that there are a few Type I radios lurking in your system. If so, one or more of the 8 blocks will be designated as Type I blocks. In this case you have a Hybrid system, and it may be either a mix of Type I and Type II or Type IIi. Type IIi is where the radios transmit a Type II ID to the site controller but the controller looks up the Type II ID in a database and then format and transmits a Type I OSW reflecting the Fleet-Subfleet affiliation (not Talk Group affiliation, which is associated with Type II radios), of the requesting radio. These radios and their IDs appear as, and are treated as, Type I IDs by the mobile units. It really is only of academic interest to the user which of these radio Types, (I or IIi) actually generated the channel grant, it's all the same to the BC235.
If there are Type I radios on your system it appears that they are not often used, as the IDs you posted were all Type II IDs. In general, you can identify a Type II system by the predominance of IDs which are integral multiples of 16. A pure Type I system will have an equal mix of both even and odd IDs. (This assumes you have "defined" the system as a Type II system). Even a pure Type II system will occasionally display some none Type II appearing IDs. These can be a number of things: A "patch" where two or more Talk Groups are "connected" together, an emergency button activation by a radio user, a digital (DVP etc.) encoded talk group, and other stuff I don't know about. If you are seeing a number of Type I IDs interspersed within what you know to be Type II IDs you will want to determine what block(s) the Type I IDs are in. Try this: divide the Type I ID by 8192, discard the fractional part. This will tell you what block the ID is coming from. Do this for several of the IDs across the range of IDs you are seeing so that you are sure you've got all the Type I blocks. There might be more than one. After you figure out which blocks seem to be Type I, reprogram the fleet map to make these blocks one of the Type I size codes. S3 or S4 are good ones to start with. Make all the other blocks Type II, (S0). Now pay attention to the Type I conversations, and see if you are hearing all the replies, (make sure you have Delay On). If so you're all set. If not, try a different size code and repeat. You think this is a pain? You should have seen the first cut at this fleet map assignment thing. It required you to determine not only the size code, but the starting ID of the Fleet-Subfleet, major aggravation!
Even with what I consider to be the simple current method of setting up the fleet maps, I expect to hear lots of complaints. But there's no way around it. The radio (even Motorola's) must know this information to parse the OSW information.
**********************************************************************
On another note, I keep seeing questions come up regarding whether or not TT needs all the system output freqs. to work correctly. The answer is yes. First of all, it does not matter to TT if you have locked out any or all of the frequencies in a trunking bank. In trunking mode the lock out
flag is ignored by the radio. Therefore, claims such as "I locked out everything but the data channel and TT still worked." are meaningless. If you are missing ANY output frequency
actually used by the system you will miss part or all of some conversations. Any talkgroup assignment made to a freq. not in the trunking bank for the system you are listening to will not be seen at all.
Such assignments are ignored by the radio. Notwithstanding the fact that Motorola's radios only need the data channel frequencies, TT must have ALL the output frequencies.