Motorola Type II

Motorola Type II refers to the second generation Motorola Trunked radio systems that replaced fleets and subfleets with the concept of talkgroups and individual radio IDs. There are no dependencies on fleetmaps, therefore there are no limitations on how many radio IDs can participate on a talkgroup. This allows for greater flexibility for the agency. When scanning Motorola IDs, each Type II user ID appears as an even 4- or 5-digit number without a dash (example 2160).

With the introduction of Type II, the System ID was also introduced. This is a 4 digit identifier that is unique to each trunking system. The purpose of the System ID is to allow radios to operate only on that specific system, and to identify each system. The System ID also allows for enhanced security because a radio now requires a System Key, unique to the System ID in order to be programmed onto any given system. Type I systems do not use unique System IDs, thus the possibility exists for overlapping coverage in busy areas.

The term SmartNet refers to a set of features that make Motorola Type I and II trunked systems APCO-16 compliant. These include better security, emergency signaling, dynamic regrouping, remote radio monitoring, and other features.

The following is true of a Type II SmartNet system:

• Up to 28 system channels
• Up to 65,534 unique radio ids
• Up to 4,094 talkgroups
• Use of odd-numbered talkgroups
• Priority Scanning of talkgroups

Status Bits

Type II SmartNet systems uses status bits for special transmissions such as Emergency, Patches, DES/DVP encrypted transmissions, and Multiselects on Motorola Trunking systems. Motorola Trunking radios directly interpret these status bits for their special functions, therefore no difference is noticed by the user. The Trunktracker Scanner, however, interpret these special talkgroup status bits as different talkgroups entirely. Below is the conversion chart for these special status bits:

Dec ID + #         Usage
-------------------------------------------------------
ID+0            Normal Talkgroup
ID+1            All Talkgroup
ID+2            Emergency
ID+3            Talkgroup patch to another
ID+4            Emergency Patch
ID+5            Emergency multi-group
ID+6            Not assigned
ID+7            Multi-select (initiated by dispatcher)
ID+8            DES Encryption talkgroup
ID+9            DES All Talkgroup
ID+10           DES Emergency
ID+11           DES Talkgroup patch
ID+12           DES Emergency Patch
ID+13           DES Emergency multi-group
ID+14           Not assigned
ID+15           Multi-select DES TG

Therefore, if a user was transmitting a multi-select call on talkgroup 1808, the trunktracker would actually receive those transmissions on 1815. Some common uses of these status bits are as follows:

• When a user hits his emergency button, all conversations on the talkgroup revert to the emergency status talkgroup (ID+2) until the dispatch clears the emergency status. Therefore, if someone hits his emergency button and his radio is on talkgroup 16, all communications will switch to talkgroup 18.
• When an emergency is declared, the system automatically strips any patches present on the talkgroup and places the talkgroup in emergency with +2 and any patched talkgroups as a Multiselect (+7) with the console repeating subscriber audio from the talkgroup in emergency.
• A lot of Fire and EMS departments dispatch tone-outs and alarms as Multi-select communications (ID+7). Therefore, if your fire department dispatch talkgroup is 1616, and it does dispatch tone-outs and alarms as Multi-selects, those communications will be on talkgroup 1623.

This can be a problem, because you will miss communications if you don't have those talkgroups programmed. By setting the Type II block you are monitoring with a fleetmap of S-1 (Mot Size A), you'll essentially get Type I subfleets for each Type II talkgroup - encompassing all of the status bits into one subfleet. Some scanners also allow you to disable the status bit information so that you will always see the ID+0 regardless of the status of the talkgroup.

SmartNet systems also added a scanning feature, called "Priority Monitor," which permitted priority scanning of talkgroups. The subscriber radio has the choice of selecting two priority talkgroups (one high and one low priority in addition to eight non-priority talkgroups). When the radio is in the middle of a voice call it is continually receiving sub-audible data on the voice channel indicating the talkgroup activity on the other channels of the system. If a talkgroup ID appears which is seen as a higher priority than the active call, the radio will switch back to the control channel to look for the late entry data word indicating which channel to tune to.

This voice channel sub-audible datastream has a limitation in the number of bits it can use to represent a talkgroup ID. Because of this the last digit of the talkgroup ID (right-most) is removed. The radio then presumes any ID it receives is an odd-numbered talkgroup ID. This is the reason behind odd numbering of talkgroups on SmartNet systems. If the systems administrator assigned odd AND even numbered talkgroups there would be a lot of confusion with the Priority Monitor feature when reading the data over the voice channel. This was a problem with the Radio Shack PRO-92 as it used only the sub-audible data to track trunked systems.