Determining Motorola Type I Fleetmaps

By Dave Goodson

Feb 04, 99

The following process provides a methodical approach for determining the proper fleet map for use by Trunktracker radios. An example illustrating the method is presented at the end of the article.

1) Verify you have the correct and complete set of FREQUENCIES programmed for the system you are investigating (missing frequencies can contribute to dramatically confused results).

2) Make sure you "UN-lock" any and all talkgroups you have previously "locked out".

3) Start by programming all blocks for Type II (Size code S0). (NOTE: all references to idís that follow refer to the value displayed by the Trunktracker with size code set to zero.)

4) With pen and paper handy, set the radio to SEARCH (while "trunking") and start listening

5) Write down the different id's you hear, and try to note which id's seem to relate to the same conversation/talkgroup. If you consistently hear all parts of the same conversation on the same talkgroup id number that talkgroup is almost certainly Type II. If different parts of the same conversation/talkgroup show up on different (but usually nearby) id's, then you are almost certainly dealing with a type I talkgroup.

6) The Trunktracker has 8 blocks of id's, numbered 0 through 7. Each block contains exactly 8192 id's. Each block is individually programmed for the type of talkgroup it contains (i.e. the size code). By inspecting the id values you have recorded above, and referring to Table 1, you can determine which of the 8 blocks the talkgroup belongs to. You can not mix type I and type II talkgroups within the SAME block. Therefore, once you determine that a talkgroup within a block is type I you can be sure that all talkgroups in that same block are type I.

Block Lower ID Upper ID

























Table 1, Ranges of id's in each of the Trunktracker's 8 blocks:

7) After establishing that a block is Type I, the next step is to determine its specific structure (i.e. picking the right "size code" for the block). Make a diligent effort to note the various talkgroups id's that relate to the same conversation. For simplicity, it is easiest to focus on one block at a time, and easiest to monitor an active talkgroup. As you collect the id's for a talkgroup, subtract the smallest number id from the largest number id (that is part of the same conversation) and the difference tells you that AT LEAST that number of radio users are part of this particular talkgroup.

Take this number, and compare it to the values in the first column of Table 2. This column lists the maximum number of users in a talkgroup for various size codes. The number of actual users you have monitored must be smaller than the allowable maximum number of users per talkgroup; that is, the proper size code cannot be one with a smaller number of maximum users than you have actually monitored. From Table 2 you can narrow down the choice for proper size code, but cannot yet isolate it to an exact match.

Maximum number of users per Talkgroup Number of Talkgroups per block Applicable Size Code
16 512 S1
32 256 S5, S6
64 128 S2, S7
128 64 S3, S8
256 32 S9, S10, S11
512 16 S4
1024 8 S12
2048 4 S13
4096 2 S14

Table 2; Maximum number of users per talkgroup for various size codes.

8) You can further narrow down the proper choice for size code by applying some intuition and logic. First, the use of size codes S12, S13, and S14 are rare since few agencies require such large talkgroups. Be skeptical of results that point towards a size code of S12, S13, or S14. For similar reasons you can usually rule out the size codes which can accommodate only a small number of users per talkgroup, such as S1, S5/S6, and S2/S7.

The most common talkgroup sizes are those which accommodate 128, 256, or 512 users.

A final tip is that most systems are designed to allow growth and expansion. If your results from step 7 were, for example, 115 users, though S3 with 128 maximum would work, it is more likely that the best answer is S11 (or possibly S4) to allow room to grow.


9) For a suspected talkgroup size of 128 users, you can use EITHER size code S3 or S8 with exactly the same performance; similarly, for a talkgroup size of 256 users you can use S9, S10, or S11. It seems to this writer that the preference in common usage is to use S3 for size codes with 128 users and S11 for size codes with 256 users.

Given all these points, three size codes emerge which are by far the most commonly used, S3 (128 users), S11 (256 users), and S4 (512 users). The list of potential size codes to contend with has been reduced from the fourteen listed in Table 2 to only these three that serve well for most systems.

(Warning: granted, the resulting talkgroup number displayed by the Trunktracker will usually be different depending on exactly which size code you use (such as S9, S10, or S11), which one is "the right one" is arbitrary. One significant subtlety is that if you start exchanging talkgroup info with a friend, make sure you are comparing talkgroup numbers derived for the exact same value of size code number.)


# # #

The steps provided to this point are often all that need be performed to successfully guess the proper size code for a given block. The sequence is simply repeated for each of the eight blocks until each specific size code has been derived. As each block is "conquered", it is helpful to temporarily lock out the talkgroups in that block to minimize delays in finding ids in other blocks.

If you program a type I block with a size code of S3 (allowing 128 users), but continue to occasionally hear parts of the same conversation on adjacent talkgroups, your S3 code is likely still too small and you can simply change it to S11 to allow 256 users.

