Database Administrator Handbook Live Version

Tom Swisher, Lead Database Administrator and Manager

Introduction

First and foremost, thank you for volunteering your time to be a RadioReference.com (“RR”) database administrator. The RR database is the heart of RadioReference.com and your efforts help us maintain a high quality and very valuable resource to our user community. This handbook is intended to outline “everything you need to know” to be an effective RR database administrator. If you have any questions about anything that is not covered in this handbook, just ask. This handbook is intended to be a “living document” so please feel free to suggest additional topics for inclusion.

Responsibilities

As an RR database administrator, your responsibilities include:

• Following the requirements, guidelines, policies and procedures outlined in this handbook.
• Working as a team with your fellow administrators.
• Regularly logging-in to the RR web site to check the administrator forum and pending submissions.
• Promptly working any incoming submissions.
• Monitoring the “Database Administrator” RR forum.

Policies

Privacy

All administrators are responsible for following the RadioReference.com Privacy Policy. The complete privacy policy may be found on the RadioReference.com web site. In summary, administrators must never share any personal information about any user with any other person under any circumstances. Specifically, requests from other users to know “who submitted X” shall be politely declined. Furthermore, contact information for any user may not be shared. Any requests for personal information shall be redirected to RR’s President.

Data Removal

Valid and confirmed data of any kind shall never be removed from the database. RadioReference.com does not honor requests to remove information unless required by court order. Exceptions to this policy will only be granted by RR’s President.

Administrator Identity

All RR database administrators are required to include their real name, a valid e-mail address and current mailing address in their RR profile.

Professional Behavior

All RR database administrators are representatives of the RadioReference.com organization and are expected to exhibit professional behavior in all of their RR-related activities, including forum posts, even when they are not specifically acting in their capacity as an administrator. Administrators shall not provide information that could allow or encourage unlawful behavior by others.

Administrator Selection

There are no rigid rules with respect to the selection of new database administrators. New administrator applications are evaluated by the Lead Database Administrator and Manager based on a number of criteria and a decision is based on a combination of factors. The following items are among the factors considered:

• Content of the database administrator application form.
• Length of time as a RR member.
• Forum participation (volume and quality).
• Submission history (volume and quality).
• Existing geographic coverage and geographic diversity.
• Opinions of any existing administrators in the relevant geographic area.

Database Entity Naming

The RR database entities (e.g., frequencies, talkgroups, categories, subcategories, descriptions, alpha tags, etc.) shall never be added, removed, named, renamed or changed to adjust them for a specific device, product or consumer of RR data.

It is not acceptable to attempt to work-around bugs in third party devices or products by modifying the RR database. Bugs in third party devices or products that occur due to incomplete or incorrect usage of RR data shall be reported directly to the third party device manufacturers.

Getting Started

First Things First

If you are a new database administrator reading this handbook for the first time, please take a moment to post a new thread in the “Database Administrator” forum introducing yourself as a new administrator for your assigned area.

Database Administrator Functionality

The database “Admin Home” is your starting point. As an administrator you have access to this restricted area of the RR database. You will find a link to this page under the “Database” menu at the top of the RR web site. (You may also access administration features from conventional or trunked pages by clicking the “Admin” link in the tab-based menu.)

On the “Admin Home” page you will see a list of all submissions for the geographic area to which you have been granted access. You shall process submissions that are visible to you as soon as possible. If you share administration responsibilities for a geographic area with other administrators, be sure to introduce yourself to your fellow administrators and coordinate your efforts.

On the “Your Queue” page, you will see a list of any submission that you have currently “owned” or have “worked” in the past.

The “New TRS” page may be used to create a completely new trunked system in the database. Please be sure to check that the system does not already exist in the database before creating a new system.

The “Staged TRS” page shows you a list of all trunked radio systems with a display status of “staged.”

The “Admin Team” page shows you a list of all database administrators and their areas of responsibility.

The “Problems” page presents a set of reports that are used to facilitate cleaning-up missing or incorrect data in the database.

Bugs and Features

If you encounter a bug or have an idea for a new feature, you should log the issue in the “Mantis” issue tracking system.

https://mantis.radioreference.com

Access Control

Each database administrator is granted access to specific portions of the RR database and access within the database is controlled by geographic area. Administrator access to a given portion of the database allows an administrator to directly add, edit and delete information in that portion of database as well as access user submissions within the same geographic area.

“Global” administrators have access to the entire RR database. Global administrators are the only administrators with the ability to add or edit “Nationwide” frequencies. Non-global administrators may be assigned access to any combination of the areas of the database consisting of the following levels:

• State/province
• County
• Trunked radio system

Please note that state-level administrators do not have access to multi-state trunked radio systems when the system is also assigned to a state to which the administrator does not have access. State-level administrators in this situation must be granted access directly to individual multi-state systems in order to access them.

Submissions of new trunked radio systems are only visible to “Global” administrators. Global administrators will typically create the new trunked radio system at which point the appropriate local administrators may take over ongoing maintenance of the system.

Processing User Submissions

Receipt of Submissions and Data Sources

Submissions are usually received from users who have clicked on a Submit tab somewhere in the database, and will appear in the Open Submissions queue on the Database Administrator page. Administrators may also "mine" the forums for confirmed data, but must submit that data following the normal procedure for that county/system, and give due credit in the submission to the member who originally posted the data. Submitted data may be used as long as it has been confirmed by the submitter through over-the-air monitoring. Data obtained directly from the FCC database is not permitted, nor is data obtained by "mining" other web pages (unless permission is obtained from the owner of the web page).

Some submissions may include radio programming data extracted from programming files commonly known as "codeplugs" or "personalities." This data may be used under the following conditions:

• Frequencies and sites must be confirmed by monitoring to avoid conflicts with existing systems.
• Talkgroups do not "pre-date" information already in the database. Where talkgroups already exist in the database, an effort must be made to verify whether the database data or the codeplug data is the most recent and up-to-date.

How To Process Submissions

Before processing any submission (to include requesting clarification from the submitter via submission note, private message or email), first click the “Own” link on or next to the submission. “Owning” a submission is the way that a submission is assigned to an administrator so that more than one administrator does not try to process a submission at the same time. Submissions shall remain “owned” for only the brief period of time while you are updating the database and while actively engaged in direct follow-up with the submitter. Do not “hoard” or “sit” on submissions; a holding period of up to 30 days is permissible if clarification of the information is needed, but if no response is received the from the submitter the submission must be rejected or released.

Before “owning” any submission, global database administrators shall allow at least one week to pass from the date of the submission before owning a submission. This permits local-area administrators with more familiarity of the local area to pose pertinent questions to the submitter if clarification is needed prior to working the submission.

When an adminstrator has personally-verified information or information gleaned from a forum post to add to the database, it shall be submitted following the normal submission process and worked as a normal submission. In the case of information gleaned from forum posts, a note shall be added in the body of the submission indicating the source forum and original poster of the information. Clerical tasks such as spelling corrections or format edits need not be submitted.

Once the data has been entered into the database (assuming it meets the criteria for inclusion in the database), the submission shall be marked “worked” (i.e., it is complete). Click the “Set Worked” link to mark the submission as complete. You will be prompted to rate the submission (“Poor,” “Good” or “Outstanding”). This rating is used to compute an average rating for each user to help evaluate the overall quality of each user’s submissions. “Good” is the default. Use “Poor” if the submission is low quality or only partially usable. Use “Outstanding” if the submission is extremely valuable and submitted in an easy way for you to process. If the submission is completely unusable or irrelevant, click the “Reject” link instead of “Set Worked.” You must enter a brief explanation of why the submission was rejected. Please place “unstructured” data in the wiki; do not “reject” these submissions.

When an administrator sets a submission to “worked,” the user receives an e-mail notifying them that the submission was set to a completed status. Administrators have the ability to add a note to a submission which will be e-mailed to the submitter for follow-up. Users may add notes to their own submissions as well. If a submission is “owned,” then the owning administrator will receive an e-mail notification of the note being added. If a submission is “rejected” then the submitter will receive an e-mail with the reason for the rejection.

User Submission History, Rating and Notes

To view a user’s submission history and rating, click on the user’s username in the submission pop-up window. You will be able to see the user’s recent submissions, the average submission rating and notes. You may also look- up a user directly by clicking the “Query” button on the “Admin Home” page and entering the username in the “Retrieve Username Info” field. Notes are used for administrators to leave comments for themselves and other administrators about a user. Notes are most commonly used to keep track of users who consistently and/or deliberately submit bad data.

