Motorola Type II Smartnet
From The RadioReference Wiki
Trunked Radio Systems → Motorola Type II → Motorola Type II Smartnet
Motorola Type II Smartnet is a 2nd generation Motorola Trunking system. 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 65534 unique radio ids
- Up to 4095 talkgroups
- They use odd numbered talkgroups
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 |
Type II Smartnet systems uses status bits for special transmissions such as Emergency, Patches, DES/DVP scrambled transmissions, and Multiselects on Motorola Trunking systems. Motorola Trunking radios directly interpret them for their special functions, thus no difference is noticed by the person with the radio. The Trunktracker scanners however interpret these special talkgroup status bits as different talkgroups entirely. To the right is the conversion chart for these special status bits.
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 their 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 hit their emergency button and their radio was on talkgroup 16, all communications would switch to talkgroup 18.
- 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 they do dispatch tone-outs and alarms as Multi-selects, then 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 alwys 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 pops up which is seen as a higher priority to 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 adminsitrator 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. With the early versions of the Radio Shack PRO-92 you saw this trouble as it used only the sub-audible data to track trunked systems.