The method to this point is fairly simple, and generally will narrow the size code choices to two or three that can be tried by trial and error until satisfactory results are obtained. The following step is more involved but provides additional insight into the structure of a block to further isolate and confirm the exact size code. It also helps to confirm the results obtained, rule out size codes that are "too big", and predict where talkgroups should occur within the block.

10) Once you have accumulated a list of talkgroups ids, determined from Table 1 which block you are dealing with, and made a prediction of the talkgroup size, you can manually map the idís into talkgroups within the block to determine if your findings are consistent with your predicted size code.

Close inspection of Table 2 shows that the number of users per talkgroup multiplied by the number of talkgroups per block is always 8192. Thus, if you suspect, for example, that a block is composed of talkgroups of 128 users, you can conclude that there are exactly 64 of these talkgroups in the block (since 128 x 64 = 8192). (The number of talkgroups per block is provided in the middle column of Table 2.) In such a block, "the first" talkgroup would occupy the first 128 id's of the block, "the second" talkgroup would occupy the next 128 id's, "the third" talkgroup would occupy the next 128 id's and so forth. "The last" talkgroup (in this case the 64th) would fit exactly into the last 128 id's of the block.

Consider block 4 as a specific example. You can easily list the id limits of each talkgroup as follows. From Table 1 the lower limit (i.e. the first id of the block) for block 4 is 32768. Accordingly, block 4 talkgroup 1 would range from 32768 to 32895 (32768+127), talkgroup 2 would range from 32896 to 33923 (32896+127), talkgroup 3 would range from 33924 to 34051 and so forth.

With the "range" of individual talkgroups listed, you can easily verify if the id values you have recorded fit appropriately into the logical talkgroup structure. That is, id's participating in the same talkgroup should fall within the limits of a common talkgroup and id's not involved in the same talkgroup (i.e. the dogcatcher and the fire department) should logically fall into separate talkgroups. By inspecting how the id's you have noted fall into the talkgroups, you can gauge if your talkgroup size is too small, too large, or just right!


Suppose, after monitoring a system for a few minutes, you note that a police department "dispatch" calls units on id 16396, "car 44" answers on id 16385, "car 46" answers on id 16543, "car 38" answers on id 16429. When you hear car 38 switch to a car-to-car channel, car 38 shows up on id 16676 and talks to his buddy in car 33 who answers on id 16721. You also hear an ambulance on id 17934 giving a medical report to a hospital that answers on id 18110. Further, what sounds like public works conversations occur on id 9680, and all parts ("both sides") of the conversation appear on this one id.

What's it all mean?

From these findings you can conclude:

  1. The public works units are in block 1 and are type II; therefore block 1 must be type II/size code S0. (Reason: 9680 falls within the range of block 1 listed in Table 1, and since both sides of the conversation consistently appear on the same id number the talkgroup is Type II.)
  2. All the other id's in this example are in block 2 which is Type I. (Reason: all the id's fall within the range of id's for block 2 listed in Table I, and since different participants in the conversation fall on different id's, the talkgroups are Type I.)
  3. Even though it appears you have notes from three different talkgroups in block 2 (the main police channel, the police car-to-car channel, and the ambulance/hospital channel) you can determine that the number of users per talkgroup in block 2 is at least 176. (Reason: assuming the police-related id's and the ambulance/hospital id's are different talkgroups, the maximum spread between any noted id's related to the same talkgroup is 176. For the main police talkgroup the max id-min id =16543-16385 =158; for the police car-to-car channel the max id-min id =16721-16676 =45, for the ambulance/hospital talkgroup, the max id-min id = 18110-17934 = 176; always take the largest of the values which is 176. From Table 2, the possible size codes that allow 176 users are those with 256, 512, or more users; therefore size code which have a maximum of less than 256 users can be eliminated from consideration.
  4. By applying the mapping technique of step 10, for block 2 with a talkgroup size of 256 the first talkgroup ranges from 16384 through 16639, the second talkgroup ranges from 16640 through 16895, the third from 16896 through 17151 and so forth (for 32 talkgroups). Using this partitioning, and applying the ids from the collected notes indicates that for this size code (i.e. 256) the main police channel "fits" into talkgroup 1, the police car-to-car channel fits into talkgroup 2, and the ambulance/hospital talkgroup fits into talkgroup 7. IF the same technique were applied for a size code of 512, talkgroup 1 would extend from 16384 through 16895, talkgroup 2 from 16896 through 17406 and so forth. In this scheme, the id's for both the main police channel AND the car-to-car channel all fall within the limits of talkgroup 1, which would mean the two police channels would in fact have to be one and the same. Since we know from monitoring this is not the case (i.e. the two channels serve separate functions) we can conclude the talkgroup size is not 512 but that 256 gives a much better (and apparently perfect) fit. From Table 2 we can conclude that a size code of S11 (with 256 users) is the right size code for block 2.