Database Organization

General

The goal of the RR database is to catalog accurate, confirmed data contributed by our vast group of users. “Unidentified” data is specifically to be excluded from the database. The database is not intended to be a collection of notes or guesses – please use the forums and wiki for this type of collaboration. Entries in the database do not necessarily have to be specific with respect to their identification (although this is ideal) but they may not be completely unspecified. For example, a talkgroup on a business trunked system is considered “identified” if it is known to be “private security” or “ambulance service” (for example) even though the exact name of the business may remain unknown. “Operations” is not a confirmed description unless “operations” has specific meaning within the scope of the associated agency or business.

Included Data

In general, the RR database is intended to include almost all conventional and trunked radio data spanning the approximately 30 MHz to 1 GHz range of spectrum. Frequencies and talkgroups must have a confirmed description (i.e., they must be identified) to be included in the database. Include unidentified or unconfirmed data in the relevant portion of the RR wiki instead. The following data is specifically intended to be included (this is not intended to be an exhaustive list) except data specifically listed in section 6.1.2 (“Excluded Data”):

• Public safety agencies
  • Police
  • Fire
  • EMS
  • Emergency management
  • Local government agencies and services o Homeland security
  • Federal agencies
  • Military
• Transportation carriers
  • Aircraft/airports
  • Railroads (passenger, freight and tourist based operations)
  • Seaports
• Public attractions
  • Amusement parks
  • Theme parks
  • Public parks
• Businesses
  • Dedicated business land mobile radio services
  • Shopping malls
  • Industrial facilities
• Amateur radio
  • ARES
  • RACES
  • Skywarn
  • Emergency management/homeland security
  • Beacons
  • All amateur radio repeaters
  • Any other amateur radio frequencies

Excluded Data

The following data is specifically to be excluded from the RR database:

• Fast food restaurants
• HF (frequencies below 30 MHz) – this information shall be included in the relevant area of the RR wiki. Frequencies between 25-30 MHz may be included in the database provided they are specifically used for typical land mobile-type operations, in a mode commonly used by land mobile users (FM, NFM, P25, etc).
• Temporary, non-recurring use frequencies, e.g., frequencies for special events – this information shall be included in the relevant area of the RR wiki (note: regularly recurring special events frequencies may be included in an appropriate “Events” agency page in the database)
• Miscellaneous “unstructured” data – this information shall be included in the relevant “collaboration” area of the RR wiki (which is linked from the database via the “Wiki” menu option on county and agency pages). “Unstructured” data includes:
  • Unit numbering schemes
  • Dispatch codes, 10-codes, status codes, signal codes, disposition codes, terminology o District and patrol zone maps
  • Channel plans
  • Fire/EMS station lists
  • Fire/EMS pager tones
  • Lists of agencies participating in mutual aid organizations
• Any extraneous information not directly related to radio monitoring, e.g., text and images (including badges, patches, logos, etc.) that provide general information about an agency – please use hyperlinks on the RR wiki collaboration page to refer users to outside sources of related information.
• Any unconfirmed data – do not use the database as a “scratch pad” for miscellaneous notes; please use the forums and wiki for this type of data.
  • License data is not considered confirmed!
  • A press release about a system being planned is not considered confirmed data!
  • Information such as encryption keys or inversion frequencies that could allow illegal decryption of any communications will not be entered in the database, the Wiki, or the forums, and will be removed if present.
• Private low-power amateur radio "hotspots" for DMR and other digital modes.

Please note that names of specific people using a radio system shall not be posted, in the database or in the Wiki.

Abbreviations

Always avoid using abbreviations throughout the database to ensure clarity for all users. “EMS” is acceptable as an abbreviation wherever it is appropriate. When abbreviations are used, they must be defined. For example, a trunked system shall be named “Southeast Texas Area Radio Network (STARNET)” not simply “STARNET.” Abbreviations shall be placed in parentheses after the full name as shown in the previous example. Abbreviations shall be entered in all capital letters and without any punctuation. For example, “STARNET” shall be used, not “S.T.A.R.N.E.T.” Except for abbreviations, words shall never be spelled in all capital letters anywhere in the database. Please note the proper capitalization of the following abbreviations which are sometimes capitalized incorrectly:

• kHz – kilohertz (please note the lower case “k”)
• MHz – megahertz
• GHz – gigahertz

A single space character shall always precede any abbreviation. For example, use “850 MHz” (not “850MHz”).

When abbreviating the word “channel” the appropriate abbreviation shall be “Ch.” and it shall be followed by a single space character, e.g., “Ch. 5.” Do not use any other abbreviations for “channel” (e.g., “CH 5,” “CH-5,” “Chan. 5,” “F-5”).

Do not use ampersands anywhere in the database.

Naming Conventions

Always name an agency, category, subcategory or trunked system with the clearest, most specific name that is appropriate. When naming government entities, the official name as determined by the government shall be used. Do not include extra information such as to what department the entity organizationally belongs. Per the previously stated policy, abbreviations shall be avoided.

Naming Conventions For U.S. Federal Entities

Bureau of Prisons entities shall be named using the official facility name. Please note that the proper name is “Federal Correctional Institution Cumberland” (not “FCI Cumberland” or “Cumberland FCI” or “Cumberland Federal Correctional Institution”). Consult http://www.bop.gov/locations/index.jsp if you are unsure of the facility name.

Military facility entities shall be named with the official facility name. Navy facilities have names that cause confusion like the BOP systems, so use “Naval Air Station Alameda” (not “NAS Alameda” or “Alameda NAS” or “Alameda Naval Air Station”). Use “Johnson Space Center” (not “NASA Johnson Space Center”). If you are tempted to use a colon or an abbreviation then that should be a red flag to you.

Frequency and Talkgroup Descriptions

Talkgroup and frequency descriptions shall be kept short and informative (50 characters or less) while avoiding exact duplication with other fields where possible. Channel numbers should be included when known. For example:

• Where an alpha tag states “PD DISPATCH 1” use “Police Dispatch 1” in the Description.
• Common operating channels shall be shown as “Countywide Common 1” or “Law Interop 1” rather than just “Countywide Common” or “Law Interop” in the Description field.
• Category or Subcategory headings or names will not be shown or duplicated in the Description field.

Site Names

Tower site names shall reflect the actual site name as used by the system, if known. If the actual name does not reflect the nearest local town or municipality, the name of the nearest hamlet, town or municipality shall be added in parenthesis after the site name; for example, "Big Tall Mtn (Little Teeny City)". Using "Actual Name (Physical Location)" will help prevent confusion when service techs and others refer on air to a site using the official name; giving the actual physical location will aid those with enquiring minds.

If the site name is a well-known feature named on a map, a hamlet/town/municipality name is not necessary.

If the actual site name is not known, the nearest town, municipality or census-designated place shall be used.

Amateur Radio Subcategory Naming Convention and Sort Order

Amateur Radio Subcategories shall be listed in the following sort order:

• 1. Severe Weather
• 2. Emergency (ARES/RACES)
• 3. 10m (29 MHz) Frequencies
• 4. 6m (50 MHz) Frequencies
• 5. 2m (144 MHz) Frequencies
• 6. 1.25m (222 MHz) Frequencies
• 7. 70cm (440 MHz) Frequencies
• 8. 33cm (902 MHz) Frequencies
• 9. 23cm (1240 MHz) Frequencies
• 10. Packet and other local data-only frequencies (excluding standard nationwide packet and APRS frequencies)

If there are no frequencies on a given band in a county, skip that subcategory, but make sure other subcategories use the proper sort number(s) so others can be added later as needed.

Since not all weather groups are part of Skywarn, the name "Skywarn" is not to be used in any subcategory heading, and may only be used for repeaters specifically associated with that organization.

A separate "Severe Weather - Wide Area" subcategory with Sort Order 1 (and the appropriate GPS coordinates and ranges) should be created for severe weather repeaters that are wide-area. Use the subcategory notes to indicate that the XXX repeater covers multiple counties.

The Emergency category is only to be used for repeaters specifically operated by ARES/RACES groups, or the local Emergency Management organization. Regular repeaters operated by other groups which may be used in an emergency shall be listed in the normal repeater subcatgories.

Sort order 11 and up should be used for specific subcategories dedicated to large clubs with more than five repeaters in any combination of frequency bands. The subcategory should be named using the official name of the club, for example "Long Island Mobile Amateur Radio Club (LIMARC)."

Listings are restricted to repeaters only, unless a simplex frequency with a dedicated squelch access is specifically designated for emergency operations in that county.

Any frequencies to be designated as statewide must legitimately cover the entire state, without use of directional antennas and/or higher transmitter power at the user level. Wide area repeaters (those which specifically cover more than one county) must be listed under the county in which they’re located, with GPS radius settings to encompass the specified coverage area.

Conventional Data

Agency Pages

“Agency” pages are the RR database name for sub-pages that are created either at the state or county level within the RR database’s geographically organized hierarchical structure. Agency pages are of one of the following types:

• Public Safety – used for nationwide or state-level public safety agencies
• Federal – any federal frequencies (it is a common practice to create a “Federal” agency page in a county and to place the federal frequencies for that county on that agency page, particularly if there are more than a handful of federal frequencies used in the county)
• Military – any military frequencies (large military bases shall each have their own agency page)
• Attraction – major attractions, such as large theme parks or stadiums located in a specific county (smaller attractions shall be listed as recreational businesses on an appropriate business agency page)
• Aircraft/Airport – always create a separate agency page for each unique airport in a specific county and place all frequencies used on the airport grounds in this agency
• Business – all business frequencies not assigned to another agency (e.g., attraction, utility, railroad)
• Railroad – common carrier railroad frequencies (this agency page may only be created at the state-level)
• Utility – utilities such as electricity, telephone and cable television providers
• Events – regularly recurring special events, e.g., air shows, major sport events, festivals, etc.
• Marine – seaports or other marine-related frequencies in coastal areas
• Misc/Other – used only as a Nationwide agency page for frequencies such as CB, FRS, GMRS, etc. that do not fall under any other agency type
• Interop – used only as a Nationwide agency page for interoperability frequencies
• Amateur Radio – amateur radio frequencies when used on a nationwide or statewide basis

Statewide or Multi-County Frequencies

In general, a frequency with a given usage shall never be entered more than once in the database. Exceptions may be made in limited cases where there is region-specific usage information for a frequency that is otherwise a “wide area” use frequency. Do not duplicate “wide area” use frequencies on multiple county pages.

Frequencies used by any state agency shall be listed on a state-level agency page. State agency frequencies (e.g., state police) shall not be entered on a county page (even if the state police frequency is only applicable to one county). State universities are not considered statewide agencies and shall be listed on the appropriate county page (in general, universities are treated as if they are cities in the database).

Frequencies that are used across multiple counties within a state shall generally be consolidated on a state-level agency page. For example, multi-county mutual aid entities that share frequencies shall be entered at the state- level, not on individual county pages. Don’t make more work for yourself – if it’s used in multiple counties don’t enter it separately in each county!

Federal and Military frequencies shall be treated like any other data; unless a frequency or system is truly regional or statewide in nature, frequencies shall be listed under the county in which the facility in question is located, listed under a Federal agency page for that county. If a Federal or Military facility spans part of two or more counties, the county which contains the majority of the facility shall be considered the "home" county and the GPS range set appropriately.

Railroad Frequencies

Traditional “common carrier” railroad frequencies shall always be entered on a state-level “Railroads” agency page. The state-level page shall be named “Railroads” and shall show the state name as part of the agency name. Railroads are entered on the state-level agency page because it is common for railroad subdivisions to span multiple counties. This design is intended to reduce duplicate entries that would otherwise occur across multiple county pages.

In the railroad listings, each major or regional railroad (CSX, Norfolk Southern, Union Pacific and so on) shall be listed as a separate category. Short-line railroads shall be listed in a "Shortline Railroads" category with each railroad listed as a separate subcategory; separate subcategories may be created for shortline railroads with widely separated service areas. A separate subcategory for a specific county may be created where a large number of short-line railroads exist only within that county.

Major or regional railroads shall be listed alphabetically, and each railroad category shall be comprised of a statewide subcategory (if needed) and divisional subcategories. Each railroad operating division shall be listed in the following order:

• 1. Divisional road and dispatcher channels
• 2. Terminal Areas, with a separate subcategory for each terminal

Each subcategory shall use GPS and range settings appropriate for the coverage area. Division-wide subcategories such as road and dispatcher channels may be broken down geographically (east and west or north and south) if necessary for location and range purposes. Location and range for a particular terminal area would ideally be centered on the area served, with a range around 5 miles, but not exceeding ten miles.

Channel names shall be comprised of the official AAR channel number (ie, "AAR 049"), but additional information may be added to identify specific local usage if necessary. In such a case, the AAR number shall precede the local usage information (for example, "022 Hvy Side").

County-Level Pages

County-level pages are the main pages within the RR database for accessing conventional radio data. All public safety and local government frequencies shall be placed on the county page corresponding to the county in which they are used. Separate “agency” pages shall not be used for public safety or local government information. All data other than public safety and local government data (e.g., businesses, utilities, airports, attractions, etc.) shall be placed on separate “agency” pages under the appropriate county. See section 6.2.4 (“County-level Agency Pages”) for more information on the creation of county-level agency pages.

Smaller counties shall have a single “category” containing “subcategories” for each logical agency within the county. Larger counties shall have several categories (e.g., county, cities, education, etc.) with each containing subcategories for each logical agency. Please see Harris County, Texas, United States in the RR database for an example of how to structure a county page for a large county. Please see Fort Bend County, Texas, United States for an example of how to structure a more typical (smaller) county page.

The following specific rules apply to category and subcategory names:

• The names shall be as concise and short as possible (this applies to categories and subcategories regardless of the type of page on which they appear).
• Subcategory names shall not repeat or duplicate information provided by the category in which it is located (this applies to subcategories regardless of the type of page on which they appear).
• The use of phrases such as “County of,” “City of,” “Town of,” etc. shall be avoided. For example, a county shall appear as “Harris County” and a city shall appear as “Houston.” In cases where disambiguation of a similar city/town/etc. is needed, please place the designation in parentheses, e.g., “Houston (City).”

You should tailor each county page somewhat to meet the needs of each particular geographic area but the general structure and layout of each county page shall generally be consistent from county to county. The county government’s subcategory shall have a high “sort order” value so that it appears at the top of the list in the category. Municipal agencies shall have the same sort order value so that they sort alphabetically below the county agency by default (just use the default sort of “99” to keep things simple). The RR database sorts subcategories alphabetically by default so do not specify an explicit sort order unless there is a specific reason to re-order the list. Typically, a frequency with a given usage shall never be entered more than once on a given county page (do not create more work for yourself by entering the same frequency in multiple subcategories).

Entities that shall appear on the county-level page itself include:

• The county (or parish, etc.) government itself.
• Municipal (e.g., borough, city, town, village, township, etc.) governments.
• Any other miscellaneous municipal agencies, such as utility authorities and independent school districts.
• Universities and colleges.
• Volunteer fire departments and rescue squads.

Do not duplicate shared frequencies on a county page (or any other page). List a frequency once and with the primary agency when possible. When full channel plans are available for an agency, the complete channel plan may be entered in the wiki.

Do not enter "talkaround" frequencies separately when they use the same frequency and squelch as the associated repeater output. Merely make note in the description for the repeater that the frequency is also the talkaround.

County-Level Agency Pages

County-level agency pages shall be used for all data other than public safety and local government services. Administrators shall use discretion in creating agency pages such that only a reasonable number of agency pages are created relative to the amount of data available in a given county. Do not create an excessive number of agency pages; use a reasonable number based on the amount of data in the county (e.g., you would not typically create an agency page to put a single frequency on it). In smaller counties, a single “Businesses” agency page shall be created for all business frequencies; break out businesses into separate agency pages only in large counties (e.g., Retail, Hospitals, Hotels, Media, etc.).

Adding And Editing Frequencies

Output Frequency

The output frequency field is the main frequency field and shall always be included on any conventional database entry. The “output” field shall indicate a repeater output frequency or a simplex frequency. Always enter frequencies with all significant digits; never round frequencies.

Input Frequency

The input frequency field shall be used to indicate a mobile transmit frequency used as a repeater input (type “RM”). If the “output” frequency is simplex, do not enter anything in the input field. Do not include the mobile side of a non-repeated duplex setup in the input field. Two separate frequency entries shall be created for non-repeated duplex pairs, one entry for the base (type “B”) and another for the mobiles (type “M”). The description of each shall clearly indicate whether it is the base or mobile frequency and with which other channel it is paired. These frequency pairs shall be sorted such that they show immediately next to each other with the base frequency listed first.

License

The “license” field shall include the FCC (or relevant foreign agency) license callsign for the indicated frequency if a license is known to exist. If there are multiple applicable licenses, just choose the most relevant license. If the license is expired and there is no newer license, include the most recent expired license. Do not put any other text in this field other than a license callsign (e.g., do not put text such as “expired,” “unlicensed,” “federal”, etc.).

Frequency Types

When adding or editing conventional frequencies, you must specify the “type” which describes how the frequency is used. The types currently supported by the RR database are:

• R – Repeater
• B – Base
• M – Mobile
• F – Fixed

One or more “types” shall be indicated for each frequency entry. The most common entries in the type field are:

• “RM” – indicating a repeater and mobiles/portables
• “BM” – indicating a base station and mobiles/portables (simplex only)
• “B” – indicating a simplex base station only
• “M” – indicating mobiles/portables only
• “F” – indicating fixed transmitters, e.g., fixed telemetry transmitters or point-to-point radio frequency links

Frequency Tones

Subaudible tones and codes are commonly used to help reduce interference from other users of the same frequency. The “tone” field in the RR database provides a location to capture this information. Only output frequency tones shall be entered in the RR database. Do not enter input frequency tones except in the case of Amateur Radio frequencies (where known). If a particular frequency allocation is used with multiple output tones by a single entity, the frequency shall be entered separately in the database for each tone used.

Frequencies using non-standard squelch tones shall be entered as carrier squelch (CSQ) and the non-standard tone added to the Description field. TDMA “slot” numbers shall also be placed in the Description field.

The RR database supports the following types of “tones:”

• Carrier squelch, i.e., no tone, entered as “CSQ”
• Continuous Tone Coded Squelch System (CTCSS), a subaudible tone frequency in Hertz, entered in the format “156.7 PL”
• Digital Coded Squelch (DCS), a decimal code, entered in the format “032 DPL”
• Project 25 Network Access Code (NAC), a hexadecimal code, entered in the format “293 NAC”
• TRBO Color Code, a decimal number, entered in the format “1 CC”
• NXDN Radio Access Number (RAN), a decimal number, entered in the format “55 RAN”

Frequency Modes

When adding or editing conventional frequencies, you must specify the “mode” in which the frequency is used. If multiple modes are used on a given frequency, create a separate frequency entry for each mode with an appropriate description.

The modes currently supported by the RR database are:

• FM, frequency modulation analog voice
• P25, Project 25 digital voice
• AM, amplitude modulation analog voice
• FMN, narrowband frequency modulation analog voice (use this for channels operating at 12.5 kHz or less bandwidth)
• Telm, data (not digital voice)
• DMR, digital voice (e.g., “MOTOTRBO” and similar systems)
• NXDN, digital voice (e.g., “NEXEDGE”)
• D-STAR, digital voice
• LSB, lower sideband
• USB, upper sideband
• YSF, Yaesu System Fusion

Sort

The “sort” field shall be used to organize frequencies with a subcategory in a logical manner. In general, sorting by “description” or by frequency/talkgroup order is usually most appropriate. In some cases, sorting by “sort order” may be more appropriate (usually in subcategories with a known channel plan). You may control how sorting is done by clicking the “Edit Subcategory” link and changing the “Sort by” setting.

Where a custom sort order is used, sort categories shall use the number series given below and shall leave additional space between groupings for future entries.

In general, public safety and governments services subcategories shall be sorted in the following order:

• 1. Police (11, 12, 13, etc)
• 2. Fire (21, 22, 23, etc)
• 3. EMS
• 4. Public works and other services
• 5. Telemetry/data

In general, business subcategories shall be sorted alphabetically by description.

Nationwide Frequencies

Nationwide frequencies may be entered by creating nationwide agency pages within each country in the database. Nationwide frequencies are maintained by global-level administrators only. New nationwide agency pages must be approved by the Lead Database Administrator and Manager before they are created.

The following are examples of the type of data that may be included in nationwide agency pages:

• Public Safety – commonly used non-interoperability public safety frequencies, e.g., “Med” channels.
• Federal – Federal itinerant frequencies and channel plans, e.g., those from the National Interoperability Field Operations Guide (NIFOG).
• Military – Nationwide military operations frequencies, e.g., those specified in the National Interoperability Field Operations Guide (NIFOG) and Intra-Squad Radio (ISR) channel plan.
• Aircraft – Common use frequencies, e.g., those designated for emergency, air-to-air and flight test.
• Business – Common use frequencies, e.g., “color dot” frequencies.
• Railroad – Nationwide railroad channel plan
• Events – Nationwide recurring events, e.g., circuses, NASCAR and NFL.
• Marine – Nationwide marine channel plan
• Misc/Other – Miscellaneous frequencies, e.g., CB, FRS, GMRS, MURS.
• Interop – Shared frequencies and channel plans that are designated specifically for interoperability, e.g., those specified in the National Interoperability Field Operations Guide (NIFOG) and not listed in a more appropriate agency such as Public Safety, Federal, Military, etc.
• Amateur Radio – Common simplex frequencies

Nationwide frequencies shall not be duplicated on state, county or other agency pages, except when there exists a confirmed local-specific usage with a confirmed squelch tone or mode which varies from the standard nationwide plan, e.g., a MURS frequency confirmed to be used by a specific business at a specific location on a permanent basis, with a unique squelch tone. Notes regarding specific local usage with either carrier squelch or standard nationwide squelch may be placed in the collaboration Wiki for the locality.

Amateur Radio Frequencies

Amateur radio frequencies may be entered at the nationwide, state or county level as appropriate.

When defining Amateur radio frequencies at the county level, you shall create a frequency category with the type of “Amateur Radio” and add the associated subcategories and frequencies to it. Creating the frequency category with type “Amateur Radio” ensures that the frequencies are listed on the Amateur Radio tab for each county.

Amateur radio frequencies defined at the state and nationwide level shall be defined within an agency using a regular category type.

Amateur radio frequencies shall always be tagged with the “Ham” function tag and as a result all state and county level amateur radio frequencies will appear on the state-level “Amateur Radio” roll-up report page.

Amateur radio frequencies from the 10-meter FM sub-band are allowed in the database.

Per the data removal policy, we do not censor data on amateur radio repeaters. “Closed” repeaters shall be included in the database, however the “closed” nature shall be noted in the “Description” field.

A repeater shall be entered in the database in the county in which the transmitter is located. In cases of a multi-county simulcast repeater, list the repeater in the county that has the most sites or represents the main coverage area. The same geographic tagging rules for other conventional frequencies apply to amateur radio frequencies.

Packet radio frequencies may be entered and shall be tagged as “Data” channels.

Trunked Data

General

Never combine more than one logical system as a single system entry in the RR database. Just because a system is licensed to the same operator does not mean the sites are networked. Only systems of a type that is capable of being networked and that are known to be networked together shall be included as a single system in the RR database. “Hard” talkgroup patches between one or more systems are not considered “networked” for the purposes of the RR database.

All trunked systems in the RR database are automatically assigned a unique ID (“sid”). Please note that the “sid” value is not the same as a trunked system’s “system ID” (if it has one).

Conventional frequencies used in conjunction with a trunked radio system shall be entered in the database on the appropriate county (or if applicable, agency) page in the RR database. You shall link the corresponding trunked system to the subcategory by using the subcategory trunked system link. Subcategory-to-trunked radio system links shall be added to all conventional subcategories for which there is a related trunked radio system. If conventional frequencies linked to a trunked radio system do not have a specific service or function associated with them, they shall be listed in a separate subcategory linked to the trunked radio system. The trunked radio system links are intended to facilitate easy identification of the proper place to monitor specific agencies and departments, especially for novice users or users unfamiliar with a particular area.

Project 25 conventional talkgroups shall be entered on a Wiki page linked to the county page that lists the corresponding frequencies.

Trunked systems shall always be entered with the “highest level” mode of operation for which it is confirmed to be capable. For example, enter a Project 25 system as “Phase 2” type if it is confirmed to be Phase 2 capable even if it has no TDMA talkgroups confirmed in use yet.

Trunked systems shall be assigned to the union of all counties for which they are actually intended to provide coverage in addition to any other counties containing transmitter sites. Only use the “Statewide” special county setting for systems that truly cover all counties in a state. While new systems are being built out, assign them only to the counties actually confirmed to be covered by the system.

The “Miscellaneous Text” block for a system entry shall only be used for specific high-level information that must be in the database but fits nowhere else. Information such as system user agencies, site locations, operational policies/procedures and so forth shall be added to the Wiki collaboration page associated with the system. System status announcements shall be placed in the “Dated News” section.

If a county's public safety communications are on trunked systems, they should be linked in the appropriate county header sub-category. For trunked systems which cover most or all of a county, create a subcategory at the top of a county page called "(County Name) Trunked Systems" and list the pertinent trunked systems there. To minimize effort and limit duplication, do not link the pertinent trunked systems multiple times, once for each subcategory. For those systems which only pertain to one or two entities within the county, place the trunked system link in the appropriate subcategory. Because data can be fluid, do not list specific talkgroups in subcategories.

System Display Modes

The RR database supports several system display modes. The display mode is set under the “General Information” section when editing a trunked system. The available modes are:

• Normal Display – self-explanatory
• Staged – this is the default mode when creating a new trunked system. “Staged” trunked systems are only viewable by administrators. This mode shall only be used during the brief period when creating a new trunked system in the database. Systems shall not be entered until system testing has commenced, and there is enough information available for the system entry to stand on it's own in the database. The system shall be moved to the “Normal Display” mode as soon as the data is setup.
• Deprecated – this status is used to remove a decommissioned trunked system. “Deprecated” trunked systems are not normally visible in the database but may be returned in search results.
• Policy - No Display – this status indicates that a previously created system has been blocked due to a data removal request. This status is no longer used under the current data removal policy.
• Deleted – this status indicates that a system has been deleted. This status shall only be used to remove erroneous systems from the database. Use the “Deprecated” status to mark systems that are no longer in use.

System Names

Public safety trunked systems shall generally be named after the primary jurisdiction (e.g., county) that the system covers or by the primary agency operating the trunked system. If a system has a specific “brand name” assigned (e.g., “Southeast Texas Area Radio Network”) then the specific name shall always be used. If the “brand name” of the system ends with the word “system” then do not exclude the word “system” from the system name.

In the case of business trunked systems, always use the “doing business as” (DBA) name, not the legal business name. In other words, the system shall be identified by the common name that would be generally recognized by the public. If the “DBA” and legal name are the same, or if the legal name is the only known name, do not include extraneous suffixes such as “LLC” or “Inc.” unless they are used as part of the common name (these suffixes indicate the legal status of the business and are not relevant in the RR database; legal names are typically found on the license if someone is interested in that detail).

System names shall always be unique. It is common to have a number of trunked systems operated by a single business so for these systems the name shall include unique identifying information in parentheses at the end of the name. Use the minimum amount of information to uniquely identify the system (e.g., geographic location, frequency band, type of system, etc.). When these options are exhausted systems may be arbitrarily numbered sequentially beginning with 1.

Here are some example system names:

• ABC Communications (Houston 460 MHz LTR)
• ABC Communications (Houston 850 MHz LTR)
• ABC Communications (Houston Motorola)
• XYZ Communications (Austin #1)
• XYZ Communications (Austin #2)

Talkgroup Categories

Talkgroups shall be logically grouped into categories that make sense based on the usage of each trunked system. Small systems need only have a single talkgroup category and this category shall be named “All” (i.e., to display as “All Talkgroups” in the user interface).

To facilitate geographic tagging, each talkgroup category shall correspond to one geographic area. Do not include talkgroups with multiple non-congruent geographic areas in the same talkgroup category.

Talkgroups for wide-area systems shall be listed by county category when applicable. If such listings exceed 40-50 separate entries, categories can be broken down by county-level or municipal-level service (Law Enforcement, Fire/EMS, Public Works, Common/Mutual Aid), but careful consideration must be given to how this is done. Multiple separate categories with only one or two entries per category should be avoided wherever possible.

A specific category for patch talkgroups shall be created if needed, as provided for in Section 6.3.5.3 (Patch Talkgroups).

Adding And Editing Talkgroups

Under no circumstances are unidentified talkgroups of any kind to be entered in a system, encrypted or clear.

Talkgroup Mode

Talkgroup “mode” indicates whether the talkgroup is used in analog or digital mode and whether or not encryption is used. The Talkgroup mode is indicated by a "base" mode type, and then an encryption flag where appropriate. The valid options for a base talkgroup mode are:

• A – Analog (may be voice or data)
• D – FDMA digital voice
• M – Mixed (analog voice and digital voice)
• T – TDMA digital voice capable

Only one mode shall be entered for a given talkgroup. If TDMA capability is noted on a talkgroup at any time it should be marked "T" for TDMA capable.

Encryption modes shall be used to indicate talkgroups that use encryption exclusively or when encryption is partially used.

Note: Partial does not mean "accidentally clear or encrypted use."

• E – Capital "E" - encryption exclusively noted
• e – Lowercase "e" - partial encryption noted.

Example Uses:

• Te - TDMA capable talkgroup with partial encryption
• AE - Analog with exclusive encryption
• DE - FDMA digital with exclusive encryption
• De - FDMA digital with partial encryption

Encrypted Talkgroups

In general, encrypted talkgroups will not be entered in the database, unless either of two specific conditions are met.

• If the agency which "owns" an encrypted talkgroup can be confirmed to a reasonable degree of certainty, it may be entered in the talkgroup category for that agency. Ways to confirm ownership include monitoring unencrypted talkgroups for references to an encrypted talkgroup which then becomes active (ie "Switch to Tac 2" and the same units appear on the encrypted talkgroup), or regular use of the talkgroup by an overwhelming preponderance of radio IDs which have been confirmed as a specific agency.
• Provided there are no clear (unencrypted) talkgroups on the system, encrypted talkgroups may be entered to indicate that there is activity on the system.

Patch Talkgroups

Patch talkgroups are specific talkgroups which "interconnect" other talkgroups and/or radio systems for operational reasons. They may use an existing talkgroup, or create a new talkgroup, and shall be treated differently depending upon the type of patch.

• "Hard" patches are those which are implemented in order to provide long-term interconnection between different radio systems; P25 ISSI is an example of a hard patch. Hard patches may be entered in the database within a dedicated "Patches" talkgroup category.

• "Soft" patches are those which are initiated by a dispatcher or other communications personnel upon request for tactical purposes during an incident. Patches of this nature are transitory and of limited duration, and shall not be entered in the database.

The only exception to the prohibition on listing soft patches is for Harris systems, which create a dedicated new talkgroup for a patch. Patch talkgroups for Harris systems shall treated as hard patches and listed in a specific category dedicated to these talkgroups. Unless specific assignments are confirmed, Harris dynamic patch talkgroups shall be given an alias name of "Patch XXXXX" where XXXXX is the talkgroup.

Adding and Editing Radio IDs

Note: This feature has not been implemented yet but is coming soon.

Radio IDs will be shown on a specific tab for each radio system, and will contain the following information:

• Radio ID (maximum 8 numerals)
• ID Alias (maximum 16 characters). Alias names must be as descriptive as possible but like talkgroup IDs must be unique.
• ID description (maximum 30 characters)

Like a talkgroup alias, a Radio ID alias must be descriptive, unique and stand on it’s own. The format for the alias name is somewhat flexible but shall show at least agency name or abbreviation and the radio ID (or a portion of it); standard abbreviations for mobile (M) and portable (P) radios may be used.

IDs for law enforcement and other sensitive occupations such as federal agencies shall contain only the agency name/abbreviation and the radio ID (or a portion of it). Personally identifiable information such as (but not limited to) names, badge numbers, car numbers, beat/precinct numbers or patrol districts shall not be shown. This also applies to portable radios assigned to a specific individual in other services.

Fire/EMS alias names may contain the apparatus name and in the case of portable radios assigned to a vehicle, the apparatus name and radio designator. Specific position descriptions such as "pump operator" and "officer" shall not be part of the radio ID alias but confined to the description field.

Dispatch consoles and control stations may be identified as such.

Examples:

Radio ID	ID Alias	ID Description
2390520	SgrGrvPD 90520	Sugar Grove PD
2500110	CFD Engine 1	Engine 1 vehicle radio
2500111	CFD Eng 1 P1	Engine 1 portable 1 (pump operator)
2503804	Cols Console 3804	Columbus console (CFD)
2500404	Station 4 base	CFD Station 4 radio
6506502	PickSO 6506502	Pickaway Co SO
9020500	OSP 9020500	Ohio State Highway Patrol
7190591	GreenFD 90591	Green Twp FD

System-Specific Information

Project 25

Project 25 system sites are grouped in the following hierarchy:

• Wide Area Communications Network (WACN; this level is equivalent to an RR system)
• System ID (this level is equivalent to an RR zone)
• Radio Frequency Subsystem (RFSS)
• Site

Project 25 trunked systems having multiple system IDs (indicating that they are using WACN-level networking) will have additional user interface displayed for administration purposes. Multiple system IDs will be created as zones with each zone having a description. Each site that is created must be assigned to a zone. If a P25 system has only one system ID then no zones will be created in the RR database. P25 systems using WACN-level networking will require that talkgroups be assigned to the system ID to which the talkgroup belongs.

Project 25 systems that are networked via Inter-RF Subsystem Interface (ISSI) shall not be combined as a single system in the RR database. ISSI-patched talkgroups shall be considered “hard patches” for the purposes of the RR database.

Sites must be assigned to the appropriate RFSS. Please note that most scanners report RFSS and site ID together as combined site or “tower” ID. Furthermore, scanners are not consistent with respect to reporting the combined RFSS/site ID in hexadecimal or decimal format. Please be sure that you know whether the submissions you are working are referring to decimal or hexadecimal RFSS/site numbers.

Sites broadcasting a Phase II TDMA control channel should have the "TDMA Control Ch" flag enabled in the site's settings.

System IDs shall be entered in 3-digit hexadecimal format. Wide Area Communications Network (WACN) codes shall be entered in 5-digit hexadecimal format.

Motorola (Smartnet)

Do not enter Motorola “status bit” talkgroups, i.e., all Motorola talkgroups shall be divisible evenly by 16 (in decimal format). The “status bit” indicates the “status” of the talkgroup and does not actually represent a unique talkgroup. When entered in hexadecimal format in the RR database, Motorola talkgroups exclude the status bit (the right most hexadecimal digit if converting from decimal).

Be sure to create separate systems in the RR database for each unique Motorola trunked system. Unless a system is confirmed to be OmniLink, a system shall never have more than one system ID assigned.

For OmniLink systems, each OmniLink zone is represented by a Motorola system ID and that system ID shall be created as a zone in the RR database. Each site must be assigned to its respective zone (system ID).

System IDs shall be entered in 4-digit hexadecimal format.

EDACS

EDACS talkgroups may be entered or imported in either decimal or Agency-Fleet-Subfleet (AFS) format. Please use the appropriate field corresponding to the format of the talkgroup that you are trying to enter. You shall only enter the talkgroup in one format or the other, not both.

At the time of this writing, no scanners currently support displaying the system ID to which a talkgroup belongs so this information may not be readily available. Furthermore, at the time of writing, the RR database does not support assigning talkgroups to system IDs. If the RR database is enhanced to enable tracking the system ID to which talkgroups belong then it is expected that this information will be properly tracked by administrators entering talkgroup data.

LTR

Standard LTR systems by definition are single-site only and each shall each be entered as a separate system in the RR database.

Standard LTR talkgroups shall be entered and imported without the dash (“-”) characters in the decimal talkgroup field, e.g., the talkgroup “1-05-101” shall be entered or imported into the decimal talkgroup field as “105101.”

Standard LTR systems shall never have a logical channel number (LCN) greater than the maximum number of 20.

iDEN

iDEN systems (except Nextel) may be entered in the database when data about these systems is confirmed.

DMR

DMR frequencies on which talkgroups move between time slots, or DMR repeaters networked with others (such as amateur radio DMR networks), shall be entered as a conventional networked system (ie single frequency trunked). Known DMR trunked systems (such as Motorola Connect Plus or Capacity Plus) shall be entered as trunked systems with the appropriate settings.

If talkgroups are restricted to specific time slots, the frequency should be entered as a conventional frequency with the proper time slot, color code and talkgroup entered.

Due to differences in the way scanners and some trunked data monitoring programs display DMR data, care must be take to verify the source of submitted data so it can be entered appropriately in the database.

DMR Connect + Systems have a system ID which are decoded and reported in the following manner:

• Uniden scanners display the system IDs in Hex
• DSD displays the system IDs in Dec

DMR Tier III Systems can have a LCN (Logical Channel Number) and a Channel ID for each TDMA slot. We store the LCN for each DMR Tier III system channel and we will automatically calculate the Channel IDs for each site to display on the site details page. Therefore, for DMR Tier III systems you should enter the calculated LCN for each site frequency. A scanner will typically report and only work with an LCN. DSDPlus and other DMR control channel decoders will report each Channel ID. The formula for calulating an LCN from a decoded channel ID is to round LCN/2 and subtract 1

lcn = round(channel_id/2)-1

NXDN

Nexedge NXDN systems can have a system ID which are decoded and reported in the following manner:

• Uniden scanners display the system IDs in Hex
• DSD displays the system IDs in Dec

Logical Channel Numbering

For unused logical channels numbers (LCNs) in system types such as EDACS and LTR, enter “0.0” for the frequency. “0.0” creates a placeholder that will cause the particular LCN position to be displayed as “N/A” in the database user interface. It is not necessary to enter placeholder entries for LCNs above the highest known used LCN in the site.

Logical channel numbers shall always be greater than zero and less than or equal to the maximum number of channels possible in a single site depending on the characteristics of the particular system type.

Always indicate whether frequencies for an LCN-based system are confirmed or unconfirmed. Create separate sites within each system for confirmed LCNs and unconfirmed LCNs – never mix both in one site. If the system is a single-site system, then site 1 shall be “Confirmed LCN” and site 2 shall be “Unconfirmed LCN” (if applicable). If the system is a multi-site system, then indicate in the site notes whether or not the LCNs are confirmed for that site. Always be sure to remove any unconfirmed LCNs from an unconfirmed LCN site once the LCNs are confirmed.

Control Channels

For system types that use dedicated control channels, the frequencies used as control channels may be designated in the database. A trunked site frequency may be marked with a “d” character to indicate it is a primary control channel. When confirmed information is obtained regarding which channels are designated as alternate control channels, these may be indicated by using an “a” character instead of “d.” In general, the “d” character shall always be used to denote a control channel unless specific information is available regarding alternate control channels.

If a P25 system is known to be provided by Harris, Tait, EADS or Cassidian, the normally-active control channel for each site shall be designated as the primary control channel, and all other channels at that site shall be designated as alternate control channels, unless specific reliable information to the contrary is submitted. Since systems from these vendors can use any channel as control, this is necessary to ensure that scanners can locate a new control channel in the event of a change.

Sites

Trunked system sites shall not be entered unless a site location is known at least to the county level. Sites located by means of the "neighbor site" logs of control channel monitoring programs shall be entered in the Wiki for the system unless a specific or reasonably close approximation of site location can be made. This does not include mobile sites used for emergency backup or special events.

Trunked System sites that are mobile in nature, such as suitcase transmitters, mobile on-wheels sites, or other itinerant type sites should be assigned to the "Itinerant" county for the state or province.

Use the “Splinter” checkbox to indicate that a site uses 800 MHz “splinter” frequencies (e.g., sites near the Mexico border in the United States). Use the “Rebanded” checkbox to indicate that a Motorola (only) trunked system 800 MHz site has been “rebanded”/reconfigured per the FCC’s 800 MHz transition plan (i.e., public safety frequencies moved down 15 MHz).

Simulcast zones/layers shall be represented as a single logical “site” in the RR database.

Sites must also have a unique site number. If a submission is received for a confirmed site but a site number is not immediately available, create a temporary, unique site number to use until the actual site number is confirmed.

System Migration

In situations where a trunked system is being converted to a new type (for example, a business system being converted from LTR to DMR, or a public safety system from EDACS to P25), a new system must be created with the new system type, using the existing name with the new type appended in parenthesis. For example, if the old LTR system is named "Joe's Pizza and Car Wash" the new system shall be named "Joe's Pizza and Car Wash (DMR)."

Sites, frequencies and talkgroups shall be added to the new system as they go on line. Sites shall not be removed from the old system; simply remove frequencies from the old system if they're confirmed in use on the new system.

Talkgroups shall not be marked "deprecated" as they can still remain in service on the old system.

Once the new system is fully on line and the old system off line, change the the old system to "deprecated" status, but do not change the name of the new/surviving system.

Alpha Tagging

General

Alpha tags are limited to 16 characters to ensure compatibility with as many scanners as possible. Alpha tags shall be made as clear as possible given the space provided. Alpha tags shall generally indicate the agency and the channel number or usage to the extent that the information is known and can reasonably fit in 16 characters.

Alpha tags should reflect the actual talkgroup name as shown on a radio transceiver programmed for a specific conventional or trunked system, unless that name is unreasonably difficult to understand. Alpha tags shall be written to be useful to scanner users and furthermore they shall be clear to novice scanner users to the extent possible.

All capitals shall be used as appropriate to more accurately reflect actual talkgroup or channel names (especially where use of mixed upper/lower case would be difficult to read). If an actual name is not known, alpha tags should use a mix of lower and upper case letters where possible.

Alpha tags “stand alone” and are not a more specific classification under the category, subcategory and description hierarchy. The alpha tag itself shall only contain information that is also represented in the county/agency/system name, category, subcategory and/or description of the frequency or talkgroup.

If the frequency or talkgroup description is insufficient to provide enough information to create a unique alpha tag, then the frequency or talkgroup number shall be included as part of the alpha tag to ensure uniqueness.

Previously existing alpha tags of 12 or fewer characters shall not be "updated" unless new information is received, or there is a compelling reason to do so.

Standard Abbreviations

• AC – Animal Control
• Bn or BN - Battalion
• Car – Car-to-Car
• Dsp or Disp – Dispatch
• E–East
• EMS – Emergency Medical Services
• FD – Fire Department
• FG or FGND – Fireground
• JFD – Joint Fire District
• M – Mobile radio (in ID database)
• N – North
• NE – Northeast
• NW – Northwest
• Ops – Operations
• P – Portable radio (in ID database)
• PD – Police Department
• PW or DPW – Public Works
• S – South
• SD – Sheriff’s Department
• SE – Southeast
• SO – Sheriff’s Office
• Svc - Service
• SW – Southwest
• TA – Talk-Around
• Tac – Tactical
• VFD – Volunteer Fire Department
• W–West

Function Tagging

General

Function or service tagging allows frequencies and talkgroups to be placed into general category-based groups. Do not be concerned that the wording of the function tag names does not exactly match what you believe to be the use of the frequency or talkgroup. Function tags shall enable novice users to easily “filter” the frequencies or talkgroups for which they are searching. The terms “Function Tag,” “Service tag” and “Tag” can be used interchangeably in reference to Function Tagging.

Service Tags and Descriptions

• Aircraft – All civilian or military air traffic control operations (typically in the 118-136 MHz and 225-380 MHz bands in AM mode). Other aviation frequencies (that are not used for air traffic control) shall be tagged with the most relevant non-Aircraft tag. Airline “company frequencies” (in the USA, typically in the 128.825-132.0 MHz and 136.5-136.975 MHz) shall be tagged as “Business.” Aerial firefighting frequencies shall be tagged with the appropriate “Fire” tag.
• Business – For most business related entities not covered by other tags. Please note that the following tags override the “Business” tag and shall always be used instead when they are applicable: Media, Railroad, Security, Transportation and Utilities.
• Corrections – For jail/prison operations and other corrections activities, including federal prisons.
• Data – For data, paging, telemetry and most non-voice operations. Do not tag encrypted voice frequencies or talkgroups as “Data” (they shall be tagged with the more specific tag).
• Deprecated – This tag denotes a frequency or talkgroup that is no longer used. This tag shall be used only temporarily during transition/migration periods for new radio systems. Frequencies and talkgroups shall be deleted if they are truly obsolete, but in any case will be automatically purged 30 days after being tagged Deprecated.
• Emergency Ops – For Emergency Operation Centers and similar emergency management or disaster-related operations.
• EMS Dispatch – For EMS dispatch (including rescue squads and medical helicopter operations).
• EMS-Tac – For EMS on-scene communications, tactical operations and secondary channels. Please note that EMS-to-Hospital communications shall be tagged with “Hospital.”
• EMS-Talk – For EMS talk-around, training, car-to-car and supervisor operations.
• Federal – For all federal government operations (except corrections, traditional law enforcement patrol and fire/EMS operations which shall be tagged using the more appropriate tags). In the USA, the Coast Guard shall be tagged as “Federal.”
• Fire Dispatch – For fire dispatch, including combined fire/EMS dispatch.
• Fire-Tac – For fireground, tactical and on-scene communications, including combined fire/EMS operations.
• Fire-Talk – For fire talk-around and car-to-car operations, training, chiefs, supervisors, etc., including combined fire/EMS operations.
• Ham – For any amateur radio assignment.
• Hospital – For EMS-to-Hospital communications and patient reports (e.g., “Med” or “HEAR” channels). Please note that hospital operations, maintenance, etc. shall be tagged with “Business.”
• Interop – Interoperability communications, cross-agency communications, mutual aid, etc. This tag includes inter-entity coordination as well as to interoperability between departments (e.g., police, fire and public works) of the same entity.
• Law Dispatch – Law enforcement dispatch.
• Law Tac – Law enforcement tactical, SWAT, on-scene, surveillance and specific sub-agency communications.
• Law Talk – Law enforcement talk-around, training, car-to-car and supervisor operations.
• Media – Newspapers, television and broadcast radio operations (most commonly in the 450/455 MHz and 161 MHz bands in the USA).
• Military – All military operations (e.g., air refueling, range control, air-to-air combat, etc.) including Civil Air Patrol in the USA. Military law, fire and EMS shall be tagged with the appropriate law, fire or EMS tag.
• Multi-Dispatch – For combined law enforcement and fire/EMS dispatch. This is a special case tag for operations that are combined as a matter of normal practice. Do not use this tag for interoperability channels, or combined Fire/EMS dispatch channels.
• Multi-Tac – For combined law enforcement and fire/EMS tactical and on-scene communications. This is a special case tag for operations that are combined as a matter of normal practice. Do not use this tag for interoperability channels, or combined Fire/EMS tactical channels.
• Multi-Talk – For combined law enforcement and fire/EMS tactical talk-around and car-to-car operations. This is a special case tag for operations that are combined as a matter of normal practice. Do not use this tag for interoperability channels, or combined Fire/EMS talk channels.
• Other – Anything not covered by the other tags. Note: This tag should rarely – if ever – be used, so in general pretend like it does not even exist. Administrators sometimes incorrectly use the “Other” tag on frequencies and talkgroups that should be labeled “Public Works.”
• Public Works – Public agency non-public safety communications. This includes any non-public safety government services, such as trash, streets, roads, zoos, administration, maintenance, animal control, community initiatives, code compliance, etc. Please do not use the “Other” tag for government services. Exceptions: Public transportation and government security services shall be tagged with “Transportation” or “Security” respectively. Tag government-run utilities with the “Utilities” tag.
• Railroad – All common carrier railroad communications.
• Security – Non-law enforcement security operations, including private security companies, non- commissioned government agency security, school security, etc.
• Schools – School-related communications (schools, school buses, football games, etc.). Exception: Security shall be tagged with “Security” and law enforcement shall be tagged with the appropriate law enforcement tag.
• Transportation – Public and private bus, taxi and public passenger rail (isolated rail systems not connected to a common carrier railroad network) communications (except school buses).
• Utilities – Electric, water, natural gas, phone, cable TV, etc. operations whether provided by a private or governmental entity.

Geographic Tagging

Geographic tagging of conventional frequency subcategories and talkgroup categories is used to indicate the “service area,” e.g., a city center point and diameter (representing a circle to approximate the area of the city) – not necessarily the actual area of radio reception. The purpose of geographic tagging is to facilitate location-based scanner programming, i.e., if a person is physically located in a city then they would want to scan the frequencies for the city that they are in, not the adjacent city which they might also be able to hear.

Geographic tagging of trunked system sites is used to indicate the location of the site and the approximate coverage area of the site (represented by a circle centered on the site). Since actual coverage areas are typically not exact circles, you shall approximate the coverage area by including the entire intended coverage area even if this means including extra area.

Geographic data (latitude, longitude and radius) shall be assigned to conventional frequency subcategories, talkgroup categories and trunked system sites. Do not simply copy FCC license data to fill-in this information (unless the latitude and longitude happen to be correct on the license).

Latitude and longitude shall always be entered in decimal degrees format, not in degrees-minutes-seconds format.

Airports shall be tagged with the intent that the coverage area is the grounds of the airport (and not areas beyond the grounds).

The way that a trunked system site inherits location data is as following (in order of priority):

• Location data explicitly assigned to the site.
• Default location data for the county in which the site resides.
• Default location data for the trunked system.

The reason for the inheritance priority is that if a site does not have location data assigned, then the next logical step is to use the county's data since that is where the site resides and is a reasonable starting point for assigning coverage.

Revision History

Current Version 2.0

• 2019-08-22
  • New live online version (official); no printed versions in future
  • Minor corrections and edits
  • Section 6.1.2, added prohibition against naming specific persons
  • Section 6.1.4.3, new section
  • Section 6.2.6, added clarification regarding local listings for nationwide frequencies with unique squelch
  • Section 6.4.1, updates and clarifications to alpha tag policy
• 2019-08-27
  • Section 6.1.2 Excluded Data, limited exemption for 25-30 MHz frequencies used specifically for land mobile
  • Section 6.4.1 Alpha Tags, new 16 character limit, prohibition on changing existing tags merely for the sake of change
• 2019-09-12
  • Section 6.1.4.4 Amateur Radio Subcategory Naming Convention and Sort Order added
  • Section 6.3.6.6 DMR added
  • Section 6.2.2.1 Railroad Frequencies added
  • Minor corrections and edits
• 2019-12-13
  • Section 6.1.2 Excluded Data, added exclusion for private low-power amateur radio "hotspots" for DMR and other digital modes.
• 2020-01-10
  • Section 5.1 Working Submissions, added requirement for administrators to submit personally-sourced information.
  • Section 6.3.1 Trunked Data General, corrected "Type 2" to "Phase 2."
• 2020-01-17
  • Section 6.3.2 System Display Modes, clarified when a trunked system should be entered in staging.
• 2020-01-24
  • Secton 6.2.3 County-Level Pages, added prohibition on entering "talkaround" frequencies using shared repeater output/squelch.
• 2020-02-07
  • Section 6.5.2 Service Tags and Descriptions, updated to reflect automatic purging of Deprecated entries.
• 2020-02-19
  • Section 6.3.10 System Migration, new section added.
• 2020-03-24
  • Section 6.3.4 Talkgroup Categories, added guidance for handling patch talkgroups.
• 2020-06-01
  • Changes to unstructured data and abbreviations sections to accommodate Radio ID database.
  • Added Section 6.3.6 Adding and Editing Radio IDs
• 2020-08-03
  • Updated Section 6.3.10 to add prohibition on adding sites without a known location.
• 2020-09-10
  • Updated Section 6.3.10 to clarify that each site must have a unique site number.
• 2020-10-20
  • Section 2.0, deleted reference to “rr_dbadmin” Yahoo Group account shutdown of Yahoo Groups on 12/15/20.
• 2020-11-03
  • Section 5.1, updated to add time limit for holding submissions.
• 2020-12-08
  • Section 5, updated and expanded, added policy for use of codeplug data.
  • Section 6.3.5.2, new section for handling encrypted talkgroups.
  • Section 6.3.11, System Migration - added prohibition on changing name of new/surviving system.
• 2020-12-17
  • Section 6.2.2, Statewide or Multi-County Frequencies - added clarification that Federal and Military information shall be listed in the county in which a facility is located, under a Federal agency page for that county, unless it is truly regional or statewide in nature.
• 2021-05-24
  • Section 6.3.5.3, new section defining process for Patch Talkgroups.
• 2021-07-24
  • 6.3.7.1 Project 25 Phase II Control channel handling
  • 6.3.7.6 DMR System ID handling
  • 6.3.7.7 NXDN System ID handling

Older Versions

• Version 1.0, 2009-03-22
  • Initial version.
• Version 1.1, 2009-03-28
  • Revised conventional frequency subcategory sort convention
  • Revised non-repeated duplex frequency pair entry convention
  • Added “Corrections” tag
  • Added common abbreviations
  • Added system ID and WACN should be entered in hexadecimal format
  • Clarified geographic tagging of trunked system sites
  • Clarified entering and importing of LTR talkgroups.
• Version 1.2, 2009-04-18
  • Added “logical channel numbering” section
  • added “always include ‘system’ if system name ends with that word”
  • added standard “channel” abbreviation
  • added “use all capital letters for abbreviations only”
  • added clarification of the use of the “Hospital” tag
  • made minor formatting changes
  • made minor clarifications related to the RR 4.0 release
  • added explanation of how to mark control channels
  • revised the “included data” and “excluded data” sections to reflect the move of unstructured data to the wiki
  • removed the “10-codes and unit lists” section
  • added “access control” section
• Version 1.3, 2009-07-25
  • Fixed typographical errors
  • do not enter Motorola “status bit” talkgroups
  • avoid using abbreviations in “description” fields
  • only enter output frequency tones
  • enter unique frequency-tone pairs separately
  • added database administrator selection policy
  • new trunked system submissions only visible to global administrators
  • always enter latitude and longitude in decimal degrees format
  • added explanation of submission notifications and submission notes
• Version 1.4, 2010-10-20
  • How to enter simulcast trunked sites
  • clarified use of “Data” tag
  • do not reject unstructured data submissions
  • radio IDs are specifically excluded
  • added RAN tone type
  • clarified hexadecimal Motorola talkgroup entry
  • clarified “Staged” display mode
  • added iDEN system section
  • temporary use frequencies are excluded
  • names of radio users are excluded
  • added category and subcategory naming rules
  • added Database Entity Naming Policy
• Version 1.5, 2011-09-10
  • Added “rebanded” checkbox policy
  • changed amateur radio exclusion to make all amateur radio frequencies included data
  • clarified the definition of “included data” to explicitly require identified/confirmed information
  • clarified valid system ID formats
  • documented “Deprecated” function tag
  • clarified use of abbreviations
  • updated frequency modes to remove number designations
  • added section on naming conventions
  • updated Project 25 system organization to reflect new RR database organization by WACN, System ID (“zone”), RFSS and site
  • clarified Database Entity Naming Policy
  • clarified state-level railroad agency page usage
  • clarified use of subcategory trunked radio system links
  • specified data entry policies for Project 25 ISSI data
  • clarified use of Military function tag
  • clarified use of the alpha tag field
  • expanded and clarified agency page usage
  • clarified “Depreciated” trunked radio system status and added “Deleted” status
  • added nationwide frequencies section
  • added amateur radio frequencies section
  • various miscellaneous clarifications and updates to wording
• Version 1.6, 2013-02-25
  • Numerous minor clarifications of wording throughout the document
  • added talkgroup category single geographic requirement
  • added airports geographic tagging policy
  • clarified not to enter duplicate frequencies
  • added TRBO Color Code
  • added LSB and USB modes
  • clarified tagging of aviation frequencies
  • clarified to tag medical helicopter operations as EMS
  • clarified use of FMN mode
  • added TDMA talkgroup mode and clarified usage of talkgroup modes
  • clarified state universities are not statewide agencies
  • clarified not to sit on submissions
  • clarified entering trunked system type with its highest confirmed level of capability
  • clarified use of the Multi and Interop tags
  • clarified use of “Statewide” special case county for trunked systems
  • clarified tagging of government-run utilities
  • added location inheritance policy for trunked system sites
  • expanded guidelines for amateur radio frequencies
• Version 1.7, 2013-08-01
  • Numerous minor clarifications of wording throughout the document
  • added policy for Harris, Tait, EADS and Cassidian P25 control channels
  • clarified tagging of encrypted channels/talkgroups
  • updated trunked system Staging procedure
  • clarified to tag amateur radio packet frequencies as Data
  • added policy for entry of non-standard squelch tones
• Version 1.8, 2015-01-20
  • Section 3.4, updated Professional Behavior section
  • Section 5.1, updated with seven-day wait for global administrators
  • Section 6.1.4.2 added, Frequency and Talkgroup Descriptions
  • Section 6.2.5.5, clarified use of input tones for Amateur Radio frequencies, added note regarding TDMA slot numbers
  • Section 6.2.5.6, added mode YSF (Yaesu System Fusion)
  • Section 6.2.5.7, added custom sort guidance
  • Section 6.3.1, added guidance for P25 conventional talkgroups and Miscellaneous Text block usage
  • Section 6.3.4, added guidance on talkgroup categories for wide-area systems
  • Section 6.5.2, heading changed to "Service Tags and Descriptions."
• Version 1.8, 2015-02-25
  • Minor corrections and edits.
• Version 1.8, 2024-11-30
  • Section 6.3.1, (Trunked Data [General]), added requirement to put link to trunked system in subcategory heading.