gr-mcp-docs/reference/cospas-sarsat/g-series/g005.md

---
title: "G005: C/S G.005 - Issue 3 - Rev. 2"
description: "Official Cospas-Sarsat G-series document G005"
sidebar:
  badge:
    text: "G"
    variant: "note"
# Extended Cospas-Sarsat metadata
documentId: "G005"
series: "G"
seriesName: "General"
documentType: "overview"
isLatest: true
issue: 3
revision: 2
documentDate: "October 2023"
originalTitle: "C/S G.005 - Issue 3 - Rev. 2"
---

> **📋 Document Information**
>
> **Series:** G-Series (General)
> **Version:** Issue 3 - Revision 2
> **Date:** October 2023
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)

---

COSPAS-SARSAT
GUIDELINES ON 406 MHz BEACON
CODING, REGISTRATION, AND
TYPE APPROVAL
C/S G.005
Issue 3 – Revision 2

![Image 1 from page 1](/images/cospas-sarsat/G-series/G005/G005_page_1_img_1.png)


COSPAS-SARSAT GUIDELINES ON 406 MHz
BEACON CODING, REGISTRATION, AND TYPE APPROVAL
History
Issue
Revision
Date
Comments


Approved by the Cospas-Sarsat Council (CSC-9)


Approved by the Cospas-Sarsat Council (CSC-21)


Approved by the Cospas-Sarsat Council (CSC-23)


Approved by the Cospas-Sarsat Council (CSC-37)


Approved by the Cospas-Sarsat Council (CSC-41)


Approved by the Cospas-Sarsat Council (CSC-43)


Approved by the Cospas-Sarsat Council (CSC-45)


Approved by the Cospas-Sarsat Council (CSC-51)


Approved by the Cospas-Sarsat Council (CSC-53)


Approved by the Cospas-Sarsat Council (CSC-59)


Approved by the Cospas-Sarsat Council (CSC-62)


Approved by the Cospas-Sarsat Council (CSC-69)


TABLE OF CONTENTS
Page
History  ................................................................................................................................................. i
Table of Contents  ................................................................................................................................. ii
List of Figures
................................................................................................................................ iv
List of Tables
................................................................................................................................. v
List of Annexes
................................................................................................................................. v
1.
INTRODUCTION .............................................................................................. 1-1
1.1
Overview .............................................................................................................. 1-1
1.2
Scope
1-1
1.3
Reference Documents .......................................................................................... 1-2
1.4
Summary of the Cospas-Sarsat Guidelines on Beacon Coding, Registration
and Type Approval ................................................................................. 1-2
2.
BACKGROUND INFORMATION ON THE 406 MHz System ................... 2-1
2.1
406 MHz Beacons ................................................................................................ 2-1
2.2
Beacon Identification ........................................................................................... 2-1
2.3
Operational Use of Beacon Registration Databases ............................................. 2-2
2.4
Encoded Position Data ......................................................................................... 2-3
3.
FIRST GENERATION 406-MHz BEACON CODING (FGB) ..................... 3-1
3.1
C/S T.001 or C/S T.015 Beacon Types ................................................................ 3-1
3.2
General Coding Requirements ............................................................................. 3-8
3.2.5 General Format and Field Definition of the 406 MHz Beacon Message . 3-8
3.2.5.1 The short message format consists of: ....................................................................... 3-8
3.2.5.2 The long message format consists of: ........................................................................ 3-8
3.2.2 Preamble ................................................................................................... 3-9
3.2.2.1 Standard Preamble ..................................................................................................... 3-9
3.2.2.2 Self-Test Mode Preamble .......................................................................................... 3-9
3.2.3 First Protected Data Field (PDF-1) ........................................................ 3-10
3.2.3.1 General Structure of the First Protected Data Field (PDF-1) .................................. 3-10
3.2.3.2 Format Flag, Protocol Flag and Country Code ........................................................ 3-10
3.2.3.3 Identification Data and Position Data ...................................................................... 3-12
3.2.3.4 Fifteen Hexadecimal Character Beacon Identification ............................................ 3-12
3.2.4 21-bit First BCH Error Correcting Field (BCH-1) ................................. 3-13
3.2.5 Non-Protected Data Field of the Short Message Format ....................... 3-13
3.2.6 Second Protected Data Field (PDF-2) .................................................... 3-14
3.2.7 Second BCH Error Correcting Field (BCH-2) ....................................... 3-15
3.3
Coding User Protocols ....................................................................................... 3-16


3.3.1 General Requirements for User Protocols .............................................. 3-16
3.3.2 Coding Maritime Protocols .................................................................... 3-18
3.3.2.1 Coding the Maritime User Protocol with MMSI ..................................................... 3-19
3.3.2.2 Coding EPIRBs with a Unique Serial Number ........................................................ 3-19
3.3.2.3 Coding EPIRBs with the Radio Call Sign Identification ......................................... 3-21
3.3.2.4 3.3.2.3.1 Coding the Maritime User Protocol with the Radio Call Sign ................. 3-21
3.3.2.5 3.3.2.3.2 Coding the Radio Call Sign User Protocol with the Radio Call Sign ....... 3-22
3.3.3 Coding Aviation Protocols ..................................................................... 3-23
3.3.3.2 3.3.3.1 Coding ELTs with the Beacon Serial Number ............................................ 3-24
3.3.3.3 Coding ELTs with the Aircraft Operator Designator and a Serial Number ............. 3-25
3.3.3.4 Coding ELTs with the Aircraft 24-bit Address ....................................................... 3-25
3.3.3.5 Coding ELTs with the Aircraft Nationality and Registration Marking ................... 3-27
3.3.4 Coding PLBs with the Serial User Protocol ........................................... 3-28
3.3.5 Coding the Test User Protocol ............................................................... 3-28
3.3.6 Coding the National User Protocol ........................................................ 3-30
3.4
Coding Location Protocols ................................................................................. 3-31
3.4.1 Position Data Encoding .......................................................................... 3-32
3.4.2 Coding the User-location Protocols ....................................................... 3-33
3.4.3 Coding the Standard Location Protocols ................................................ 3-34
3.4.4 Coding the National Location Protocol .................................................. 3-38
3.4.5 Coding the RLS Location Protocols....................................................... 3-40
3.4.6 Coding the ELT(DT) Location Protocols ............................................... 3-44
3.4.6.1 ELT(DT) Cancellation Message .............................................................................. 3-48
3.4.7 Coding the Test Location Protocols ....................................................... 3-48
4.
SECOND GENERATION 406-MHz BEACON CODING (SGB) ................. 4-1
4.1
C/S T.018 Beacon Types ...................................................................................... 4-1
4.2
General Coding Requirements ............................................................................. 4-2
4.2.1 Overall SGB Message Structure .............................................................. 4-2
4.2.1.2 Preamble .................................................................................................................... 4-2
4.2.1.3 Useful Message ......................................................................................................... 4-2
4.2.1.4 Protected Data Field .................................................................................................. 4-2
4.2.2 General Format and Field Definition of the SGB 406-MHz Message ..... 4-2
4.2.3 23-Hexadecimal ID .................................................................................. 4-3
4.3
SGB Specific Coding Features ............................................................................. 4-3
4.3.1 Location vs. Non-Location Encoded Beacons ......................................... 4-3
4.3.2 Spreading Codes ....................................................................................... 4-4
4.3.3 Transmission Schedule ............................................................................. 4-4
4.3.4 Message Fields ......................................................................................... 4-4
4.3.4.1 Main Field ................................................................................................................. 4-4
4.3.4.2 Rotating Fields .......................................................................................................... 4-6
4.3.5 SGBs and Programming Adaptors ........................................................... 4-6
4.3.6 SGBs Message Format for Transmission in the Ground Segment ........... 4-7
4.4
SGB Coding Examples ......................................................................................... 4-7
4.4.1 EPIRBs ..................................................................................................... 4-7
4.4.2 ELTs ......................................................................................................... 4-7


4.4.3 ELT(DT)s ................................................................................................. 4-7
4.4.4 PLBs ......................................................................................................... 4-7
5.
BEACON REGISTRATION ............................................................................. 5-1
5.1
Purpose of Beacon Registration ........................................................................... 5-1
5.2
General Principals for Registering 406 MHz Beacons ........................................ 5-1
5.2.1 Where to Register 406 MHz Beacons ...................................................... 5-1
5.2.2 Country of Registration – Coding Procedure ........................................... 5-2
5.2.3 Control and Updating of Registered Information .................................... 5-2
5.2.4 Access to Registration Databases ............................................................. 5-2
5.2.5 Content of National Registration Databases ............................................ 5-3
5.2.6 Accuracy of Beacon Identification (15 / 23 Hex ID) ............................... 5-3
5.3
Cospas-Sarsat International 406 MHz Beacon Registration Database
(IBRD) (www.406registration.com) ...................................................... 5-3
5.3.1 IBRD Management Policy ....................................................................... 5-4
5.3.2 Updating Registration Information in IBRD ............................................ 5-5
6.
406 MHz BEACON TYPE APPROVAL ......................................................... 6-1
6.1
Objectives and Scope of Type Approval .............................................................. 6-1
6.2
Cospas-Sarsat Type Approval Testing ................................................................. 6-1
6.3
Cospas-Sarsat Type Approval Certificate ............................................................ 6-2
6.4
National Type Approval ....................................................................................... 6-2
7.
GENERAL GUIDELINES TO ADMINISTRATIONS,
MANUFACTURERS AND DISTRIBUTIONS ................................................ 7-1
7.1
Guidelines to Administrations .............................................................................. 7-1
7.2
Guidelines to Manufacturers and Distributors ..................................................... 7-2
LIST OF ANNEXES
ANNEX A : EXAMPLES OF 406 MHz BEACON CODES .................................................. A-1
ANNEX B : MODIFIED-BAUDOT CODE ............................................................................ B-1
ANNEX C : BINARY CODED DECIMAL............................................................................ C-1
ANNEX D : GUIDELINES ON THE USE OF THE BEACON REGISTRATION
CHECKSUM ..................................................................................................... D-1
LIST OF FIGURES


Figure 3.1: General Format of the 406 MHz Beacon Message ................................................... 3-2
Figure 3.2: Standard Preamble Coding ........................................................................................ 3-9
Figure 3.3: Example of Country Code ....................................................................................... 3-11
Figure 3.4: Short Message Non-Protected Data Field ............................................................... 3-13
Figure 3.5: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols ........... 3-17
Figure 3.6: Coding the Maritime User Protocol with MMSI ..................................................... 3-19
Figure 3.7: Coding the EPIRB Serial Identification .................................................................. 3-20
Figure 3.8: Coding the Maritime User Protocol with the Radio Call Sign ................................... 3-22
Figure 3.9: Coding the Radio Call Sign User Protocol ................................................................ 3-23
Figure 3.10: Coding ELTs with the Beacon Serial Number ........................................................ 3-24
Figure 3.11: Coding ELTs with the Aircraft Operator Designator and Serial Number ................ 3-25
Figure 3.12: Coding ELTs with the Aircraft 24-bit Address ..................................................... 3-26
Figure 3.13: Coding ELTs with the Aircraft Nationality and Registration Marking................. 3-27
Figure 3.14: Coding PLBs with the Serial User Protocol .......................................................... 3-28
Figure 3.15: Coding the Test User Protocol .............................................................................. 3-29
Figure 3.16: Coding the National User Protocol ......................................................................... 3-30
Figure 3.17: Outline of Location Protocols ............................................................................... 3-31
Figure 3.18: Coding the User-location Protocols’ Second Protected Data Field (PDF-2) ........ 3-33
Figure 3.19: Coding the Standard Location Protocol with MMSI............................................. 3-34
Figure 3.20: Coding a Ship Security Alert System (SSAS) Beacon .......................................... 3-35
Figure 3.21: Coding the Standard Location Protocol with the 24-bit Aircraft Address ............ 3-35
Figure 3.22: Coding the Standard Location Protocol with the Aircraft Operator Designator and
Serial Number .................................................................................................... 3-36
Figure 3.23: Coding the ELT/EPIRB/PLB Serial Identification Data ....................................... 3-36
Figure 3.24: Coding the Position Data in the Standard Location Protocols .............................. 3-37
Figure 3.25: Coding the National Location Protocol ................................................................. 3-38
Figure 3.26: Coding the RLS Location Protocol ....................................................................... 3-41
Figure 3.27: Coding the Position Data in the RLS Location Protocols ..................................... 3-41
Figure 3.28: Coding the RLS Data in the RLS Location Protocols ........................................... 3-43
Figure 3.29: Coding the ELT(DT) Location Protocol with the 24-bit Aircraft Address ........... 3-44
Figure 3.30: Coding the ELT(DT) Location Protocol with the Aircraft Operator Designator and
Serial Number .................................................................................................... 3-45
Figure 3.31: Coding the C/S Serial Identification Data in the ELT(DT) Location Protocol ..... 3-45
Figure 3.32: Coding the Position Data in the ELT(DT) Location Protocols ............................. 3-46
Figure 3.33: Coding the Supplementary Data in the ELT(DT) Location Protocols .................. 3-47
Figure 4-1: Burst general structure .............................................................................................. 4-2
Figure 4-2: Message content bits ................................................................................................. 4-3
LIST OF TABLES
Table 3.1: List of Available Coding Options for User Protocols ........................................... 3-3
Table 3.2: List of Available Coding Options for the Location Protocols (1/4) ........................... 3-4
Table 3.3: Format Flag and Protocol Flag Combinations .......................................................... 3-11
Table 3.4: Maritime Emergency Codes ................................................................................. 3-14


Table 3.5: Non-Maritime Emergency Codes ............................................................................. 3-14
Table 3.6: Auxiliary Radio-locating Device Code .................................................................... 3-18
Table 3.7: Encoding of Position Data ........................................................................................ 3-32
Table 4.1: Transmission Schedule ............................................................................................... 4-4
Table 5.1: Example of Basic Information to be Recorded and .................................................... 5-6
Table 5.2: Example of Ship Categories for Database Description .............................................. 5-7
Table 5.3: Example of Ship Radio Installation Description ........................................................ 5-7
Table B.1: Modified-Baudot Code ............................................................................................. B-1
Table D.1: Translation of characters to ASCII Decimal Values ................................................ D-3
Table D.2: Standard Translation of 4 Bits Blocks to Hexadecimal Characters .......................... D-3
Table D.3: Example UIN Inputs and Resulting Checksums ....................................................... D-3

1-1

1.
INTRODUCTION
1.1
Overview
This document describes the various methods of coding 406 MHz distress beacons for maritime,
aviation or personal applications and provides guidelines for setting up a 406 MHz beacon
registration database. The procedure to be followed by manufacturers to obtain a Cospas-Sarsat
type approval certificate is also described, together with recommendations for administrations
regarding national type approval of 406 MHz beacons.
1.2
Scope
The purpose of this document is to inform administrations, Cospas-Sarsat equipment
manufacturers and users on practical matters concerning the coding, registration and type approval
of 406 MHz beacons. It is not intended to replace the current System documents which provide
the specification for 406 MHz beacons, including all the technical details and options for
applicable coding protocols (C/S T.001, T.015, and T.018), or the procedure for Cospas-Sarsat
type approval testing (C/S T.007, and T.021\*).
Some background information on the Cospas-Sarsat 406 MHz System is given in section 2 of these
guidelines. The basic information required for coding and registering 406 MHz beacons is
presented in sections 3 and 4, and a guide for manufacturers requesting Cospas-Sarsat type
approval testing is provided in section 5. General guidelines to administrations, manufacturers and
distributors are included in section 6.
* Second Generation Beacons have not yet been approved by the programme and therefore it is not currently possible
to get a Cospas-Sarsat approval for a C/S T.018 beacon in accordance with C/S T.021.

1-2

1.3
Reference Documents
The following documents contain more detailed information on 406 MHz beacons and should be
used for reference, as necessary, on specific matters not fully covered by these guidelines:
C/S T.001, Specification for Cospas-Sarsat 406 MHz Distress Beacons;
C/S T.007, Cospas-Sarsat 406 MHz Distress Beacon Type Approval Standard;
C/S T.015, Cospas-Sarsat Specification and Type Approval Standard for 406 MHz
Ship Security Alert (SSAS) Beacons;
C/S T.018, Specification for Second-Generation Cospas-Sarsat 406-MHz Distress
Beacons;
C/S T.021, Cospas-Sarsat Second Generation 406-MHz Distress Beacon Type
Approval Standard;
C/S D.004, Operations Plan for the Cospas-Sarsat International 406 MHz Beacon
Registration Database;
C/S G.003, Introduction to the Cospas-Sarsat System;
C/S S.011, Cospas-Sarsat Glossary; and
C/S S.007, Handbook of Beacon Regulations\*.
These documents may be obtained from the Cospas-Sarsat Secretariat or downloaded from the
Cospas-Sarsat web site: www.cospas-sarsat.int (except item (h)).
1.4
Summary of the Cospas-Sarsat Guidelines on Beacon Coding, Registration and
Type Approval
National authorities are responsible for all regulatory matters concerning the use of 406 MHz
beacons. This includes:
issuing equipment specifications and carriage requirements;
testing and type approving beacon models in accordance with Cospas-Sarsat,
IMO, ICAO, ITU and/or their own national performance requirements;
defining which coding protocols (see section 3) are applicable;
allocating identification codes (see sections 3.3 and 3.4) as appropriate; and
defining and implementing registration procedures (see section 4).
When developing national regulations, Administrations are invited to consider the guidelines
provided herein and other information available from the Cospas-Sarsat Secretariat, concerning type
approved beacons, applicable coding protocols and registration procedures recommended by the
relevant international organizations.
* Note: Document updated semi-annually.

![Image 1 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_1.png)

![Image 2 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_2.png)

![Image 3 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_3.png)

![Image 4 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_4.png)

![Image 5 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_5.png)

![Image 6 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_6.png)

![Image 7 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_7.png)

![Image 8 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_8.png)

![Image 9 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_9.png)

![Image 10 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_10.png)

![Image 11 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_11.png)

![Image 12 from page 9](/images/cospas-sarsat/G-series/G005/G005_page_9_img_12.png)

1-3

The Cospas-Sarsat Secretariat maintains a list of points of contact of a number of administrations
responsible for 406 MHz beacon matters\*. All countries adopting the use of 406 MHz beacons should
inform the Cospas-Sarsat Secretariat of their point(s) of contact for 406 MHz beacon matters, for
inclusion in this list.
In summary, Administrations are invited to:
establish appropriate regulations for the use of 406 MHz beacons in their country;
test First Generation Beacons (FGBs) for type approval according to the Cospas-
Sarsat specification and type approval standard (C/S T.001 and C/S T.007), or
authorise the use of only those 406 MHz beacons which have received a Cospas-
Sarsat type approval certificate, as published on the Cospas-Sarsat website at:
www.cospas-sarsat.int;
test Second Generation Beacons (SGBs) for type approval according to the
Cospas-Sarsat specification and type approval standard (C/S T.018 and C/S
T.021), or authorise the use of only those 406 MHz beacons which have received
a Cospas-Sarsat type approval certificate, as published on the Cospas-Sarsat
website at www.cospas-sarsat.int;
perform additional tests, as appropriate, to ensure that the beacons comply with
their specific requirements for the corresponding application, and/or consider
whether the same beacon model has already been tested and approved by other
administrations for that application;
select the beacon coding protocols they wish to use in their country;
establish and maintain a beacon register or co-ordinate with other administrations
for the establishment and maintenance of a "regional" registration database; and
provide the Cospas-Sarsat Secretariat with the address(es) of their point(s) of
contact for 406 MHz beacon matters (i.e. type approval, coding and registration).
- END OF SECTION 1 -
* Note: See “Handbook of Beacon Regulations”, C/S S.007 (Should refer to the C/S website for the POC).

![Image 1 from page 10](/images/cospas-sarsat/G-series/G005/G005_page_10_img_1.png)

![Image 2 from page 10](/images/cospas-sarsat/G-series/G005/G005_page_10_img_2.png)

![Image 3 from page 10](/images/cospas-sarsat/G-series/G005/G005_page_10_img_3.png)

![Image 4 from page 10](/images/cospas-sarsat/G-series/G005/G005_page_10_img_4.png)

![Image 5 from page 10](/images/cospas-sarsat/G-series/G005/G005_page_10_img_5.png)

![Image 6 from page 10](/images/cospas-sarsat/G-series/G005/G005_page_10_img_6.png)

![Image 7 from page 10](/images/cospas-sarsat/G-series/G005/G005_page_10_img_7.png)

2-1

2.
BACKGROUND INFORMATION ON THE 406 MHz SYSTEM
2.1
406 MHz Beacons
The use of the 406 MHz system shall be in accordance with the appropriate provisions of the ITU
Radio Regulations, and the alerting signals shall be in accordance with relevant ITU-R
Recommendations.
406 MHz distress beacons are normally designed and constructed either as Emergency Position-
Indicating Radio Beacons (EPIRBs) for maritime applications, as Emergency Locator
Transmitters (ELTs) for aviation applications, or as Personal Locator Beacons (PLBs) for personal
use.
406 MHz distress beacons (C/S T.001 or C/S T.015) transmit a half-second burst of data every 50
seconds with the exception of ELT(DT)s which transmit of a variable schedule. All SGB 406-MHz
distress beacons (C/S T.018) transmit, on a variable schedule, a one-second burst of data. The
Cospas-Sarsat satellites relay this data, referred to as the beacon message, to Cospas-Sarsat earth
receiving stations called Local User Terminals (LUTs) which automatically examine the beacon
message and determine the geographical location of the distress beacon. To ensure that the System
performance requirements are met and to maintain the quality of alert and location data forwarded
to search and rescue (SAR) services, it is essential that only beacons which satisfy Cospas-Sarsat
specification and type approval requirements are used in the System. The list of Cospas-Sarsat
type approved beacons is published on the Cospas-Sarsat website at:
www.cospas-sarsat.int.
2.2
Beacon Identification
Each message transmitted by a 406 MHz beacon must uniquely identify the beacon. The complete
beacon identification code includes the: protocol flag, protocol code, country code, and other
identification data, all of which are encoded in the first protected data field (PDF-1) of the 406
MHz message (see section 3.2.3).
Identification data can be provided in various alphanumeric formats, depending on the coding
protocol required by the responsible administration (see section 3). It is encoded together with the
country code and other information in the beacon message in binary format. However, for the
purpose of transmission to SAR services in the alert message produced by Cospas-Sarsat, the
unique identification of a 406 MHz beacon encoded in bits 26-85 of the beacon message is
provided as a 15 hexadecimal character string, referred to as the beacon 15 Hex Identification, or
beacon 15 Hex ID (see also item 3.2.3.4).

2-2

The beacon 15 Hex ID is used:
to correlate all the messages transmitted by a particular beacon;
to provide SAR services with information on the ship, the aircraft or the beacon
owner in case of beacon alert (see section 2.3); and
to retrieve information from the beacon registration databases.
A SGB (C/S T.018) beacon message also contains a unique Hex ID for the beacon. SGBs Hex IDs
are provided as a 23 Hex Identification, as described in Table 3.10 of document C/S T.018. The
generation of a 23 Hex ID makes use of an FGB spare protocol, thus ensuring that the truncation
of a 23 Hex ID to form a SGB 15 Hex ID will result in a unique Hex Identification for all SGB
messages and ensures that they can be distinguished from FGB messages.
2.3
Operational Use of Beacon Registration Databases
It is crucial that 406 MHz distress beacons are registered in recognized beacon registration
databases that are accessible to search and rescue (SAR) authorities 24 hours per day. The
information contained in these databases concerning the beacon, its owner, and the vehicle/vessel
on which the beacon is mounted is vital for the effective use of SAR resources. The unique
information encoded in the Cospas-Sarsat 406 MHz beacon message provides the information
necessary to identify the register that should hold the registration information for that beacon, and
it is also the unique key used for retrieving the registration details.
Both the International Maritime Organization (IMO) and the International Civil Aviation
Organization (ICAO) require administrations authorising the use of 406 MHz beacons to make
provisions for registering 406 MHz beacons that are under their jurisdiction. For beacon owners
in countries that do not operate national registers, Cospas-Sarsat has implemented an International
406 MHz Beacon Registration Database (IBRD). A more detailed description of the registration
process, requirements for 406 MHz beacon registers, and an introduction to the IBRD is provided
at section 4. Details can be found in document C/S D.004 (Operations Plan for the Cospas-Sarsat
International 406 MHz Beacon Registration Database).
As mentioned above, because a beacon may be transmitting from anywhere on the globe, access
to beacon registration databases must be provided to SAR services world-wide, 24 hours per day
and with minimum delay. In order to achieve this objective, the following requirements should be
met by all countries which authorise the use of 406 MHz distress beacons:
all beacons should be coded in accordance with the Cospas-Sarsat specification
(C/S T.001, C/S T.015 or C/S T.018) and national requirements, and include the
country code assigned to the country of beacon registration (see section 3.2.3.2)
and additional identification data, which together forms a unique beacon 15 Hex
ID (see section 3.2.3.4);

![Image 1 from page 12](/images/cospas-sarsat/G-series/G005/G005_page_12_img_1.png)

![Image 2 from page 12](/images/cospas-sarsat/G-series/G005/G005_page_12_img_2.png)

![Image 3 from page 12](/images/cospas-sarsat/G-series/G005/G005_page_12_img_3.png)

![Image 4 from page 12](/images/cospas-sarsat/G-series/G005/G005_page_12_img_4.png)

2-3

all beacons should be registered with the appropriate administration, or in the
International Beacon Registration Database (IBRD) if the administration has
chosen to use the IBRD for beacons with their country code(s) (see section 4);
appropriate points of contact should be designated, and identified to the
Cospas-Sarsat Secretariat\*, for providing guidance to beacon owners in respect
of national registration and coding; and
procedures should be defined for communicating beacon registration database
information to SAR services upon request; details of the registry's point of
contact should be provided to the Cospas-Sarsat Secretariat for the information
of SPOCs and Cospas-Sarsat MCCs.
The accuracy of information contained in the registration databases should also be checked
periodically, possibly as part of any mandatory periodic beacon testing.
2.4
Encoded Position Data
Beacon messages encoded with the location protocols include position data in addition to the
beacon identification data. Such position data can be derived from a satellite navigation system,
such as GPS, Galileo or GLONASS, using either a receiver integrated into the beacon, or an
external navigation receiver connected to the beacon.
The incorporation of the position data into the beacon message provides locating capability for
406 MHz alerts received through geostationary satellites in the 406 MHz GEOSAR system.
The incorporation of the position data into the beacon messages also provides supplemental
location data for the independent locations that are generated using the LEOSAR and MEOSAR
system. This data also provides the primary location information for rapidly moving aviation
distress tracking (ELT(DT)) beacons.
More than 75% of the estimated global beacon population deployed include an encoded location
capability, and the proportion of the beacon population which include this capability is expected to
increase in the future.
- END OF SECTION 2 -
* For inclusion in the web list available on www.cospas-sarsat.int

![Image 1 from page 13](/images/cospas-sarsat/G-series/G005/G005_page_13_img_1.png)

![Image 2 from page 13](/images/cospas-sarsat/G-series/G005/G005_page_13_img_2.png)

![Image 3 from page 13](/images/cospas-sarsat/G-series/G005/G005_page_13_img_3.png)

3-1

3.
FIRST GENERATION 406-MHz BEACON CODING (FGB)
3.1
C/S T.001 or C/S T.015 Beacon Types
Cospas-Sarsat 406 MHz beacons can be used in different environments and for a variety of
applications such as EPIRBs and Ship Security Alert System (SSAS) beacons that service the
maritime environment, ELTs and ELT(DT)s (aviation) or PLBs (personal use). The specification
of the distress signal characteristics (document C/S T.001), which ensures that all 406 MHz
beacons are compatible with the Cospas-Sarsat Space Segment, is applicable to all types of
beacons. However, different user groups have different needs; hence the need for various coding
protocols. To satisfy these requirements, the Cospas-Sarsat specification provides for various
coding options which are divided in two groups of coding protocols:
User Protocols, described in section 3.3; and
Location Protocols, described in section 3.4.
The user protocols can be used for encoding the beacon identification and other data in the digital
message transmitted by a 406 MHz distress beacon, but do not allow for encoding beacon position
data. The coding options for user protocols are listed in Table 3.1 and further described in section
3.3.
The location protocols can be used for encoding beacon position data, in addition to the beacon
identification data, in the digital message transmitted by a 406 MHz distress beacon. The coding
options for location protocols are listed in Table 3.2 and further described in section 3.4.
User protocols  are implemented using the short message format whereas location protocols are
implemented using the long message format, as described in Figure 3.1.
All protocols have the general structure of the 406 MHz digital message described in section 3.2
of this document.
The choice of the protocol option to be used in a particular beacon type depends on:
the user category (maritime, aviation, or personal);
the method used to provide beacon identification data as required by the
responsible administration; and
the required resolution of encoded position data (only for location protocols).
Administrations will normally specify which coding protocols can be used for the applications that
they authorise. Manufacturers of 406 MHz beacons should contact the appropriate national
authorities to determine how beacons should be coded for each country. The document C/S S.007
“Handbook of Beacon Regulations”, which is semi-annually updated by the Cospas-Sarsat
Secretariat, provides a list of points of contact (including addresses and telephone numbers) for
beacon matters in a number of countries.

![Image 1 from page 14](/images/cospas-sarsat/G-series/G005/G005_page_14_img_1.png)

![Image 2 from page 14](/images/cospas-sarsat/G-series/G005/G005_page_14_img_2.png)

![Image 3 from page 14](/images/cospas-sarsat/G-series/G005/G005_page_14_img_3.png)

3-2

Administrations should not authorise coding options which are not currently allocated or permitted
by the Cospas-Sarsat specification for 406 MHz beacons (C/S T.001).
Figure 3.1: General Format of the 406 MHz Beacon Message
3.1.a:
Fields of the Short Message Format
Bit
Synchronization
Frame
Synchronization
First Protected Data Field (PDF-1)
BCH-1
Non-Protected
Data Field
Unmodulated
Carrier
(160 ms)
Bit
Synchronization
Pattern
Frame
Synchronization
Pattern
Format
Flag
Protocol
Flag
Country
Code
Identification
Data
21-Bit
BCH
code
Emergency Code/
National Use or
Supplement. Data
Bit No.
1-15
16-24


27-36
37-85
86-106
107-112
15 bits
9 bits
1 bit
1 bit
10 bits
49 bits
21 bits
6 bits
3.1.b:
Fields of the Long Message Format
Bit
Synchronization
Frame
Synchronization
First Protected Data Field (PDF-1)
BCH-1
Second Protected Data
Field (PDF-2)
BCH-2
Unmodulated
Carrier
(160 ms)
Bit
Synchronization
Pattern
Frame
Synchronization
Pattern
Format
Flag
Protocol
Flag
Country
Code
Identification or
Identification
plus Position
21-Bit
BCH
code
Supplementary and
Position or National Use
Data
12-Bit
BCH code
Bit No.
1-15
16-24


27-36
37-85
86-106
107-132
133-144
15 bits
9 bits
1 bit
1 bit
10 bits
49 bits
21 bits
26 bits
12 bits
In addition to the available coding options listed in Table 3.1 and Table 3.2, a "national" user
protocol and a specific "orbitography" protocol have been defined.
The national user protocol allows for coding data which is defined and controlled by national
administrations. It is described further in section 3.3.6.
The orbitography protocol is not described in this document as its use is restricted to a small
number of orbitography beacons under the control of Cospas-Sarsat System operators.

3-3

Table 3.1: List of Available Coding Options for User Protocols
Application
Identification Data
Protocols
Figure No.
EPIRBs
(Maritime)
MMSI
Maritime User
Fig. 3.6
Unique EPIRB Serial
Number\*
Serial User
Fig. 3.7
Radio Call Sign
a. Maritime User
b. Radio Call Sign
Fig. 3.8
Fig. 3.9
ELTs
(Aviation)
Unique ELT Serial
Number\*
Serial User
Fig. 3.10
Aircraft Operator
Designator & Serial
Number\*
Serial User
Fig. 3.11
Aircraft 24-bit Address
Serial User
Fig. 3.12
Aircraft Registration
Marking
Aviation User
Fig. 3.13
PLBs
(Personal)
Unique PLB Serial
Number\*
Serial User
Fig. 3.14
Test†
Any Unique Combination
All
Fig. 3.15
* Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations
must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code.
Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas-
Sarsat type approval certificate number assigned to that beacon model.
† The test protocol is used in trials (to be co-ordinated with the appropriate MCC) which involve live transmissions to
satellites.  It is described further in section 3.3.5.

3-4

Table 3.2: List of Available Coding Options for the Location Protocols (1/4)
Application
Identification
Data
Location Data
Protocols
Figure No.
EPIRBs
(Maritime)
MMSI
4-minute resolution encoded
in PDF-2
User-location
Fig. 3.6
Fig. 3.18
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 15-minute
resolution encoded in PDF-1
Standard Location Fig. 3.19
Fig. 3.24
Unique EPIRB
Serial Number
4-minute resolution encoded
in PDF-2
User-location
Fig. 3.7
Fig. 3.18
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 15 minute
resolution encoded in PDF-1
Standard Location Fig. 3.23
Fig. 3.24
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 30-minute
resolution encoded in PDF-1
RLS Location
Fig. 3.26
Fig. 3.27
Fig. 3.28
Radio Call Sign
4-minute resolution encoded
in PDF-2
User-location
Fig. 3.8
Fig. 3.9
Fig. 3.18
Serial Number\*
Assigned by
Administration
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 2-minute
resolution encoded in PDF-1
National Location Fig. 3.25
SSAS
(Maritime)
MMSI
position to a 15-minute
resolution encoded in PDF-1
and offset to a 4-second
resolution encoded in PDF-2
Standard Location Fig. 3.20
* Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations
must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code.
Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas-
Sarsat type approval certificate number assigned to that beacon model.

3-5

Table 3.2: List of Available Coding Options for the Location Protocols (2/4)
Application
Identification
Data
Location Data
Protocols
Figure No.
ELTs
(Aviation)
Unique ELT
Serial Number\*
4-minute resolution encoded
in PDF-2
User-location
Fig. 3.10
Fig. 3.18
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 15-minute
resolution encoded in PDF-1
Standard Location Fig. 3.23
Fig. 3.24
position offset to a 4 second
resolution encoded in PDF-2
in addition to a 30 minute
resolution encoded in PDF-1
RLS Location
Fig. 3.26
Fig. 3.27
Fig. 3.28
Aircraft Operator
Designator &
Serial Number\*
4 minute resolution encoded
in PDF-2
User-location
Fig. 3.11
Fig. 3.18
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 15-minute
resolution encoded in PDF-1
Standard Location Fig. 3.22
Fig. 3.24
Aircraft 24-bit
Address
4 minute resolution encoded
in PDF-2
User-location
Fig. 3.12
Fig. 3.18
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 15-minute
resolution encoded in PDF-1
Standard Location Fig. 3.21
Fig. 3.24
Aircraft
Registration
Marking
4 minute resolution encoded
in PDF-2
User-location
Fig. 3.13
Fig. 3.18
Serial Number\*
Assigned by
Administration
position offset to a 4-second
resolution encoded in PDF-2
in addition to a 2-minute
resolution encoded in PDF-1
National Location Fig. 3.25
* Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations
must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code.
Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas-
Sarsat type approval certificate number assigned to that beacon model.

3-6

Table 3.2: List of Available Coding Options for the Location Protocols (3/4)
Application
Identification
Data
Location Data
Protocols
Figure No
PLBs
(Personal)
Unique PLB
Serial Number\*
4-minute resolution
encoded in PDF-2
User-location
Fig. 3.14
Fig. 3.18
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
15-minute resolution
encoded in PDF-1
Standard Location Fig. 3.23
Fig. 3.24
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
30-minute resolution
encoded in PDF-1
RLS Location
Fig. 3.26
Fig. 3.27
Fig. 3.28
Serial Number\*
Assigned by
Administration
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
2-minute resolution
encoded in PDF-1
National Location Fig. 3.25
RLS Test
Test
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
30-minute resolution
encoded in PDF-1
RLS Location
Fig. 3.26
Fig. 3.27
Fig. 3.28
Test†
Any Unique
Combination
All
ELT(DT)
Test
Test
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
30-minute resolution
encoded in PDF-1
ELT(DT) Location Fig. 3.29 to
Fig. 3.31
Fig. 3.32
Fig. 3.33
* Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations
must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code.
Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas-
Sarsat type approval certificate number assigned to that beacon model.
† The test protocol is used in trials (to be co-ordinated with the appropriate MCC) which involve live transmissions
to satellites.  It is described further in section 3.3.5.

3-7

Table 3.2: List of Available Coding Options for the Location Protocols (4/4)
Application Identification
Data
Location Data
Protocols
Figure No
ELT
(Distress
Tracking
(DT))
Aircraft 24-bit
Address
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
30-minute resolution
encoded in PDF-1
ELT(DT) Location Fig. 3.29
Fig. 3.32
Fig. 3.33
Aircraft
Operator
Designator &
Serial Number
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
30-minute resolution
encoded in PDF-1
ELT(DT) Location Fig. 3.30
Fig. 3.32
Fig. 3.33
Unique ELT
Serial Number\*
position offset to a 4-second
resolution encoded in
PDF-2 in addition to a
30-minute resolution
encoded in PDF-1
ELT(DT) Location Fig. 3.31
Fig. 3.32
Fig. 3.33
* Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations
must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code.
Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas-
Sarsat type approval certificate number assigned to that beacon model.

3-8

3.2
General Coding Requirements
3.2.5
General Format and Field Definition of the 406 MHz Beacon Message
The message transmitted by a Cospas-Sarsat 406 MHz beacon can be encoded either in a short
message format or a long message format, as shown in Figure 3.1.
3.2.5.1 The short message format consists of:
unmodulated carrier signal (160 ms), bit synchronization pattern (bits 1 to 15)
and frame synchronization pattern (bits 16 to 24), often referred to as the
preamble;
the first protected data field (PDF-1) which includes the format and protocol
flags, the country code, and beacon identification data (bits 25 to 85);
the first BCH error correcting field (BCH-1) associated with the PDF-1 (encoded
in bits 86 to 106); and
the non-protected data field (variable / optional or supplementary data contained
in bits 107 to 112).
3.2.5.2 The long message format consists of:
the preamble;
the first protected data field (PDF-1);
the first BCH error correcting field (BCH-1);
the second protected data field (PDF-2) which includes supplementary and
position data of the location protocols, or information defined in national
requirements (encoded in bits 107 - 132); and
the second BCH error correcting field BCH-2 associated with the PDF-2
(encoded in bits 133 to 144).
The 82 bits of the combined PDF-1 and BCH-1 are also referred to as the first protected
field. The 38 bits of the combined PDF-2 and BCH-2 are also referred to as the second
protected field.

![Image 1 from page 21](/images/cospas-sarsat/G-series/G005/G005_page_21_img_1.png)

![Image 2 from page 21](/images/cospas-sarsat/G-series/G005/G005_page_21_img_2.png)

![Image 3 from page 21](/images/cospas-sarsat/G-series/G005/G005_page_21_img_3.png)

![Image 4 from page 21](/images/cospas-sarsat/G-series/G005/G005_page_21_img_4.png)

![Image 5 from page 21](/images/cospas-sarsat/G-series/G005/G005_page_21_img_5.png)

![Image 6 from page 21](/images/cospas-sarsat/G-series/G005/G005_page_21_img_6.png)

3-9

3.2.2
Preamble
3.2.2.1 Standard Preamble
The preamble of the 406 MHz digital message allows the receiver-processor to:
detect the incoming signal and lock on its frequency, using the unmodulated
carrier transmission;
lock on the phase and bit timing of the modulation using the bit synchronization
pattern; and
identify the first data bit of the message using the frame synchronization pattern.
Therefore, this preamble must be fixed and identical for all Cospas-Sarsat 406 MHz
beacons, and encoded according to the format of Figure 3.2.
Figure 3.2: Standard Preamble Coding
3.2.2.2 Self-Test Mode Preamble
A 406 MHz beacon should be designed to perform a short self-test. The self-test
transmission may consist of a short duration emission of a single burst. If the beacon
transmits in the self-test mode, the signal must have a frame synchronization pattern of
011010000 to ensure that the satellite or ground equipment will not process this test
transmission. This eliminates the risk of a false alert being generated by the self-test burst.
Unless prior co-ordination has been accomplished in accordance with Cospas-Sarsat
document C/S A.004 “Cospas-Sarsat System Exercising”, no other test transmissions are
permitted when using a beacon coded with an "operational" protocol (see the "test"
protocol coding in sections 3.3.5 and 3.4.7), as any such test could generate a false alert.
In addition, self-test transmissions must be kept to a minimum as they interfere with "real"
406 MHz distress alerts.
In the self-test transmission mode the complete test transmission must be limited to one
burst only of a maximum duration of 440 ms (+1%) for a short message or 520 ms (+1%)
for a long message. If a 440 ms transmission is used for a beacon encoded with the long
format message, the message should be truncated without changing the format flag bit.
* The self-test mode described in section 3.2.2.2 should not be confused with the "test" protocols described in sections
3.3.5 and 3.4.5 which are processed by Cospas-Sarsat satellites.
160 ms
Bits 1-15
Bits 16-24
Unmodulated Carrier
Bit Synchronization Pattern
Frame Synchronization Pattern
- unmodulated carrier:
160 ms;
- bits 1 to 15:
all set to "1";
- bits 16 to 24:
set to the pattern "000101111" (except in self-test mode \*).

![Image 1 from page 22](/images/cospas-sarsat/G-series/G005/G005_page_22_img_1.png)

![Image 2 from page 22](/images/cospas-sarsat/G-series/G005/G005_page_22_img_2.png)

![Image 3 from page 22](/images/cospas-sarsat/G-series/G005/G005_page_22_img_3.png)

3-10

For location protocols, the default bits should replace the position data in encoded
position data fields of the self-test mode messages. Therefore, the content of the self-test
message shall always provide the beacon 15 Hex ID.
3.2.3
First Protected Data Field (PDF-1)
3.2.3.1 General Structure of the First Protected Data Field
(PDF-1)
The first protected data field (PDF-1) (bits 25 to 85) includes (see Figure 3.1):
the format flag (bit 25) which indicates the use of the short message or long
message formats as described in Table 3.3;
the protocol flag (bit 26) which is set to "1" for all user protocols and user-
location protocols, and to “0” for all other location protocols (i.e. standard
location protocols and national location protocol);
the country code which is a three-digit decimal number (see section 3.2.3.2)
encoded in bits 27 to 36 in binary notation;
identification data: a number of bits (different for each protocol, depending on
the method used to encode the beacon 15 Hex ID: see Figures 3.5 and 3.17)
which must remain fixed as this information will:
• provide, with the preceding flags and country code, a unique identification
of each beacon transmission and of the corresponding Doppler
measurements used by LUTs to compute the beacon location,
• permit a fast and reliable identification of the vehicle / user in distress, in
order to obtain all information required to assist search and rescue
operations,
• permit a fast identification of the transmitter in case of false alert, allowing
its cancellation at minimum cost to SAR services; and
position data: a number of bits (different for each protocol, depending on the
method used to encode the beacon 15 Hex ID: see Figure 3.17) which will be
used in standard location protocols, national location protocols, RLS location
protocols, and ELT(DT) location protocols to encode beacon position data.
In the case of user and user-location protocols, the PDF-1 may also include information
which is specific to an application or a beacon type (e.g. information on auxiliary radio-
locating devices available in that beacon).
3.2.3.2 Format Flag, Protocol Flag and Country Code
The bit allocations for the format flag, protocol flag and country code are identical in all
beacon protocols. The possible combinations of format flag and protocol flag values are
summarised in Table 3.3.

![Image 1 from page 23](/images/cospas-sarsat/G-series/G005/G005_page_23_img_1.png)

![Image 2 from page 23](/images/cospas-sarsat/G-series/G005/G005_page_23_img_2.png)

![Image 3 from page 23](/images/cospas-sarsat/G-series/G005/G005_page_23_img_3.png)

![Image 4 from page 23](/images/cospas-sarsat/G-series/G005/G005_page_23_img_4.png)

![Image 5 from page 23](/images/cospas-sarsat/G-series/G005/G005_page_23_img_5.png)

3-11

Table 3.3: Format Flag and Protocol Flag Combinations
Format Flag (bit 25) →
Protocol Flag (bit 26) 

(short)

(long)

(protocol code: bits 37-40)
No longer allowed
Standard Location Protocols
National Location Protocol
RLS Location Protocol
ELT(DT) Location Protocol

(protocol code: bits 37-39)
User Protocols
User-Location Protocols
National and Test User Protocols
The country code is part of every beacon identification data. This code is the 3-digit
decimal
number
allocated
to
each
country/territory
by
the
International
Telecommunication Union (ITU) and listed as Maritime Identification Digits (MID) in
Appendix 43 of the ITU Radio Regulations. The up-to-date list of MIDs is available from
the ITU web site at:
http://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/mid.aspx
The country code is encoded in binary notation in bits 27 to 36 of the message, with the
least significant bit on the right. The country code indicates the administration
maintaining the beacon registration data base (see section 4). If the appropriate
registration database exists, the country code should always match the flag of the vessel
or aircraft.
The example presented in Figure 3.3 shows the country code for the United Kingdom,
where: MID=232 (i.e., decimal number "232" coded "0011101000" in binary notation).
Figure 3.3: Example of Country Code
Bits


3-12

3.2.3.3 Identification Data and Position Data
The unique Beacon Identification consists of the protocol flag, country code and the fixed
(non-variable) bits of identification data specific for each protocol. In some location
protocols, PDF-1 also includes variable bits which provide for the encoding of beacon
position (see Figure 3.17). Therefore, the interpretation of data contained in the PDF-1
requires determining which protocol is being used, as indicated by the setting of the
protocol flag (bit 26) and the protocol code (bits 37 to 40 for standard, national, RLS, and
ELT(DT) location protocols (long format), and bits 37 to 39 for all user protocols,
including user-location protocols).
The bit settings for the protocol code and the bit assignments for identification data and
position data are described in sections 3.3 and 3.4.
Some user protocols (i.e. the serial user protocol and the national user protocol) have, as
part of the identification data, data fields that may be defined by administrations to fulfil
specific identification requirements. Administrations should inform the Cospas-Sarsat
Secretariat of their national identification coding schemes to ensure that these schemes
remain compatible with the general Cospas-Sarsat coding requirements.
3.2.3.4 Fifteen Hexadecimal Character Beacon Identification
The fifteen hexadecimal character representation of PDF-1 excluding bit 25 (message
format flag) is used for the purpose of distribution of distress alerts over Cospas-Sarsat
ground communication network. It is referred to as the beacon 15 Hex ID. The beacon 15
Hex ID must uniquely identify each 406 MHz beacon. The beacon 15 Hex ID is derived
from a 406 MHz message by presenting every 4 bits of a beacon message, starting from
bit 26 to bit 85, as a hexadecimal character: “0000” = Hex 0 up to “1111” = Hex F. The
beacon 15 Hex ID is, therefore, represented as a string of fifteen characters, for example:
ADCD0228C500401 for the bit sequence: 1010 1101 1100 1101 0000 0010 0010 1000
1100 0101 0000 0000 0100 0000 0001.
In the case of location protocol, bits 26 to 85 include variable position data. The position
data in PDF-1 must be set to specified default values to create the fixed unique 15 Hex
ID of the beacon.
In the case of the SGBs, the 15 Hex ID is a truncated form of the full 23 Hex ID as defined
in Table 3.9 of document C/S T.019. A specific FGB user-location-protocol code “101”,
equivalent to Bits 37-39, which has been assigned to ensure that the 23 Hex ID for SGBs
will always truncate to a unique 15 Hex ID with the first bit always set to a value of “1”.

3-13

3.2.4
21-bit First BCH Error Correcting Field (BCH-1)
The 61 bits forming the first protected data field (PDF-1, bits 25 to 85) are followed by a 21-
bit Bose-Chaudhuri-Hocquenhem (BCH) error-correcting code (bits 86 to 106), in a field
defined as the first BCH error correcting field (BCH-1). This code can detect and correct up
to three bit errors in the 82 bits of the first protected field (PDF-1 and BCH-1). The error-
correcting code is generated from the content of PDF-1 as described in Annex A of C/S T.001.
Therefore, it must be computed and encoded together with the PDF-1. When updates to the
PDF-1 are required for encoding position data, the error-correcting code must be regenerated
after each update.
3.2.5
Non-Protected Data Field of the Short Message Format
The data field (bits 107 to 112) following the BCH-1 in the short message format is not error
protected. It can be used to transmit supplementary data indicating the distress situation
(emergency code) or specific features of the beacon (radio-locating device). The bits of the
non-protected data field have different assignments in the user protocols group or the location
protocols group, which are described in Figure 3.4.
Figure 3.4: Short Message Non-Protected Data Field
Figure 3.4.a: Emergency Code/National Use Data (\*) for Short Format User Protocols
Bits


Content
Emergency Code
Flag
Activation Code
Emergency Code or National Use Data
- bit 107:
flag bit set to "1" means that bits 109 to 112 contain one of the agreed emergency codes
(Table 3.4 and Table 3.5);
flag bit set to "0" means that bits 109 to 112 contain data defined by the administration
designated in the country code;
default coding for bit 107 is "0";
- bit 108:
the activation code is set to "1" if beacon is designed for both automatic and manual
activation; it is set to "0" if beacon can be activated manually only;
- bits 109 to 112:
encoded with one of the agreed emergency codes (Table 3.4 and Table 3.5) or with data
defined according to national requirements;
default coding for bits 109 to 112 is "0000".
* For national user protocols, the content of bits 107 to 112 of the non-protected field may be reassigned and controlled
by national administrations (see section 3.3.6).

3-14

Table 3.4: Maritime Emergency Codes\*
IMO
Indication(†)
Binary
Code
Usage


1001 to 1111
Fire/explosion
Flooding
Collision
Grounding
Listing, in danger of capsizing
Sinking
Disabled and adrift
Unspecified distress‡
Abandoning ship
Spare (could be used in future as necessary)
Table 3.5: Non-Maritime Emergency Codes
Bits
Usage §


No fire (=0); fire (=1)
No medical help (=0); medical help required (=1)
Not disabled (=0); disabled (=1)
Spare (=0)
3.2.6
Second Protected Data Field (PDF-2)
The twenty-six bits (bits 107 to 132) following the BCH-1 in the long message format form
the second protected data field (PDF-2). The PDF-2 is available only in the long message
format.
* The maritime emergency codes are in accordance with the list of IMO Nature of Distress Indications, except for code
"1111" which, for 406 MHz beacons, is defined as "spare" instead of "test" code in the IMO list (see also the test
protocol in section 3.3.5).
† IMO indication is an emergency code number, it is different from the binary encoded number.
‡ If no emergency code data has been entered, bit 107 remains set to (=0).
§ If no emergency code data has been entered, bit 107 remains set to (=0).

3-15

The second protected data field (PDF-2) is used for encoding supplementary data and position
data as defined for the various location protocols described in section 3.4. However,
administrations can also define their own bit assignments for this field to satisfy specific
national requirements, as provided for in the national user protocol (see section 3.3.6).
3.2.7
Second BCH Error Correcting Field (BCH-2)
The twenty-six bits forming the PDF-2 (bits 107 to 132) of the beacon message are followed
by a 12-bit BCH error-correcting code (bits 133 to 144) in a field defined as the second BCH
error correcting field (BCH-2), which can detect and correct up to 2 bit errors in the 38 bits
of the second protected field (PDF-2 plus BCH-2). The error-correcting code is generated
from the content of PDF-2 as described in Annex A of C/S T.001. Therefore, it must be
computed and encoded together with the PDF-2. When updates to the PDF-2 are required, the
error-correcting code must be regenerated after each update.
The 12-bit BCH error-correcting code must be computed and encoded in the second BCH
error correcting field (BCH-2) of all protocols using the long message format (with the
exception of orbitography protocol which is intended for use only by the Cospas-Sarsat
System operators).

3-16

3.3
Coding User Protocols
This section defines the user protocol message formats which can be used to encode the beacon
identification data and other data in the message transmitted by a 406 MHz distress beacon.
3.3.1
General Requirements for User Protocols
There are 6 different options for coding user protocols, which are described in Figure 3.5. The
applicable user protocol type is selected by setting bits 37 to 39 according to the appropriate
pattern. Most of the user protocols are available only in the short message format, selected by
setting bit 25 (format flag) to “0”. The coding of the user protocols is described with further
details in section 3.3.2 to 3.3.6.
The national user protocol and the test user protocol can be coded either with the short or the
long message format, as indicated by the format flag: “0” (short message), or “1” (long
message). The national user protocol which can be used to meet specific national requirements
must be defined in accordance with section 3.3.6.
The user-location protocol, described in section 3.4 as part of the location protocol group,
uses the long message format, but has the same definition as the user protocols for the first
protected data field (PDF-1).

3-17

Figure 3.5: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols
1. MARITIME USER PROTOCOL
Bits
25 26 27
36 37
39 40
81 82


.....


Country Code


MMSI or Radio Call Sign (42 bits)


R
L
2.  RADIO CALL SIGN USER PROTOCOL
Bits
25 26 27
36 37
39 40
81 82


.....


Country Code


Radio Call Sign  (42 bits)


R
L
3.  SERIAL USER PROTOCOL
Bits
25 26 27
36 37
39 40
42 43

73 74


.....


Country Code


T
T
T
C
Serial Number and other Data
C/S Cert. No or
National Use
R
L
4.  AVIATION USER PROTOCOL
Bits
25 26 27
36 37
39 40
81 82


.....


Country Code


Aircraft Registration Marking  (42 bits)
E N
R
L
5.  NATIONAL USER PROTOCOL
Bits
25 26 27
36 37
39 40

......
F

Country Code


National Use (46 bits)
6.  TEST USER PROTOCOL
Bits
25 26 27
36 37
39 40

.....
F

Country Code


Test Beacon Data (46 bits)
7.  ORBITOGRAPHY PROTOCOL
Bits
25 26 27
36 37
39 40

......
F

Country Code


Orbitography Data  (46 bits)
8.  SGB PROTOCOL (Reserved for SGB – but not transmitted)
Bits
25 26 27
36 37
39 40

......
…

Country Code


As Defined in C/S T.018  (46 bits)
Notes:
RL
=
Auxiliary radio-locating device (see Table 3.6)
TTT =
000 - ELT with serial number
010 - float free EPIRB with serial number
011 - ELT with 24-bit aircraft address  100 - non float free EPIRB with serial number
001 - ELT with aircraft operator
110 - personal locator beacon (PLB) with serial number
designator and serial number
C
=
C/S Type Approval Certificate Flag:
"1" C/S Type Approval Certificate number encoded in bits 74 to 83
"0" other national use
F
=
Format Flag (“0” = short message, “1” = long message)
EN* =
Specific ELT number on designated aircraft (see Figure 3.13)
Radio call sign of six or fewer alphanumeric characters can be encoded in Maritime User Protocol.
Radio call sign of up to seven characters (four alphanumeric and three digits) can be encoded in Radio Call Sign User
Protocol.
* Effective as of 1 November 2011.

3-18

Table 3.6: Auxiliary Radio-locating Device Code


- No Auxiliary Radio-locating Device
- 121.5 MHz Auxiliary Radio-locating Device
- 9 GHz SART Locating Device
- Other Auxiliary Radio-locating Device(s)
Note:
If other auxiliary radio-locating device(s) is (are) used in addition to 121.5 MHz, the code for
121.5 MHz (i.e. 01) should be used.
3.3.2
Coding Maritime Protocols
Resolution A.810(19) of the International Maritime Organization (IMO) 19th Assembly meeting
states that:
"A unique beacon identification code shall be made part of all messages.
This identification code shall include a 3-digit code for the country in which the beacon is
registered, followed by either:
.1 the trailing 6 digits of the ship station identity in accordance with Appendix 43
of ITU Radio Regulations; or
.2  a unique serial number; or
.3  a radio call sign.
Preference is given to method .1.”
Note:
For the purpose of this document the Maritime Mobile Service Identity (MMSI) and the Ship Station
Identity are equivalent and are defined as a 9-digit number consisting of the MID (country code)
followed by six digits.
Coding of beacons with the identification codes recommended by IMO is detailed in the
following sections:
3.3.2.1 Coding the Maritime User Protocol with MMSI;
3.3.2.2 Coding EPIRBs with a Unique Serial Number; and
3.3.2.3 Coding EPIRBs with the Radio Call Sign Identification.

3-19

3.3.2.1 Coding the Maritime User Protocol with MMSI\*
The maritime user protocol can be used to encode the Maritime Mobile Service Identity
(MMSI) in EPIRBs as shown in Figure 3.6.
Figure 3.6: Coding the Maritime User Protocol with MMSI
Bits 25 26 27 ........ 36 37 .. 39 40 .....................
75 76 ..... 81 82 83 84 85
0 1
Country Code
0 1 0
(36 bits) Trailing 6 digits
of MMSI
Beacon
Number
0 0
R L
- bit 25:
format flag set to "0" (short message)
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code, set to "010" (maritime user protocol);
- bits 40 to 75:
contain the trailing 6 digits of MMSI number encoded using the modified-Baudot code
(i.e. 6 bits per digit, see Table B.1 of Annex B);
- bits 76 to 81:
a consecutive decimal number for each beacon on that vessel, encoded using the
modified-Baudot code (see Table B.1 of Annex B), where the first or only float free
beacon is to be coded with a modified-Baudot zero: "001101"; additional beacons shall
be numbered consecutively using modified-Baudot characters 1 to 9 and A to Z;
- bits 82 and 83:
spare, set to "00";
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see
Table 3.6 to indicate other radio-locating devices).
3.3.2.2 Coding EPIRBs with a Unique Serial Number
Protocol code bits 37 to 39 for this method of encoding identification data are set to "011"
(i.e. the serial user protocol) to indicate that a beacon serial number is contained in the
message as described in Figure 3.7, unless the beacon serial identity number is defined
otherwise by the national regulation. Bits 40 to 42 are used to identify the beacon type, as
the same serial protocol is used in several applications.
* This coding method should be used only if the first 3 digits (MID) forming part of a unique 9-digit code of ship
station identity correspond to the 3 digit country code encoded in bits 27 to 36.

3-20

Figure 3.7: Coding the EPIRB Serial Identification
Bits 25 26 27 .... 36 37 .. 39 40 .. 42 43 44 ....... 63 64 .... 73 74 ....... 83 84 85
0 1
Country
Code
0 1 1 T T T C
(20 bits)
Serial Number
All ‘0’ or
National
Use
C/S Cert. No
or National
Use
R L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code set to "011" (serial user protocol);
- bits 40 to 42:
(TTT) beacon-type code set to "010" for EPIRBs which can be automatically released and
activated, (float free type) or to "100" for EPIRBs which can be manually activated only
(survival type);
- bit 43:
(C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded
in bits 74 to 83, or set to "0" otherwise \*;
- bits 44 to 63:
sequential number, allocated by the manufacturer \*, encoded in binary notation with the
least significant bit on the right;
- bits 64 to 73:
all "0", unless designated otherwise by the responsible administration \*;
- bits 74 to 83:
if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number
for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon
model), encoded in binary notation with the least significant bit on the right;
if bit 43 is set to "0", these bits are designated by the responsible administration \*;
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see
Table 3.6 to indicate other radio-locating devices).
The serial identification coding format described in Figure 3.7, which uses the Cospas-Sarsat type
approval certificate (TAC) number, is compatible with other existing serial formats defined by
administrations (as notified to the Cospas-Sarsat Secretariat).
The Cospas-Sarsat TAC number is a unique number assigned by the Cospas-Sarsat Secretariat to each
beacon model which has been successfully tested in accordance with the Cospas-Sarsat Type
Approval Standard (C/S T.007). The list of Cospas-Sarsat TAC numbers of type approved beacon
models is published by the Cospas-Sarsat Secretariat in the document "Cospas-Sarsat System Data".
Using the Cospas-Sarsat TAC number ensures that the serial production number assigned by a
manufacturer provides a unique beacon 15 Hex ID, independent of the country of beacon registration
encoded in the country code. If the Beacon 15 Hex ID is assigned by the national administration of
the country designated by the country code, bit 43 can be set to “0” and the content of bits 44 to 83
* Alternative means of allocating and controlling serial numbers on a national basis may be adopted by administrations,
but they must be compatible with the serial user protocol defined in document C/S T.001, and provide a unique beacon
15 Hex ID.

3-21

reassigned as required. However, in that case, the national administration must ensure that the beacon
15 Hex ID is unique.
3.3.2.3 Coding
EPIRBs
with
the
Radio
Call
Sign
Identification
The radio call sign is an alphanumeric sequence (letters and digits) assigned to a particular
vessel by the Flag State administration. This call sign can be encoded in bits 40 to 75 of
the maritime user protocol or the radio call sign user protocol. The coding of these two
protocols is detailed in the following paragraphs.
3.3.2.4 3.3.2.3.1 Coding the Maritime User Protocol with the
Radio Call Sign
Radio call signs consisting of six or fewer alphanumeric characters can be encoded
using the maritime user protocol as shown in Figure 3.8. Although the same protocol
is used for both MMSI and Radio Call Signs of 6 or fewer characters, the use of letters
in Radio Call Signs ensures that the Radio Call Sign will not be confused with MMSI
composed of only digits.

3-22

Figure 3.8: Coding the Maritime User Protocol with the Radio Call Sign
Bits 25 26 27 ........ 36 37 .. 39 40 ..................
75 76 ..... 81 82 83 84 85
0 1
Country Code
0 1 0 (6 alphanumeric characters =
36 bits) Radio Call Sign
Beacon
Number
0 0
R L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code, set to "010" (maritime user protocol);
- bits 40 to 75:
up to 6 alphanumeric characters encoded using the modified-Baudot code (see
Table B.1 of Annex B); if the radio call sign has fewer than six characters, blank spaces
should be encoded to the left of the characters using the modified-Baudot space symbol:
"100100"; if the radio call sign has seven characters it can only be encoded with the
Radio Call Sign User Protocol (see item 3.3.2.3.2);
- bits 76 to 81:
a consecutive serial number for each beacon on that vessel, encoded using the modified-
Baudot code, where the first or only float free beacon is to be coded with a modified-
Baudot zero "001101"; additional beacons shall be numbered consecutively using
modified-Baudot characters 1 to 9 and A to Z;
- bits 82 and 83:
set to "00";
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see
Table 3.6 to indicate other radio-locating devices).
3.3.2.5 3.3.2.3.2 Coding the Radio Call Sign User Protocol
with the Radio Call Sign
Radio call signs of up to seven characters can be encoded according to Figure 3.9 if
they comply with the ITU Radio Regulations on the formation of call signs (Article
25 of the Radio Regulations) whereby alphabetic characters are allowed only in the
first four characters of the sequence. These first four characters are coded with the
modified-Baudot code in bits 40 to 63 (see Table B.1 of Annex B) and the final three
digits are coded in binary-coded decimal form in bits 64 to 75. Characters coded with
the modified-Baudot code can be either alphabetic or numeric; characters coded in
binary-coded decimal (BCD) must be numeric.
If the radio call sign protocol is used for a call sign of less than seven characters, the
radio call sign should be left justified (i.e. data on the left) in the data field (bits 40 to
75) and padded to the right of the last character with BCD "space" characters (see
Annex C) in the binary-coded decimal field (bits 64-75).

3-23

Figure 3.9: Coding the Radio Call Sign User Protocol
Bits 25 26 2

........ 36


.. 39 4

............ 6

64 .. 75 7

..... 81 8

83 8


Country Code
1 1

(4 alphanumeric
char. of Radio
Call Sign)
(3 last
digits)
Beacon
Number
0 0
R L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code, set to "110" (radio call sign user protocol);
- bits 40 to 63:
first 4 characters of the radio call sign (letters or digits) encoded using the modified-
Baudot code (see Table B.1 of Annex B);
- bits 64 to 75:
last BCD characters (see Annex C) of the radio call sign (3 digits or less), and padded
with "space" ("1010") to the right of the last digit, if less than 3 digits (see example
hereunder);
- bits 76 to 81:
a consecutive number for each beacon on the same vessel, encoded using the modified-
Baudot code, where the first or only float free beacon is to be coded with a modified-
Baudot zero "001101"; additional beacons shall be numbered consecutively using
modified-Baudot characters 1 to 9 and A to Z;
- bits 82 and 83:
set to "00";
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see
Table 3.6 to indicate other radio-locating devices).
Example of radio call sign coding: "ABC123" will be coded:
" 111000  110011  101110  011101  0010  0011  1010 "
A       B       C       1      2     3    ( )
3.3.3
Coding Aviation Protocols
The International Civil Aviation Organization (ICAO) has defined four coding methods which
can be used to identify 406 MHz Emergency Locator Transmitters (ELTs) (Convention on
International Civil Aviation, Annex 10, Appendix D to Part I - Emergency Locator Transmitter
Coding).
The identification codes recommended by ICAO are in accordance with the general structure of
Cospas-Sarsat user protocols shown in Figure 3.5 and described in the following sections:
3.3.3.1 Coding ELTs with the Beacon Serial Number;
3.3.3.2 Coding ELTs with the Aircraft Operator Designator and a Serial Number;
3.3.3.3 Coding ELTs with the Aircraft 24-bit Address; and
3.3.3.4 Coding ELTs with the Aircraft Nationality and Registration Marking.

3-24

All aviation coding methods include a country code based on ITU Radio Regulation
Appendix 43 (see section 3.3.1). ICAO also recommends that "each beacon shall be assigned a
unique coding and shall be registered" with the appropriate authority (Convention on
International Civil Aviation, Annex 10, Volume I, Part I, Chapter 5. Emergency Locator
Transmitter (ELT) for Search and Rescue).
3.3.3.2 3.3.3.1 Coding ELTs with the Beacon Serial Number
Protocol code bits 37 to 39 for this method of encoding identification data are set to "011"
to designate the serial user protocol. Bits 40 to 42 are used to identify the beacon type and
coding method (i.e. "000" to indicate an ELT serial number) since the same serial user
protocol is used for several applications. If bit 43 is set to "1", the Cospas-Sarsat type
approval certificate number is encoded in bits 74 to 83, as shown in Figure 3.10. This will
help ensure that the serial identity of the beacon is unique (see also item 3.3.2.2).
Figure 3.10: Coding ELTs with the Beacon Serial Number
Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 63 64 ..... 73 74 ........ 83 84 85
0 1
Country
Code
0 1 1 0 0 0 C
(20 bits)
Serial Number
All "0" or
Nation. Use
C/S Cert.No or
National Use
R L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code, set to "011" (serial user protocol);
- bits 40 to 42:
beacon type set to "000" for ELTs with serial identification;
- bit 43:
(C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded
in bits 74 to 83, set to "0" otherwise;
- bits 44 to 63:
sequential number, allocated by manufacturers\*, encoded in binary notation with the least
significant bit on the right;
- bits 64 to 73:
all "0", unless designated otherwise by the responsible administration\*;
- bits 74 to 83:
if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number
for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon
model), encoded in binary notation with the least significant bit on the right;
if bit 43 is set to "0", these bits are designated by the responsible administration* ;
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see
Table 3.6 to indicate other radio-locating devices).
* Alternative means of allocating and controlling serial numbers on a national basis may be adopted by administrations, but they must
be compatible with the serial user protocol defined in document C/S T.001, and provide a unique beacon 15 Hex ID.

3-25

3.3.3.3 Coding ELTs with the Aircraft Operator Designator
and a Serial Number
The 3-letter Aircraft Operator Designator (AOD), defined in ICAO DOC 8585, is a
unique identification of Aircraft Operators. The AOD can be coded in the serial user
protocol as shown in Figure 3.11.
Figure 3.11: Coding ELTs with the Aircraft Operator Designator and Serial Number
Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 61 62 ..... 73 74 ........ 83 84 85
0 1
Country
Code
0 1 1 0 0 1 C
Operator
3-letter
Designator
Serial
Number
C/S Cert.No or
National Use
R L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code, set to "011" (serial protocol);
- bits 40 to 42:
beacon type set to "001" for ELTs identified with the 3-letter aircraft operator designator
and a serial number;
- bit 43:
(C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded
in bits 74 to 83, set to "0" otherwise\*;
- bits 44 to 61:
3-letter aircraft operator designator, encoded using the Modified-Baudot code (see
Table B.1 of Annex B);
- bits 62 to 73:
serial number, as designated by the operator, is encoded in binary notation with the least
significant bit to the right (No. 0001 up to 4096);
- bits 74 to 83:
if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number
for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon
model), encoded in binary notation with the least significant bit on the right;
if bit 43 is set to "0", these bits are designated by the responsible administrations ;
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see
Table 3.6 to indicate other radio-locating devices).
3.3.3.4 Coding ELTs with the Aircraft 24-bit Address
The Aircraft 24-bit Address is a unique 24-bit binary code assigned to the aircraft by
national administrations in accordance with Annex 10 to the Convention on International
Aviation. The Aircraft 24-bit Address is coded in the serial user protocol as shown in
Figure 3.12.

3-26

Figure 3.12: Coding ELTs with the Aircraft 24-bit Address
Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 67 68 ..... 73 74 ........ 83 84 85
0 1
Country
Code
0 1 1 0 1 1 C
24-bit
Aircraft
Address
Specific
ELT number
C/S Cert. No
or National
Use
R L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code, set to "011"(serial protocol);
- bits 40 to 42:
beacon type set to "011" for ELTs identified with aircraft 24-bit address;
- bit 43:
(C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is
encoded in bits 74 to 83, set to "0" otherwise;
- bits 44 to 67:
24-bit aircraft address;
- bits 68 to 73:
6 bit specific ELT number, in binary notation with the least significant bit on the right, if
several ELTs are carried in the same aircraft and encoded with the same 24 bit address,
or default to 0's when one ELT is carried, see Notes (1) and (2) below;
- bits 74 to 83:
if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number
for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon
model), encoded in binary notation with the least significant bit on the right;
if bit 43 is set to "0", these bits are designated by the responsible administrations;
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon
(see Table 3.6 to indicate other radio-locating devices).
Notes: (1)  Before attempting to encode an ELT with the serial user protocol using the aircraft 24-bit address, to avoid
repeating an existing 15 Hex ID, manufacturers / programming facilities should request the inquirer / user to
provide appropriate information on the specific number to be encoded in bits 68 to 73. Cospas-Sarsat
recommendation is to assign the first ELT the default value “000000” and then increment the binary number
for subsequent ELT, (e.g., 2nd ELT = “000001”, 3rd ELT = “000010”, etc.)
(2)  Administrations should advise users to inform manufacturers / programming facilities on the number to be
encoded in bits 68 to 73 each time they request the coding of an ELT with a specific aircraft 24-bit address to
ensure that each coded beacons results in a unique Hex-ID.

3-27

3.3.3.5 Coding ELTs with the Aircraft Nationality and
Registration Marking
The aircraft nationality and registration marking is a unique alphanumeric number
assigned by national administrations in accordance with Annex 10 to the Convention on
International Civil Aviation. This is coded in the aviation user protocol as shown in Figure
3.13.
Figure 3.13: Coding ELTs with the Aircraft Nationality and Registration Marking
Bits 25 26 27 ...... 36
37 .. 39 40 .................................. 81 82 83 84

0 1
Country Code

0 1
Aircraft Registration Marking
(42 bits = up to 7 alphanumeric
charact.)
ELT
number
R
L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 to 36:
country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 39:
protocol code, set to "001" (aviation user protocol);
- bits 40 to 81:
aircraft nationality and registration marking, containing up to 7 alphanumeric characters, is
encoded using the modified-Baudot code (see Table B.1 of Annex B); if the aircraft nationality
and registration marking include less than 7 characters, blank spaces should be encoded to
the left of the characters using the modified-Baudot space symbol: "100100";
- bits 82 and 83:
Specific ELT number where “00” indicates the first ELT on the aircraft coded with this protocol
and “01”, “10” and “11” identify additional ELTs on the same aircraft, all coded with the Aviation
User protocol\*;
- bits 84 and 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table
3.6 to indicate other radio-locating devices).
* Effective as of 1 November 2011.

3-28

3.3.4
Coding PLBs with the Serial User Protocol
The serial user protocol is used to code beacons that have been designed as Personal Locator
Beacons (PLB). These PLBs are coded as shown in Figure 3.14 using the serial user protocol
with protocol code bits (40 - 42) set to “110”.
Figure 3.14: Coding PLBs with the Serial User Protocol
Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 63 64 ..... 73 74 ........ 83 84 85
0 1
Country
Code
0 1 1 1 1 0 C
(20 bits)
Serial Number
All "0" or
Nation. Use
C/S Cert.No or
National Use
R L
- bit 25:
format flag set to "0" (short message);
- bit 26:
protocol flag set to "1";
- bits 27 - 36:
country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 - 39
protocol code set to "011" (serial user protocol);
- bits 40 - 42:
beacon-type code set to "110" (personal);
- bit 43:
(C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded
in bits 74 to 83, or set to "0" otherwise\*;
- bits 44 - 63:
sequential number, allocated by the manufacturer \*, encoded in binary notation with he
least significant bit on the right;
- bits 64 - 73:
all "0", unless designated otherwise by the responsible administration \*;
- bits 74 - 83:
if bit 43 is set to "1", contain the Cospas-Sarsat type approval certificate number for that
beacon model (i.e., a unique number assigned by Cospas-Sarsat for each beacon model),
encoded in binary notation with the least significant bit on the right;
if bit 43 is set to "0", these bits are designated by the responsible administration \*;
- bits 84 - 85:
(RL) set to "01" if a 121.5 MHz radio-locating transmitter in included in the beacon (see
Table 3.6 to indicate other radio-locating devices).
3.3.5
Coding the Test User Protocol
The test protocols are used when conducting any tests of beacons (e.g. demonstrations, type
approval tests, training exercises, etc.) whenever the emitted signals might be detected by the
satellites. The test user protocol can be formed from any of the other user protocols by setting
* Alternative means of allocating and controlling serial numbers on a national basis may be adopted by administrations,
but they must be compatible with the serial user protocol defined in document C/S T.001, be made known to the
Cospas-Sarsat Secretariat, and provide a unique beacon 15 Hex ID.

3-29

bits 37 - 39 to "111". When using the test protocol, bits 40 to 85 and 107 to 112 may be set to
any bit pattern (even random) provided that the error-correcting code is set accordingly.
Cospas-Sarsat MCCs will neither respond to, nor forward alert messages corresponding to
beacons coded with the test user protocol, unless requested by the appropriate authority of the
country conducting the test (e.g. the SPOC in that country) and co-ordinated with the
appropriate MCC (i.e. the MCC in which service area the test is being conducted). Details of
the procedure to co-ordinate tests are provided in the System document C/S A.001 (DDP).
The test user protocol is different than the beacon "self-test" mode described in section 3.2.2.2,
which transmits a single burst having a modified frame synchronization bit pattern. The self
test mode transmission of the beacon is not processed by the Cospas-Sarsat satellite
equipment.
Figure 3.15: Coding the Test User Protocol
Bits 25 26 27 ........ 36 37 .. 39 40..................................................
.

F 1
Country Code
1 1 1
Any combination of bits allowed in the user protocol
format
- bit 25:
(F) format flag set to "0" (short message) or "1" (long message);
- bit 26:
protocol flag set to "1";
- bits 27 - 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 - 39:
protocol code set to "111" (test user protocol);
- bits 40 - 85:
any combination of bits (with the proper error-correcting code).

3-30

3.3.6
Coding the National User Protocol
The national user protocol is a special coding format having certain data fields, indicated as
"national use", which are defined and controlled by the national administration of the
particular country which is identified by the country code field.
The national user protocol may be either a short or a long message, as indicated by the format
flag (bit 25). The correct BCH code(s) must be encoded in bits 86-106, and in bits 133-144 if
a long message is transmitted.
The national user protocol coding format is described in Figure 3.16:
Figure 3.16: Coding the National User Protocol
Bits 25 26 27 ..... 36 37 38 39 40................85 86......106 107..........132 133....144
F 1
Country
Code
1 0 0
National Use
(46 bits)
BCH Code
(21 bits)
National Use
(26 bits)
BCH Code
(12 bits)
- bit 25:
(F) format flag set to "0" (short message) or "1" (long message);
- bit 26:
protocol flag set to "1";
- bits 27 - 36:
country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 - 39
protocol code set to "100" (national user protocol);
- bits 40 - 85:
national use;
- bits 86-106:
21-bit BCH code;
- bits 107 - 112:
national use;
- bits 113 - 132:
national use (if long message);
- bits 133 - 144:
12-bit BCH code (if long message).
Once the beacon has been activated, the content of the message in bits 1 to 106 must remain
fixed, but bits 107 onwards are permitted to be changed periodically, provided the correct
12-bit BCH code is also re-computed and that such changes do not occur more frequently
than once every 5 minutes.
It should be noted that the content of distress alert messages encoded with the national user
protocol cannot be interpreted by Cospas-Sarsat MCCs and will be forwarded to SAR
services only as hexadecimal data.

3-31

3.4
Coding Location Protocols
This section defines the protocols which can be used for encoding beacon position data, as well as
the beacon identification data, in the digital message transmitted by a 406 MHz distress beacon.
Five types of location protocols are defined for use either with the long message format or with
the short message format, as illustrated in Figure 3.17. The three protocol types available are:
• User-location Protocol;
• Standard Location Protocol;
• National Location Protocol.
Figure 3.17: Outline of Location Protocols
U  s  e  r   -    L  o  c  a  t  i  o  n        P  r  o  t  o  c  o  l  s
bit

bits
27-39
bits 40-83
bits
84-85
bits 86-106
bit 107
bits 108-132
bits
133-144

.......
Identification Data
(44 bits)
Radio-
locating
Device
21-Bit
BCH code
Position.
Data
Source
Position Data
to 4 min Resolution
(25 bits)
12-Bit
BCH code
S  t  a  n  d  a  r  d       L  o  c  a  t  i  o  n       P  r  o  t  o  c  o  l  s
bit

bits
27-40
bits 41-64
bits 65-85
bits 86-106
bits 107-112
bits 113-132
bits
133-144

.......
Identification Data
(24 bits)
Position Data
to 15 min Resolution
(21 bits)
21-Bit
BCH code
Supplementary
Data
Position Data
to 4 sec Resolution
(20 bits)
12-Bit
BCH code
N  a  t  i  o  n  a  l       L  o  c  a  t  i  o  n       P  r  o  t  o  c  o  l
bit

bits
27-40
bits 41-58
bits 59-85
bits 86-106
bits 107-112
bits 113-126
bits
127-132
bits
133-144

.......
Identification Data
(18 bits)
Position Data
to 2 min Resolution
(27 bits)
21-Bit
BCH code
Supplementary
Data
Position Data
to 4 sec Resolution
(14 bits)
National
Use
12-Bit
BCH code
E  L  T  ( D  T )    a  n  d    R  L  S       L  o  c  a  t  i  o  n       P  r  o  t  o  c  o  l
bit

bits
27-40
bits 41-66
bits 67-85
bits 86-106
bits 107-114
bits 115-132
bits 133-144

.......
Identification Data
(26 bits)
Position Data to 30 min
Resolution (19 bits)
21-Bit
BCH code
Supplementary
Data (8 bits)
Position Data to 4 sec
Resolution (18 bits)
12-Bit
BCH code

3-32

3.4.1
Position Data Encoding
All position information is encoded as degrees, minutes and seconds of latitude or longitude,
or as fractions of these units. Latitude and longitude data are rounded off (i.e. not truncated)
to the available resolution. When a position is encoded in the PDF-1, the higher resolution
information given in the PDF 2 is an offset (Δ latitude and Δ longitude) relative to the position
provided in PDF 1.
The position is encoded as follows. The coarse position encoded in the PDF-1 is selected to
be as close as possible to the actual position. Then the actual position is rounded off. The
offset encoded in the PDF-2 is selected so that it may be summed with the coarse position to
produce a finer position that equates to the rounded position. Subsequent position updates (if
applicable) are encoded in exactly the same way. An example of encoding of position data for
the standard location protocol is presented in Table 3.7. More examples of encoding of the
position data with the Standard Location and National Location protocols are provided in
Annex A.
Table 3.7: Encoding of Position Data
Position data:
actual latitude:
43 43' 57'' N
actual longitude:
0 57' 51'' E
actual latitude rounded to nearest 4'' increment:
43 43' 56''N
actual longitude rounded to nearest 4'' increment:
000 57' 52''E
coarse latitude:
43 45' N
coarse longitude:
001 0' E
latitude offset:
- 1' 4''
longitude offset:
- 2' 8''
Binary encoding:
position
bits
setting
Latitude Flag:
N


Latitude in Degrees
(in 1/4 degree increment):
43
66-74
0101011 11
Longitude Flag:
E


Longitude in Degrees
(in 1/4 degree increment):

76-85
00000001 00
Latitude offset sign:


Latitude offset in min:

114-118

Latitude offset in sec:

119-122

Longitude offset sign:


Longitude offset in min:

124-128

Longitude offset in sec:

129-132

3-33

The latitude and longitude values contained in the PDF-1 are positive numbers regardless of
their directions. The offset is applied by adding or subtracting the offset value in accordance
with the offset sign in PDF-2. For example:
100° E. longitude + 30 offset = 100° 30 E. longitude
100° W. longitude + 30 offset = 100° 30 W. longitude (not 99° 30 W. longitude)
100° W. longitude - 30 offset =  99° 30W. longitude (not 100° 30 W. longitude).
3.4.2
Coding the User-location Protocols
The applicable user-location protocol is selected by setting bit 26 (protocol flag) to "1" and
bits 37 to 39 as defined in section 3.3. The protocols are available only in long message format,
with bit 25 (format flag) set to “1”.
The beacon identification data is provided in the PDF-1 by any one of the user protocols
defined in section 3.3, except the orbitography user protocol and the national user protocol.
Position data is provided as latitude and longitude, to 4-minute resolution, encoded in the
PDF-2. The 26 bits available in the PDF-2 can be encoded as shown in Figure 3.18.
Figure 3.18: Coding the User-location Protocols’ Second Protected Data Field (PDF-2)
Bits


......


......

Position
Data
Source
Flag
N/S
Latitude Data
Flag
E/W
Longitude Data
- bit 107:
encoded position data source bit set to "0" means that the encoded position data is provided
by an external navigation device,
encoded position data source bit set to "1" means that the encoded position data is provided
by an internal navigation device;
- bits 108 to 119:
latitude data (12 bits) with 4 minute resolution, including:
- bit 108:
N/S flag (N=0, S=1),
- bits 109 to 115:
degrees (0 to 90) in 1 degree increments,
- bits 116 to 119:
minutes (0 to 56) in 4 minute increments,
(default value of bits 108 to 119= 0 1111111 0000);
- bits 120 to 132:
longitude data (13 bits) with 4 minute resolution including:
- bit 120:
E/W flag (E=0, W=1),
- bits 121 to 128:
degrees (0 to 180) in 1 degree increments,
- bits 129 to 132:
minutes (0 to 56) in 4 minute increments,
(default value of bits 120 to 132= 0 11111111 0000).

3-34

3.4.3
Coding the Standard Location Protocols
The applicable standard location protocol is selected by setting bit 26 (protocol flag) to "0"
and bits 37 to 40 as defined below. The protocols are available in long message format with
bit 25 (format flag) set to “1”.
The beacon identification data is provided in a standardised format in 24 bits of the PDF-1
and can be encoded for different standard location protocols as shown in Figures 3.19 to
3.23\*.
Position data to 15-minute resolution is also given in the PDF-1, with position offsets to 4-
second resolution in the PDF-2. The coding of this data is the same for all types of standard
location protocols and is described with further details in Figure 3.24.
Figure 3.19: Coding the Standard Location Protocol with MMSI
Bits


.... 36


....
60 61
...


Country Code


(20 bits)
Last 6 Digits of
MMSI
Specific Beacon
Number
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
protocol code, set to "0010" (EPIRB -MMSI Standard Location Protocol);
- bits 41 to 60:
contain the last 6 digits of MMSI in binary form;
- bits 61 to 64:
4-bit specific EPIRB number (in binary notation with the least significant bit on the right)
used if several EPIRBs are carried on same vessel and encoded with the same 20 bit
MMSI address, all bits defaulted to “0” when only one EPIRB is carried.

3-35

Figure 3.20: Coding a Ship Security Alert System (SSAS) Beacon
Bits


.... 36


....
60 61
...


Country Code


(20 bits)
Last 6 Digits of
MMSI
Specific Beacon
Number
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
protocol code, set to "1100" (Ship Security Alert);
- bits 41 to 60:
contain the last 6 digits of MMSI in binary form;
- bits 61 to 64:
values set to "0000"
Figure 3.21: Coding the Standard Location Protocol with the 24-bit Aircraft Address
Bits 25


.... 36

.. ..


...................... 64


Country Code


24 bit Aircraft Address
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
protocol code, set to "0011" (ELT 24-bit Address Standard Location Protocol);
- bits 41 to 64:
contain the 24-bit aircraft address (only one ELT per aircraft can be identified using this
protocol).
Note:   * ELTs carried to satisfy the requirements of ICAO Annex 6, Parts I, II and III shall operate in accordance with ICAO
Annex 10.

3-36

Figure 3.22: Coding the Standard Location Protocol with the Aircraft Operator Designator
and Serial Number
Bits


.... 36 37
.. ..


....


...


Country Code


(15 bits)
3-letter of AOD
code
9 bit ELT
Number
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
protocol code, set to "0101" (ELT - Aircraft Operator Designator Standard Location
Protocol);
- bits 41 to 55:
3-letter aircraft operator designator, encoded using the Modified-Baudot code (see
Table B.1 of Annex B) in shortened form: the first bit which is =1 for any letter is deleted
to form a 5 bit code;
- bits 56 to 64:
9-bit unique ELT number (1-511) in binary form assigned by operator.
Figure 3.23: Coding the ELT/EPIRB/PLB Serial Identification Data
in the Standard Location Protocols
Bits


.... 36

.. ..


.... 50

...


Country Code
X
X
X
X
10 bit C-S type
approval
certificate
Number
14 bit Serial
Number
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
standard location protocol code, set to: 0100 for ELT, 0110 for EPIRB, 0111 for PLB;
- bits 41 to 50:
contain the 10-bit Cospas-Sarsat type approval certificate number of the beacon
(1 to 1,023);
- bits 51 to 64:
14-bit serial number (1 to 16,383) in binary form.

3-37

Figure 3.24: Coding the Position Data in the Standard Location Protocols
Bits

66-74
75 76-85 86-106 107-112 113 114-118 119-122 123 124-128 129-132 133-144
Flag
Lat
Lat
degr
Flag
Long
Long
degr
21-bit
BCH code
Suppl.
Data
Lat 
Sign
Lat 
min
Lat 
sec
long 
sign
Long 
min
Long 
sec
12-bit
BCH code
- bits 65 to 74:
latitude data (10 bits) with 15 minute resolution, including:
- bit 65:
Latitude flag (N=0, S=1)
- bits 66 to 74:
degrees (0 to 90) in 0.25 degree increments
(default value of bits 65 to 74 = 0 111111111);
- bits 75 to 85:
longitude data (11 bits) with 15 minute resolution including:
- bit 75:
Longitude flag (E=0, W=1)
- bits 76 to 85:
degrees (0 to 180) in 0.25 degree increments
(default value of bits 75 to 85 = 0 1111111111);
- bits 86 to 106:
21-bit BCH code;
- bit 107-110:
“1101” (fixed);
- bit 111:
position data source flag set to "0" means that the position data encoded in PDF-1 is
provided by an external navigation device;
position data source flag set to "1" means that the position data encoded in PDF-1 is
provided by an internal navigation device;
- bit 112:
121.5 MHz radio-locating device flag set to "0" means that there is no 121.5 MHz auxiliary
radio-locating transmitter in the beacon;
121.5 MHz radio-locating device flag set to "1" means that the beacon is equipped with a
121.5 MHz auxiliary radio-locating transmitter;
- bits 113 to 122:
offset () latitude data (10 bits) with 4 second resolution, including:
- bit 113:
 sign (0=minus, 1=plus)
- bits 114 to 118:
minutes (0 to 30) in 1 minute increments
- bits 119 to 122:
seconds (0 to 56) in 4 second increments
(default value of bits 113 to 122 = 1 00000 1111);
- bits 123 to 132:
offset () longitude data (10 bits) with 4 second resolution, including:
- bit 123:
 sign (0=minus, 1=plus)
- bits 124 to 128:
minutes (0 to 30) in 1 minute increments
- bits 129 to 132:
seconds (0 to 56) in 4 second increments
(default value of bits 123 to 132 = 1 00000 1111);
- bits 133 to 144:
12-bit BCH code.
* Fig 3.24 defines the coding scheme for all Standard Location Protocols, some newer beacons where the coarse position in PDF-1 is
always selected to be as close as possible to the actual position will have a maximum offset in PDF-2 of +/- 7 minutes 30 seconds, in
which case bits 114, 115, 124 and 125 of the message will not be used and should be permanently set to “0”.

3-38

3.4.4
Coding the National Location Protocol
The applicable national location protocol is selected by setting bit 26 (protocol flag) to “0”
and bits 37 to 40 as defined below. The protocol is available in the long message format with
bit 25 (format flag) set to “1”.
The beacon identification data is provided in a nationally-defined format in 18 bits of the
PDF-1. Position data, to 2-minute resolution, are given in the PDF-1, with position offsets to
4-second resolution in the PDF-2. The coding of the national location protocol is described
with further details in Figure 3.25.
Figure 3.25: Coding the National Location Protocol
Figure 3.25.a: Data of the PDF-1 and BCH-1 Fields of National Location Protocol
Bits


27-36
37-40 41-58

60-66 67-71

73-80 81....85
86-106
Format
Flag
Prot.
Flag
MID
Prot.
Code
Ser.
Numb
Flag
Lat
Lat
degr
Lat
min
Flag
Long
Long
degr
Long min
21-bit
BCH code
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
National location protocol code set to: 1000 for ELT, 1010 for EPIRB, 1011 for PLB;
- bits 41 to 58:
contain the 18-bit identification data consisting of a serial number assigned by the
responsible administration;
- bits 59 to 71:
latitude data (13 bits) with 2 minute resolution, including:
- bit 59:
N/S flag (N=0, S=1)
- bits 60 to 66:
degrees (0 to 90) in 1 degree increments
- bits 67 to 71:
minutes (0 to 58) in 2 minute increments
(default value of bits 59 to 71= 0 1111111 00000);
- bits 72 to 85:
longitude data (14 bits) with 2 minute resolution including:
- bit 72:
E/W flag (E=0, W=1)
- bits 73 to 80:
degrees (0 to 180) in 1 degree increments
- bits 81 to 85:
minutes (0 to 58) in 2 minute increments
(default value of bits 72 to 85 = 0 11111111 00000);
- bits 86 to 106:
21-bit BCH code.

3-39

Figure 3.25.b: Data of the PDF-2 and BCH-2 Fields of National Location Protocol
Bits 107-112

114-115 116-119

121-122 123-126 127.................132 133-144
Supplem.
Data
Lat 
Sign
Lat min Lat sec long 
sign
Long
min
Long
sec
National Use
12-bit
BCH code
- bit 107-109:
“110” (fixed);
- bit 110:
additional data flag: set to “1” means that  position data encoded in PDF-2, set to “0”
means that data in PDF-2 is defined nationally;
- bit 111:
position data source flag set to "0" means that the position data encoded in PDF-1 is
provided by an external navigation device;
position data source flag set to "1" means that the position data encoded in PDF-1 is
provided by an internal navigation device;
- bit 112:
121.5 MHz radio-locating device flag set to "0" means that there is no 121.5 MHz auxiliary
radio-locating transmitter in the beacon;
121.5 MHz radio-locating device flag set to "1" means that the beacon is equipped with a
121.5 MHz auxiliary radio-locating transmitter;
- bits 113 to 119:
offset () latitude data (7 bits) with 4 second resolution, including:
- bit 113:
 sign (0=minus,1=plus)
- bits 114 to 115:
minutes (0 to 3) in 1 minute increments
- bits 116 to 119:
seconds (0 to 56) in 4 second increments
(default value of bits 113 to 119 = 1 00 1111);
- bits 120 to 126:
offset () longitude data (7 bits) with 4 second resolution, including:
- bit 120:
 sign (0=minus, 1=plus)
- bits 121 to 122:
minutes (0 to 3) in 1 minute increments
- bits 123 to 126:
seconds (0 to 56) in 4 second increments
(default value of bits 120 to 126 = 1 00 1111);
- bits 127 to 132:
Additional beacon type identification (national use)
(default value of bits 127 to 132= 000000);
- bits 133 to 144:
12-bit BCH code.
* Fig 3.25.b defines the coding scheme for all National Location Protocols, some newer beacons where the coarse position
in PDF-1 is always selected to be as close as possible to the actual position will have a maximum offset in PDF-2 of +/- 1
minute, in which case bits 114 and 121 of the message will not be used and should be permanently set to “0”.

3-40

3.4.5
Coding the RLS Location Protocols
The applicable Return Link System (RLS) location protocol is selected by setting bit 26
(protocol flag) to "0" and bits 37 to 40 to “1101”. The protocols are available in long message
format with bit 25 (format flag) set to “1”.
The beacon identification data is provided in a standardised format in 26 bits of the PDF-1
and can be encoded for different RLS beacon types as shown in Figure 3.26.
Position data to a 30-minute resolution is also given in the PDF-1, with position offsets to
4-second resolution in the PDF-2. The coding of this data is the same for all RLS beacons and
is described with further details in Figure 3.27.
Supplementary and RLS data is encoded in the message as shown in Figure 3.28.

3-41

Figure 3.26: Coding the RLS Location Protocol
Bits


.... 36

.. .... 40
41 … 42 43
.... 52

...


Country Code


Beacon
Type
10 bit RLS type
approval
certificate
Number
14 bit RLS ID
Serial Number


Country Code


Beacon
Type
10 bit National
RLS Number
14 bit serial
number assigned
by a Competent
Authority
Bits


.... 36

.. .... 40
41 … 42 43
.... 46

...


Country Code


Beacon
Type
1 1 1 1
20 bit last six
digits of MMSI
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
RLS location protocol code, set to: 1101;
- bits 41 to 42:
beacon type, set to: 00 for ELT, 01 for EPIRB, 10 for PLB, 11 for RLS Test Protocol
except when bits 43 to 46 have the value “1111” in which case these bits indicate the
following; “00” First EPIRB on Vessel, “01” Second EPIRB on Vessel, “10” PLB and “11”
Location Test Protocol;
- bits 43 to 52:
contain the 10-bit Cospas-Sarsat RLS truncated\*†‡  type approval certificate number of
the beacon (1 to 919) or National RLS Number, except when bits 43 to 46 are set to
“1111”;
- bits 53 to 66:
14-bit serial number (1 to 16,383) in binary form, or 14-bit identification data consisting of
a Competent Authority assigned serial number (1 to 16,383), associated with a National
RLS Number that has been allocated to an Administration by the Cospas-Sarsat
Programme (920 to 949), except when bits 43 to 46 are set to “1111”;
- bits 47 to 66:.
When bits 43 to 46 are set to “1111” then and only then, do these bits provide the last six
digits of the MMSI in binary form§.
Figure 3.27: Coding the Position Data in the RLS Location Protocols
* The 10-bit RLS truncated TAC or National RLS number is the last 3 decimal numbers in the TAC number data field, which
allows a range of 1 to 948.  The RLS beacon TAC number 949 is reserved for type-approval testing.
The RLS beacon TAC number or National RLS number series are assigned as follows:
1000 series is reserved for EPIRBs (i.e. 1001 to 1948),
2000 series is reserved for ELTs (i.e. 2001 to 2948), and
3000 series is reserved for PLBs (i.e. 3001 to 3948).
These are represented in the RLS messages as bits 41 to 42 (except when bits 43 to 46 are set to “1111”)  indicating the beacon
type series (EPIRB, ELT, or PLB) and a 10 bit (1-1024) TAC number which is added to the series to encode the full TAC number.
(e.g., TAC 1042 would be encoded as “01” for EPIRB in bits 41 to 42 representing 1nnn, where “nnn” is “042” determined by
“0000101010” in bits 43 to 52, and form a binary representation “00 0010 1010” of the decimal number “42”.
†  The numbers 920 to 948 (i.e., National RLS Numbers 920 to 948) are set aside for National Use by Competent Authorities. That
is full National RLS Numbers 1920 to 1948 for EPIRBs, 2920 to 2948 for ELTs, and 3920 to 3948 for PLBs.
‡ The numbers in the ranges x700 to x799 in the 1000, 2000 and 3000 series have been set aside for allocation to special-use beacon
models approved under letters of compatibility.
§ The full 9-digit MMSI is comprised of the Country Code in bits 27 to 36 providing the Flag State (MID) of the vessel and bits
47 to 66 providing the unique 6-digit identity for the vessel.

3-42

Bits

68-75
76 77-85 86-106 107-108 109-

115 116-119 120-123 124 125-128 129-132 133-144
Flag
Lat
Lat
degr
Flag
Long
Long
degr
21-bit
BCH code
Suppl.
Data
RLS
Data
Lat 
Sign
Lat 
min
Lat 
sec
long 
sign
Long 
min
Long 
sec
12-bit
BCH code
- bits 67 to 75:
latitude data (9 bits) with 30 minute resolution, including:
- bit 67:
Latitude flag (N=0, S=1)
- bits 68 to 75:
degrees (0 to 90) in 0.5 degree increments
(default value of bits 67 to 75 = 0 11111111);
- bits 76 to 85:
longitude data (10 bits) with 30 minute resolution including:
- bit 76:
Longitude flag (E=0, W=1)
- bits 77 to 85:
degrees (0 to 180) in 0.5 degree increments
(default value of bits 76 to 85 = 0 111111111);
- bits 86 to 106:
21-bit BCH code;
- bit 107 to 108:
Supplementary Data (See Figure 3.28)
- bit 109 to 114:
RLS Data (See Figure 3.28)
- bits 115 to 123:
offset () latitude data (9 bits) with 4 second resolution, including:
- bit 115:
 sign (0=minus, 1=plus)
- bits 116 to 119:
minutes (0 to 15) in 1 minute increments\*
- bits 120 to 123:
seconds (0 to 56) in 4 second increments
(default value of bits 115 to 123 = 1 0000 1111);
- bits 124 to 132:
offset () longitude data (9 bits) with 4 second resolution, including:
- bit 124:
 sign (0=minus, 1=plus)
- bits 125 to 128:
minutes (0 to 15) in 1 minute increments\*
- bits 129 to 132:
seconds (0 to 56) in 4 second increments
(default value of bits 123 to 132 = 1 0000 1111);
- bits 133 to 144:
12-bit BCH code.
* For RLS Location Protocol beacons the coarse position in PDF-1 is always selected to be as close as possible to the
actual position and will have a maximum offset in PDF-2 of +/- 15 minutes.

3-43

Figure 3.28: Coding the RLS Data in the RLS Location Protocols
Bits

68-75
76 77-85 86-106 107-108 109-

115 116-119 120-123 124 125-128 129-132 133-144
Flag
Lat
Lat
degr
Flag
Long
Long
degr
21-bit
BCH code
Suppl.
Data
RLS
Data
Lat 
Sign
Lat 
min
Lat 
sec
long 
sign
Long 
min
Long 
sec
12-bit
BCH code
- bit 107 to 108:
Supplementary Data;
- bit 107:
position data source flag set to "0" means that the position data encoded in
PDF-1 is provided by an external navigation device;
position data source flag set to "1" means that the position data encoded in
PDF-1 is provided by an internal navigation device;
- bit 108:
121.5 MHz radio-locating device flag set to "0" means that there is no
121.5 MHz auxiliary radio-locating transmitter in the beacon;
121.5 MHz radio-locating device flag set to "1" means that the beacon is
equipped with a 121.5 MHz auxiliary radio-locating transmitter;
- bit 109 to 114:
RLS Data;
- bit 109 to 110:
RLM Request
- bit 109:
Capability to process RLM Type-1:
"1": Acknowledgement Type-1 (automatic acknowledgement) accepted
by this beacon,
"0": Acknowledgement Type-1 not requested and not accepted by this
beacon;
- bit 110:
Capability to process manually generated RLM:
"1": Manually generated RLM (such as Acknowledgement Type-2)
accepted by this beacon,
"0": Manually generated RLM (such as Acknowledgement Type-2) not
requested and not accepted by this beacon
- bit 111 to 112:
Beacon feedback (acknowledging the reception of the RLM)
- bit 111:
Feedback on RLM Type-1:
"1": Acknowledgement Type-1 (automatic acknowledgement) received
by this beacon,
"0": Acknowledgement Type-1 not (yet) received by this beacon;
- bit 112:
Feedback on RLM Type-2:
"1": Acknowledgement Type-2 (or manually generated RLM) received
by this beacon,
"0": Acknowledgement Type-2 not (yet) received by this beacon
- bit 113 to 114:
RLS Provider Identification
"01": GALILEO Return Link Service Provider,
"10": GLONASS* Return Link Service Provider,
“11”: BDS* Return Link Service Provider, and
"00": Spare (for other RLS provider);
* Beacons shall not be coded with these coding options (except for the RLS location test protocol) until the GLONASS
or BDS RLS services are declared operational by the Cospas-Sarsat Programme and type approval for these versions
of the RLS Location protocols cannot be granted.

3-44

3.4.6
Coding the ELT(DT) Location Protocols
The applicable ELT(DT) location protocol is selected by setting bit 26 (protocol flag) to "0"
and bits 37 to 40 to “1001”. The protocols are available in long message format with bit 25
(format flag) set to “1”.
The beacon identification data is provided in a standardised format in 26 bits of the PDF-1
and can be encoded for different ELT(DT) ID types as shown in Figures 3.29 to 3.31.
Position data to a 30-minute resolution is also given in the PDF-1, with position offsets to
4-second resolution in the PDF-2. The coding of this data is the same for all ELT(DT) beacons
and is described with further details in Figure 3.32.
Supplementary ELT(DT) data is encoded in the message as shown in Figure 3.33.
WARNING:  Administrations are cautioned that the use of the ELT(DT) location protocol
with 24-bit aircraft address (Figure 3.29) including the PDF-2 rotating field option (Figure
3.33), is the only ELT(DT) coding protocol which is fully compatible with the Cospas-Sarsat
MCC network allowing the automated processing of these messages for transmission to the
ICAO LADR.  All other ELT(DT) protocol options will require Administrations’ aviation
authorities to establish guidance for their aircraft operators to deposit the alert information
into the ICAO LADR.
Figure 3.29: Coding the ELT(DT) Location Protocol with the 24-bit Aircraft Address
Bits 25


.... 36

.. ..

41 ..42 43
....................


Country Code


0   0
24 bit Aircraft Address
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
ELT(DT) location protocol code, set to: 1001;
- bits 41 to 42:
Aircraft ID, 2-bits for type of beacon identity set to “00” for Aircraft 24 bit address;
- bits 43 to 66:
contain the 24-bit aircraft address (only one ELT per aircraft can be identified using this protocol).
Or
- bits 43 to 66:
encoded with all “0”s or all “1”s to indicate ELT(DT) Location Test protocol.

3-45

Figure 3.30: Coding the ELT(DT) Location Protocol with the Aircraft Operator Designator
and Serial Number
Bits


.... 36 37
.. ..

41 … 42

....


...


Country Code  1


0   1
(15 bits)
3-letter of AOD
code
9 bit ELT Number
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
ELT(DT) location protocol code, set to: 1001;
- bits 41 to 42:
Aircraft ID, 2-bits for type of beacon identity set to “01” for Aircraft operators designator and serial
number;
- bits 43 to 57:
3-letter aircraft operator designator, encoded using the Modified-Baudot code (see Table B.1 of
Annex B) in shortened form: the first bit which is =1 for any letter is deleted to form a 5 bit code;
- bits 58 to 66:
9-bit unique ELT number (1-511) in binary form assigned by operator.
Or
- bits 43 to 66:
encoded with all “0”s or all “1”s to indicate ELT(DT) Location Test protocol.
Figure 3.31: Coding the C/S Serial Identification Data in the ELT(DT) Location Protocol
Bits


.... 36

.. .... 40
41 … 42 43
.... 52

...


Country Code


1    0
10 bit C/S type
approval
certificate
Number
14 bit Serial
Number
- bit 25:
format flag set to "1" (long message);
- bit 26:
protocol flag set to "0";
- bits 27 to 36:
country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
- bits 37 to 40:
ELT(DT) location protocol code, set to: 1001;
- bits 41 to 42:
Aircraft ID, 2-bits for type of beacon identity set to “10” for TAC with serial number;
- bits 43 to 52:
contain the 10-bit Cospas-Sarsat type approval certificate number of the beacon
(1 to 1,023);
- bits 53 to 66:
14-bit serial number (1 to 16,383) in binary form.
Or
- bits 43 to 66:
encoded with all “0”s or all “1”s to indicate ELT(DT) Location Test protocol.

3-46

Figure 3.32: Coding the Position Data in the ELT(DT) Location Protocols
Bits

68-75
76 77-85 86-106
107-114
115 116-119 120-123 124 125-128 129-132 133-144
Flag
Lat
Lat
degr
Flag
Long
Long
degr
21-bit
BCH code
Suppl. Data Lat 
Sign
Lat 
min
Lat 
sec
long 
sign
Long 
min
Long 
sec
12-bit
BCH code
- bits 67 to 75:
latitude data (9 bits) with 30 minute resolution, including:
- bit 67:
Latitude flag (N=0, S=1)
- bits 68 to 75:
degrees (0 to 90) in 0.5 degree increments
(default value of bits 67 to 75 = 0 11111111);
- bits 76 to 85:
longitude data (10 bits) with 30 minute resolution including:
- bit 76:
Longitude flag (E=0, W=1)
- bits 77 to 85:
degrees (0 to 180) in 0.5 degree increments
(default value of bits 76 to 85 = 0 111111111);
- bits 86 to 106:
21-bit BCH code;
- bit 107 to 114:
Supplementary Data (See Figure 3.33)
- bits 115 to 123:
offset () latitude data (9 bits) with 4 second resolution, including:
- bit 115:
 sign (0=minus, 1=plus)
- bits 116 to 119:
minutes (0 to 15) in 1 minute increments\*
- bits 120 to 123:
seconds (0 to 56) in 4 second increments
(default value of bits 115 to 123 = 1 0000 1111);
- bits 124 to 132:
offset () longitude data (9 bits) with 4 second resolution, including:
- bit 124:
 sign (0=minus, 1=plus)
- bits 125 to 128:
minutes (0 to 15) in 1 minute increments\*
- bits 129 to 132:
seconds (0 to 56) in 4 second increments
(default value of bits 123 to 132 = 1 0000 1111);
- bits 133 to 144:
12-bit BCH code.
* Section A3.3.7 defines the coding scheme for the ELT(DT) Location Protocol. For these new beacons the coarse
position in PDF-1 is always selected to be as close as possible to the actual position and will have a maximum offset
in PDF-2 of +/- 15 minutes.

3-47

Figure 3.33: Coding the Supplementary Data in the ELT(DT) Location Protocols
Bits

68-75
76 77-85 86-106
107-114
115 116-119 120-123 124 125-128 129-132 133-144
Flag
Lat
Lat
degr
Flag
Long
Long
degr
21-bit
BCH code
Suppl. Data Lat 
Sign
Lat 
min
Lat 
sec
long 
sign
Long 
min
Long 
sec
12-bit
BCH code
- bit 107 to 108:
Means of Activation;
“00”: manual activation by the user
“01”: automatic activation by the beacon
“10”: automatic activation by external means
“11”: spare;
- bit 109 to 112:
Encoded Altitude;
“0000”: altitude is less than or equal to 400 m (1312 ft)
“0001”: altitude is greater than 400 m (1312 ft) up to and including 800 m (2625 ft)
“0010”: altitude is greater than 800 m (2625 ft) up to and including 1200 m (3937 ft)
“0011”: altitude is greater than 1200 m (3937 ft) up to and including 1600 m (5249 ft)
“0100”: altitude is greater than 1600 m (5249 ft) up to and including 2200 m (7218 ft)
“0101”: altitude is greater than 2200 m (7218 ft) up to and including 2800 m (9186 ft)
“0110”: altitude is greater than 2800 m (9186 ft) up to and including 3400 m (11155 ft)
“0111”: altitude is greater than 3400 m (11155 ft) up to and including 4000 m (13123 ft)
“1000”: altitude is greater than 4000 m (13123 ft) up to and including 4800 m (15748 ft)
“1001”: altitude is greater than 4800 m (15748 ft) up to and including 5600 m (18373 ft)
“1010”: altitude is greater than 5600 m (18373 ft) up to and including 6600 m (21654 ft)
“1011”: altitude is greater than 6600 m (21654 ft) up to and including 7600 m (24934 ft)
“1100”: altitude is greater than 7600 m (24934 ft) up to and including 8800 m (28871 ft)
“1101”: altitude is greater than 8800 m (28871 ft) up to and including 10000 m (32808 ft)
“1110” altitude is greater than 10000 m (32808 ft)
“1111”: default value if altitude information is not available
- bit 113 to 114:
Encoded location freshness;
"00”: PDF-2 rotating field indicator,
“01”: encoded location in message is more than 60 seconds old, or the default encoded position is
transmitted,
“10”:  encoded location in message is greater than 2 seconds and equal to or less than 60 seconds
old,
“11”: encoded location in message is current (i.e., the encoded location freshness is less or equal to
2 seconds).
When bit 113 to 114 = “00” i.e., PDF-2 Rotating Field
Bits

68-75
76 77-85 86-106
107-114
115-117
118-132
133-144
Flag
Lat
Lat
degr
Flag
Long
Long
degr
21-bit
BCH code
Suppl. Data
PDF-2
Rotating
Field Type
PDF-2 Rotating
Field
12-bit BCH code
-
bits 113 to 114:
“00”: PDF-2 rotating field indicator
-
bit 115 to 117: PDF-2 Rotating Field Type
“000”: Aircraft Operator 3LD
Other: Spare
-
bit 115 to 117: equal to “000”

3-48

-
bit 118 to 132 3-letter aircraft operator designator\*, encoded using the Modified-Baudot code (see
Table B.1 of Annex B) in shortened form: the first bit which is =1 for any letter is deleted to
form a 5 bit code; if there is no 3LD for the aircraft operator, then the 3LD is coded as “ZGA”,
i.e., bits 115 to 132 are set to 000 10001 01011 11000).
3.4.6.1 ELT(DT) Cancellation Message
In case of alert cancellation, a specific message shall be sent with the following bit
assignment:
bits 37 to 40:
4-bit protocol code as defined as 1001
bits 41 to 42:
2-bits for type of beacon identity
bits 43 to 66:
24 bits of beacon identification data, or ELT(DT) Location Test
protocol
bits 67 to 75:
fixed sequence “1 11111010”;
bits 76 to 85:
fixed sequence “1 111111010”;
bits 86 to 106:
BCH-1
bits 107 to 114:
fixed sequence “00111100”
bits 115 to 123:
fixed sequence “0 1111 0000”
bits 124 to 132:
fixed sequence “0 1111 0000”
bits 133 to 144:
BCH-2
3.4.7
Coding the Test Location Protocols
The test protocol for all coding methods (i.e. "user" and "location" protocols (except RLS and
ELT(DT) protocols)) is encoded by setting bits 37-39 (protocol code) to "111". In addition,
bit 40 is used to distinguish between the test format of the standard location protocols (bit 40
= "0") and national location protocols (bit 40 = "1"). With the above exception, the coding
described in section 3.3.5 and Figure 3.15 (Test User Protocol) remain valid for the Test
Location Protocol.
The RLS test protocol is indicated by setting bits 41 to 42 to binary “11”.  Thus, for an RLS
test beacon it is not possible to distinguish between different types of beacon (i.e., ELT,
EPIRB, or PLB).  The remaining fields allow multiple beacon IDs to be encoded however
there will be some ambiguity as to the beacon type and hence whether the beacon should be
assigned to the 1000, 2000, or 3000 series of TACs would be unknown with the test protocol.
The ELT(DT) test protocol is indicated by setting bits 43 to 66 to all “0”s or all “1”s.  Thus,
for an ELT(DT) there are only two ID bits (41 and 42) which can be used to distinguish
between different test protocol beacons available for use in combination with the country code
(bits 27 to 36) field.
* 3LD is a 3-Letter aircraft operator Designator from the list of "Designators for Aircraft Operating Agencies,
Aeronautical Authorities and Services" published by the International Civil Aviation Organization (ICAO) as
document 8585.

3-49

- END OF SECTION 3 -

4-1

4.
SECOND GENERATION 406-MHz BEACON CODING (SGB)
4.1
C/S T.018 Beacon Types
Cospas-Sarsat 406 MHz beacons can be used in different environments and for a variety of
applications such as EPIRBs that service the maritime environment, ELTs and ELT(DT)s
(aviation) or PLBs (personal use). The specification of the distress signal characteristics (document
C/S T.018), which ensures that all 406 MHz beacons are compatible with the Cospas-Sarsat Space
Segment, is applicable to all types of beacons. However, different user groups have different needs;
hence the need for various coding options. To satisfy these requirements, the Cospas-Sarsat
specification provides for various coding options which for FGBs were divided in two groups of
coding protocols:  user protocols and location protocols.
However, unlike FGBs, SGBs do not have coding protocols and the differentiation between
"location” and "non-location” beacons is provided by the data encoded in the location field of the
SGB message.  See section 4.2.2 below for a description.
All SGB messages have the general structure of the 406 MHz digital message described in section
4.2 of this document.
Administrations will normally specify which coding options can be used for the applications that
they authorise. Manufacturers of 406 MHz beacons should contact the appropriate national
authorities to determine how beacons should be coded for each country. The document C/S S.007
“Handbook of Beacon Regulations”, which is semi-annually updated by the Cospas-Sarsat
Secretariat, provides a list of points of contact (including addresses and telephone numbers) for
beacon matters in a number of countries.
Administrations should not authorise coding options which are not currently allocated or permitted
by the Cospas-Sarsat specification for 406 MHz beacons (C/S T.018).

4-2

4.2
General Coding Requirements
4.2.1
Overall SGB Message Structure
Preamble
Correcting bits
Useful message
166.7 ms
673.3 ms
160 ms
1s
Figure 4-1: Burst general structure
Figure 4-1 depicts the general message structure of an SGB burst.
4.2.1.2 Preamble
The initial 166.7 ms of the transmitted signal shall consist of the combination of the first
6400 chips of the two PRN code segments (each segment 38,400 chips long for the entire
burst) used to spread the I and Q message components as illustrated in Figure 2-3.  There
will be no useful information encoded on either the I or Q components during the
preamble. I and Q component information bits shall all be set to ‘0’ during the preamble.
4.2.1.3 Useful Message
The contents of the useful message are described in section 4.2.2 below.
4.2.1.4 Protected Data Field
The entire 202 bits forming the message data field are followed by a 48-bit Bose-
Chaudhuri-Hocquenhem (BCH) error-correcting code (bits 203 to 250), in a field defined
as the BCH error correcting field (BCH). This code can detect and correct up to six bit
errors in the 250 bits of the SGB message. The error-correcting code is generated from
the content of the message field as described in Appendix B of C/S T.018. Therefore, it
must be computed and encoded together with the message data. When updates to the
message content are required for encoding position data, or other dynamic message data
(time since activation, remaining battery life, etc.), the error-correcting code must be
regenerated prior to each transmission as the message content changes.
4.2.2
General Format and Field Definition of the SGB 406-MHz Message
The message transmitted by a Cospas-Sarsat SGB 406-MHz beacon is encoded as shown in
Figure 4-1.

4-3

202 information bits
48 error correction bits
154 bit main field
48 bit rotating field
48 bit BCH field
Main Message
Spare

…


…


….……


…………….


Figure 4-2: Message content bits
A graphical representation of the detailed SGB message structure can be found on the
Cospas-Sarsat website at:
https://www.cospas-sarsat.int/images/content/articles/SGB\_Message\_Structure\_-\_63\_Hex\_-
\_23\_Hex\_-\_15\_Hex\_Ver-11-NN.pdf
The SGB graphic  provided on the Cospas-Sarsat website summarizes in a single graphic the
SGB message content specified in document C/S T.018. It shows the structure of the SGB
message, what information will be provided by the SGB messages, and where this information
will be allocated in the message. It also shows the relationship between the 63 hexadecimal
characters composing the full SGB Message and the specific contents of the 23 Hex ID and
of the truncated SGB 15 Hex ID.
4.2.3
23-Hexadecimal ID
The 23-Hex ID unlike a FGB 15-Hex ID is not directly transmitted in the beacon message.
The SGB 23-Hex ID needs to be constructed by combining specific data bits in the message
as described in the SGB data structure graphic (see section 4.2.2) or document C/S T.018,
Table 3.10.  The 23-Hex ID can be truncated to become a 15-Hex ID and the combination
rules ensure that it results in a unique Hex ID as one of the spare 15-Hex IDs from the FGB
coding standards has been reserved for that purpose.
4.3
SGB Specific Coding Features
4.3.1
Location vs. Non-Location Encoded Beacons
As SGBs all use a similar message format (i.e., no different protocols), the capabilities of the
beacon to provide an encoded location in the message are indicated by the use of default
values in the encoded message.  If the beacon is capable of providing encoded location
information than the beacon message will either contain an encoded GNSS location or the
default value in bits:
44 to 66 of “0 1111111 000001111100000”, and
67 to 90 of “0 11111111 111110000011111”.

4-4

Alternatively, if the beacon does not have GNSS location capabilities, the alternate default
values (i.e., the N/S (bit 44) and E/W (bit 67) flags are switched from 0 to 1 in the default
pattern indicating no GNSS capability is provided by this beacon) are used as follow:
44 to 66 of “1 1111111 000001111100000”, and
67 to 90 of “1 11111111 111110000011111”.
4.3.2
Spreading Codes
SGBs messages are transmitted using one of two distinct pseudo random noise (PRN)
spreading codes.  These two codes allow “normal” distress transmissions to be distinguished
from “self-test” transmissions.
4.3.3
Transmission Schedule
SGB are designed to include a variable transmission rate into their transmission schedule.
This allows more frequent transmissions to occur earlier in the distress sequence and gradually
reducing the transmission rate later in the distress which allows the conservation of the beacon
battery. Table 4.1 indicates the nominal transmission repetition intervals during various
phases of beacon operation.
Table 4.1: Transmission Schedule
IAMSAR Stage
Nominal Time from
Activation
Transmission
Nominal Repetition
Interval
Randomization
Initial
0 to 30* Seconds
5 Seconds

Action / Planning
30† Seconds to
30 minutes
30 Seconds
± 5 Seconds
30 minutes +
120 Seconds
± 5 Seconds
ELT (DT)
0 to 120 Seconds
5 Seconds

120 to 300 Seconds
10 Seconds

300 Seconds +
28.5 Seconds
± 1.5 Seconds
4.3.4
Message Fields
The message fields are described in the SGB data structure graphic (see section 4.2.2).
4.3.4.1 Main Field
The following text provides basic guidance on programming an SGB. Unlike FGBs, all SGBs
are serialized and include a TAC and Serial Number in their transmitted messages forming a
* For EPIRBs this value is 33 seconds.

4-5

unique beacon ID.  However, SGBs may also contain additional vessel identification
information (analogous to coding protocols in FGBs) as a secondary identity field.
TAC Number – The Type Approval Certificate number between 10,000 and 17,999 assigned
to the beacon by the Secretariat excluding the suffixes ‘M’ and ‘m’, see document C/S T.021
Section 2.2.1 for further details.
Serial Number – A numerical serial number between 0 and 16,383 assigned by the beacon
manufacturer to a beacon during production.
The TAC and Serial Number together form a unique identity for each beacon produced and
shall not be capable of being changed once programmed by the manufacturer. Once a
manufacturer uses up all available serial numbers, they shall apply to the Secretariat for an
Extension TAC in order to continue inserting a unique identity into every beacon that they
produce. Identities shall never be reused, if for example a beacon is scrapped, then that identity
is not reused.
Country Code – The three-digit decimal country code based on the ITU MID related to the
country of beacon registration, or the normal place of residence of the beacon owner. Note
that the Country Code is not necessarily the same as the first 3 digits of the Maritime Mobile
Service Identity (MMSI) that may be assigned to a beacon associated with a vessel. The
country code may be changed as necessary during the life of a beacon to reflect changes of
beacon registration or place of residence.
Vessel ID – If a Vessel (Aircraft or Ship) Identity is available / known then it should be
included in the beacon message using one of the following options:
SHIPS – In addition to the TAC and Serial Number ships may also be coded with either the
MMSI of the vessel or its Radio Call Sign, with preference being given to the former.  If
neither are available then these fields are set to default values.
MMSI – An identity allocated to a beacon associated with a vessel in accordance with
Recommendation ITU-R M.585. This may be the MMSI assigned to a ship station as defined
in ITU-R M.585 Annex 1 Section 1 or the MMSI assigned to a craft associated with a parent
ship as defined in ITU-R M.585 Annex 1 Section 5. It shall not be the freeform number
identity as defined in ITU-R M.585 Annex 2 Section 2, commencing with 970, 972 or 974
which is only used to identify an AIS locating signal transmitter if one is included as part of
a 406 MHz beacon. However, if the beacon includes an AIS locating signal, then the AIS
identity commencing with 974 should be added in bits 94-123 AFTER the ships MMSI.
Note that if during the life of a beacon a vessel on which it is provided changes flag state and
as a result is allocated a different MMSI, then the MMSI in the beacon must be updated
accordingly. This will not affect the identity of the AIS locating signal, however, as this is not
linked to the vessel identity.

4-6

Radio Call Sign – If an MMSI for the vessel is not available then the ships Radio Call Sign
may be inserted here instead. Radio Call Signs of up to 7 characters may be inserted.
AIRCRAFT – In addition to the TAC and Serial Number aircraft may also be coded with
one of three forms of identity, either the Aircraft Registration Marking (commonly referred
to as the Tail Number), the Aviation 24-Bit Address (as used by the ADS-B system) or the
Aircraft Operator designator followed by a serial number. The Aviation 24-Bit Address may
also be followed by the 3-letter Aircraft Operator Designator (3LD), which is essential for
ELT(DT)s.
Aircraft Registration Marking – This identity, often referred to as the aircraft Tail Number
can be encoded in up to 7 alphanumerical characters.
Aviation 24-Bit Address – This identity is becoming more common in larger aircraft as it is
allocated to an aircraft for use with systems such as the ADS-B. For ELT(DT)s required to
meet the Automatic Distress Tracking (ADT) requirements of the ICAO GADSS system, it
is essential to code the ELT(DT) with the aircraft 24-Bit address followed by the 3-letter
Aircraft Operator Designator, as both of these data items are required by the ICAO Location
of an Aircraft in Distress Repository (LADR). Note that the Aircraft 24-Bit address followed
by the Aircraft Operator Designator can also be used to code ELTs other than ELT(DT)s if
required.
Aircraft Operator and Serial Number – This identity is less common but can be used to
identify an aircraft it consists of the identity of the aircraft operator followed by a serial
number allocated to the beacon by the aircraft operator to create a unique identity for that
aircraft.
[Other message fields not currently described include:
• Status of Homing Device
• RLS Function
• Test Protocol
• Encoded GNSS Location
• Beacon Type]
4.3.4.2 Rotating Fields
[Text in this section is still under development.]
4.3.5
SGBs and Programming Adaptors
[Text in this section is still under development.]
[Key features to describe include:

4-7

• SGB programming adaptors are controlled by C/S requirements,
• SGB programming adaptors do not program the beacons, they simply provide ID data
which supersedes the identity information in the beacon when it is connected to the
beacon and is used in transmitted messages (which is a different paradigm than used
with FGBs),
• Use of PA requires two registrations, one of the adaptor related beacon ID and also
the ID associated with the beacon model the adaptor can be used with]
4.3.6
SGBs Message Format for Transmission in the Ground Segment
A SGB message consist of 250 bits which does not divide by four to form an even
hexadecimal number and therefore two leading 0’s are added to “round” out to an even
number of Hexadecimal characters.  When displaying a message as 63 hex characters, one bit
is inserted at the beginning of the message to indicate the PRN sequence (0 = Normal, 1 =
self-test), followed by one zero, to form the 63 hexadecimal representation (2 bits + 250 bit
message) for processing by the Cospas-Sarsat ground segment.
4.4
SGB Coding Examples
4.4.1
EPIRBs
[Text in this section is still under development.]
4.4.2
ELTs
[Text in this section is still under development.]
4.4.3
ELT(DT)s
[Text in this section is still under development.]
4.4.4
PLBs
[Text in this section is still under development.]
– END OF SECTION 4 –

5-1

5.
BEACON REGISTRATION
5.1
Purpose of Beacon Registration
One of the advantages of 406 MHz beacons is that each beacon is designed to transmit a unique
message allowing its identification. However, to take advantage of this feature, a register is needed to
relate each beacon to a particular ship, aircraft or individual user. Beacon registration is valuable for
the resolution of SAR cases. Identification of the beacon user (ship, aircraft or individual user) helps
SAR services to properly respond to a distress alert provided that the registration database contains
the information listed below in section 5.2. This information provides important search planning data
to allow the timely rescue of people in distress. Registration information also helps to resolve false
alerts without diverting SAR resources.
All 406 MHz beacons (EPIRBs, ELTs or PLBs) should, therefore, be registered. Every administration
requiring or allowing the use of 406 MHz beacons should make suitable arrangements for the
registration of 406 MHz beacons, and enforce their registration.
5.2
General Principals for Registering 406 MHz Beacons
5.2.1
Where to Register 406 MHz Beacons
The International Maritime Organization (IMO) and the International Civil Aviation
Organization (ICAO) require that administrations authorising the use of 406 MHz beacons on
board vessels and aircraft make provisions for registering these beacons in a database register
that is accessible by SAR services 24 hours a day. The administrative and operational contact
details for national 406 MHz beacon registers that have been reported to Cospas-Sarsat are
published respectively in the following Cospas-Sarsat documents, which can be downloaded
free of charge from the Cospas-Sarsat website at www.cospas-sarsat. int:
• "Handbook of Beacon Regulations” (C/S S.007);
• "Cospas-Sarsat Data Distribution Plan” (C/S A.001).
Beacon owners should first consult the Cospas-Sarsat website to determine whether a national
registration service exists in which they can register their beacons. For beacon owners in
countries that do not operate national registers, Cospas-Sarsat has implemented an
International 406 MHz Beacon Registration Database (IBRD).
The IBRD is provided solely for the purpose of assisting SAR Services in SAR operations
and is not intended to fulfil the obligation of National Administrations, as required by IMO
or ICAO. A more detailed description of the IBRD is provided at Section 5.3.

5-2

5.2.2
Country of Registration – Coding Procedure
As the administration authorising the use of the beacon does not always maintain a beacon
registration database but could, alternatively, use the service of another administration or the
IBRD, the country code in the 406 MHz beacon message must provide a link that identifies
the operator of the database (i.e., the operator of the national database where the records are
held). The country code should always enable SAR services to retrieve pertinent registration
data through the point of contact associated with that country code, either the IBRD (if the
country has chosen to use the IBRD for registration of beacons with their country codes), or
the national registration facility.
If a registration database is implemented and maintained regionally by agreement between
several countries, the administration of the country of registration should arrange with
Cospas-Sarsat and appropriate SAR authorities that its country code be recognised as one
associated with that particular database, and provide information about such arrangements to
the beacon owner.
5.2.3
Control and Updating of Registered Information
Administrations should provide the means for beacon owners to readily and expeditiously
update information in the registration database. Owners of beacons are responsible for
reporting any change in the registered information, including:
• de-registration of the beacon in the case of a change of ownership, or
• indicating if the beacon has been stolen or permanently removed from service.
Administrations should also regularly verify the accuracy of the database information by
contacting the beacon owners. A census of registered 406 MHz beacons should be undertaken
by administrations at least every two years. Administrations should also require a check of
the beacon registration during mandatory periodic inspections of the beacon.
Authorities maintaining or using databases should ensure that information supplied for beacon
registration is treated as proprietary, and ensure that it is used only by appropriate recognised
authorities.
Specific guidance for updating registration information contained in the IBRD is provided at
Section 5.3.2.
5.2.4
Access to Registration Databases
Administrations maintaining registration databases should provide the means for SAR
services to obtain relevant information on a 24 hour, seven day per week basis. Beacon
registration information contained in the IBRD can be accessed by SAR services on a 24 hour
basis via the Internet. SAR services requiring a password to access the IBRD should submit
requests to Cospas-Sarsat via their Representative to either IMO, ICAO or the Cospas-Sarsat
Programme.

5-3

5.2.5
Content of National Registration Databases
It is desirable that the appropriate information from Tables 5.1, 5.2 and 5.3 be recorded in
beacon registration databases or in other appropriate registers and be made available to SAR
services in case of distress alerts. Examples of beacon registration cards are provided in the
document C/S S.007 “Handbook of Beacon Regulations”, which is semi-annually updated by
the Cospas-Sarsat Secretariat.
5.2.6
Accuracy of Beacon Identification (15 / 23 Hex ID)
It is critical that the beacon’s 15 or 23 Hex ID (C/S T.001 beacons use a 15 Hex ID, C/S T.018
beacons use a 23 Hex ID) is correctly entered in the registration database as any mismatch
between the data encoded into the beacon and that in the database may delay a rescue or
provide misleading information to SAR services. Before proceeding, Administration involved
in the registration, such as beacon maintenance facilities or beacon register operator, should
be requested and recommended to check and verify the correct programming of the beacon.
Errors may result in a mismatch in a number of ways, but the most common come from
misreading the 15 / 23 Hex ID and entering an incorrect 15 / 23 Hex ID into the database, for
example, entering a letter ‘D’ as an ‘0’ or a letter ‘B’ as an ‘8’.
In order to reduce such data entry errors, a checksum for T.001 compliant  beacons has been
implemented on the IBRD and some national registration databases and is under development
or implemented for T.018 compliant beacons, whereby the beacon manufacturer calculates
and provides a 5 digit checksum, which is checked during registration data entry to identify
possible input errors.
Provision of the beacon registration checksum by manufacturers, though not required, is
strongly encouraged. Guidelines on the use of the beacon registration checksum are provided
in Annex D.
5.3
Cospas-Sarsat International 406 MHz Beacon Registration Database (IBRD)
(www.406registration.com)
The IBRD is hosted on the Internet at www.406registration.com. It provides beacon owners who do
not have access to national registration facilities the capability to register their beacons or have their
beacons registered on their behalf. The IBRD has been configured as follows:
registrations will not be accepted for beacon type(s) with country codes of
countries that have advised Cospas-Sarsat that they operate national registers;
registrations of beacon type(s) will be accepted only from the designated
national representative (the National Data Provider) in countries that have
informed Cospas-Sarsat that they will use the IBRD, but want to control the entry
of registration data at a national level; and
registrations of beacon type(s) will be accepted directly from beacon owners via
the Internet, if neither a) nor b) apply.

![Image 1 from page 72](/images/cospas-sarsat/G-series/G005/G005_page_72_img_1.png)

![Image 2 from page 72](/images/cospas-sarsat/G-series/G005/G005_page_72_img_2.png)

![Image 3 from page 72](/images/cospas-sarsat/G-series/G005/G005_page_72_img_3.png)

5-4

For direct registration by the beacon owner (paragraph (c) above), the IBRD provides a web based
user friendly interface in English, French, Russian and Spanish languages that makes registering new
beacons and updating existing registration information both quick and easy. The application includes
extensive online help features that answer most of the common questions that arise during the
registration process. For issues not addressed in the online help, users can also send questions directly
to the Database Administrator via Email.
5.3.1
IBRD Management Policy
Cospas-Sarsat policy regarding the operation and management of the IBRD is contained in the
document C/S D.004, "Operations Plan for the Cospas-Sarsat International 406 MHz Beacon
Registration Database”, which is available at www.cospas-sarsat.int. Users of the IBRD are
encouraged to read this document in its entirety. As a minimum IBRD users and potential users should
be aware of the following:
The content of registration information stored in the IBRD is the responsibility
of the person, organisation, or Administration that provides the information.
Cospas-Sarsat does not accept any responsibility or liability in respect of the
accuracy of registration information submitted by users.
Cospas-Sarsat will only accept beacon registrations submitted via the online
facilities provided by the IBRD. Beacon registrations submitted in paper format or
via other communication facilities will not be accepted.
Cospas-Sarsat will not modify beacon registration information, unless absolutely
essential to repair a problem that, if not corrected, could damage the system or
corrupt the database.
Cospas-Sarsat will implement procedures to avoid where possible the loss or
corruption of beacon registration data in the IBRD. Nevertheless, Cospas-Sarsat
will not accept responsibility for any loss or corruption of registration information
that may occur.
Cospas-Sarsat will not provide facilities in the IBRD to accommodate or enforce
national requirements nor provide guidance on matters that fall within the
jurisdiction of national administrations (e.g., will not limit the coding options
accepted by the IBRD based on specific requirements established at the national
level, will not recommend specific beacon models for use, will not identify which
beacon models are authorised by specific national administrations, etc.).
The IBRD was developed to improve the effectiveness of Cospas-Sarsat alert data,
and is offered for use “as provided”. Cospas-Sarsat will support the operation of
the IBRD on a best effort basis, but provides no guarantee in respect of its
availability or performance.
The IBRD includes security features that limit the release of registration data to
SAR services. Nevertheless, Cospas-Sarsat will not be responsible for unauthorised

![Image 1 from page 73](/images/cospas-sarsat/G-series/G005/G005_page_73_img_1.png)

![Image 2 from page 73](/images/cospas-sarsat/G-series/G005/G005_page_73_img_2.png)

![Image 3 from page 73](/images/cospas-sarsat/G-series/G005/G005_page_73_img_3.png)

![Image 4 from page 73](/images/cospas-sarsat/G-series/G005/G005_page_73_img_4.png)

![Image 5 from page 73](/images/cospas-sarsat/G-series/G005/G005_page_73_img_5.png)

![Image 6 from page 73](/images/cospas-sarsat/G-series/G005/G005_page_73_img_6.png)

![Image 7 from page 73](/images/cospas-sarsat/G-series/G005/G005_page_73_img_7.png)

5-5

access or unauthorised changes to registration data which may result from
malicious activities.
Cospas-Sarsat, on a best effort basis, will respond to requests for assistance by
Administrations, SAR services and beacon owners. Support services provided by
Cospas-Sarsat will only be offered during normal working hours, and subject to the
availability and workload of the staff operating the database.
5.3.2
Updating Registration Information in IBRD
When a beacon is initially entered in the IBRD, a password is created that provides access to
the person / organisation that entered the registration information. This password is needed
for updating registration details as circumstances change. As a minimum, the registration data
provider should update the beacon registration every two years.
If data registered in the IBRD with a particular country code is under the exclusive control of
the Administration acting as the National Data Provider (section 5.3 (b)), then it is the sole
responsibility of that Administration to update registration data for all beacons with its country
code.
Registration reminder notices are automatically sent by email to the email address provided
in the beacon's registration record. It is thus very important that this email address be accurate
and current.
According to Annex 10 of ICAO’s Chicago Convention, a valid email address is mandatory
to register an ELT.

![Image 1 from page 74](/images/cospas-sarsat/G-series/G005/G005_page_74_img_1.png)

5-6

Table 5.1: Example of Basic Information to be Recorded and
Made Available through Beacon Registration
PLB
ELT
EPIRB
Beacon Identification
(15 Hex ID
\*)
Full length (22/30 Hex) message
with default position bits
Name of owner/
organization
email address
Name, address and phone
number of emergency
contact person
Alternative 24-hour
emergency phone
number
Town, city of residence
or base
Any critical personal
information
Beacon Identification
(15 Hex ID\*)
Full length (22/30 Hex) message
with default position bits
Aircraft registration number/
name of aircraft operator
email address
Name, address and phone
number of emergency
contact person
Alternative 24-hour
emergency phone
number
Type of aircraft, colour,
aircraft marking
Capacity for persons on
board (passengers, crew)
Home base
Emergency equipment
Navigation/communication
equipment
Beacon Identification
(15 Hex ID\*)
Full length (22/30 Hex) message
with default position bits
Name of vessel/
call sign/MMSI
email address
Name, address and phone
number of emergency
contact person
Alternative 24-hour
emergency phone
number
Brief vessel description
†
Capacity for persons on
board (passengers, crew)
Home port
Ship radio installation
(see Table 4-3)
* Beacon Identification (Beacon 15 Hex ID) - the 15 hexadecimal characters that uniquely identify each 406 MHz beacon.  This
Beacon Identification is derived from bits 26 to 85 of the 406 MHz beacon message.  For location protocols, the position data in
the first protected data field (PDF-1) is set to specified default values to obtain the unique Beacon 15 Hex ID.
† A brief vessel description may include:
- Length of vessel - Vessel type (see Table 5.2)
- Hull colour
- Hull type (see Table 5.2)
- Superstructure colour
- Propulsion (see Table 5.2).
Examples of ship descriptions are given hereunder:
Example A
Bulk carrier, 270 metres in length, black hull, white superstructure.
Example B
Stern trawler, 52 metres in length, green hull, grey superstructure.
Example C
Sail boat, 21 metres in length, double hull, single mast, white hull and superstructure.
Example D
Fishing vessel, 30 metres in length, superstructure aft, red hull and buff superstructure.

5-7

Table 5.2: Example of Ship Categories for Database Description
Vessel Type
Hull
Tug
Single hull
General cargo
Double hull
Bulk carrier
Triple hull
Tanker
Container
Passenger
Fishing
Ferry
Pleasure craft
Government
Drilling platform
Ro-ro
Other
Propulsion
Sail
Power
Single mast
Inboard
Two mast
Outboard
Three mast                      Inboard/Outboard
Table 5.3: Example of Ship Radio Installation Description
Inmarsat - A / B / M
Inmarsat - C
VHF with DSC / UHF
HF
MF with DSC
9 GHz Radar Transponder
– END OF SECTION 5  –

6-1

6.
406 MHz BEACON TYPE APPROVAL
6.1
Objectives and Scope of Type Approval
The issuing of performance requirements, carriage regulations and the testing and type approving
of 406 MHz distress beacons are the responsibilities of national authorities.
However, to ensure beacon compatibility with Cospas-Sarsat Space Segment and Ground Segment
equipment, it is essential that beacons meet specified Cospas-Sarsat performance requirements.
Compliance with these requirements provides assurance that the tested beacon performance is
compatible with, and will not degrade, the Cospas-Sarsat System.
The Cospas-Sarsat type approval tests are designed to ensure that the signals transmitted by the
beacons and their coding meet all applicable requirements of the Cospas-Sarsat specification for
406 MHz distress beacons (document C/S T.001, C/S T.015 or C/S T.018). These tests primarily
measure the electrical characteristics of beacon transmissions on 406 MHz and, with the exception
of temperature, do not take into account environmental conditions the beacon may encounter
during normal use.
In addition to the Cospas-Sarsat requirements, there might be other requirements (e.g., radio-
locating, environmental, activation, etc.) that administrations and/or International Organizations
may specify. Although a Cospas-Sarsat beacon must always be tested according to its normal
operating mode (i.e. with auxiliary devices in operation), the control of the performance of these
additional devices is not part of the Cospas-Sarsat testing requirements. Testing to ensure proper
operation of such additional features, under the required environmental conditions, is the
responsibility of the national authorities.
6.2
Cospas-Sarsat Type Approval Testing
In order to ensure that beacons do not degrade the System and to ensure uniformity of testing,
Cospas-Sarsat has defined the necessary tests and overall procedure which a manufacturer must
follow to receive Cospas-Sarsat type approval (document C/S T.007 “Cospas-Sarsat 406 MHz
Distress Beacon Type Approval Standard” or document C/S T.021 “Cospas-Sarsat Second
Generation 406 MHz Distress Beacon Type Approval Standard”). The tests described in C/S T.007
or C/S T.021 consist of a series of indoor laboratory tests in which the beacon does not transmit to
the satellite, and an outdoor functional test of the beacon transmitting to the satellite.
Cospas-Sarsat type approval testing must be performed by a Cospas-Sarsat accepted test facility.
The Cospas-Sarsat Secretariat maintains a list of such test facilities.
The beacon manufacturers should submit for Cospas-Sarsat type approval testing beacons coded
with a test protocol of appropriate type and format. All protocol types intended for use with the
beacon should be verified. The verification of the different coding options within each type is not

6-2

required. However, sample messages should be provided for each applicable coding protocol as
required by C/S T.007 or C/S T.021.
6.3
Cospas-Sarsat Type Approval Certificate
After successful completion of Cospas-Sarsat type approval testing, the test report and other
technical documentation (as specified in C/S T.007 or C/S T.021) is submitted to the Secretariat.
A Cospas-Sarsat type approval certificate (TAC) will be issued to the beacon manufacturer by the
Cospas-Sarsat Secretariat, after review and approval of the test results by Cospas-Sarsat.
TAC numbers will be issued only in the following cases:
• type approval of new beacon models,
• significant changes to an approved beacon model that has been retested at an accepted test
facility, and
• the need for additional serial numbers to encode a unique identification with the Standard
Location Protocol, provided that the capacity of all possible serial numbers associated with
previously assigned TAC numbers was fully used.
Should it be demonstrated subsequently that the production models do not meet the same standard
as the type approved model, Cospas-Sarsat reserves the right to revoke the certificate.
406 MHz beacons that have received Cospas-Sarsat type approval are listed on the Cospas-Sarsat
web-site at:
www.cospas-sarsat.int
6.4
National Type Approval
Cospas-Sarsat encourages national administrations to adopt national requirements (e.g., radio-
locating, environmental, activation, etc.) for 406 MHz beacons.
National administrations should also consider requirements which may contribute to reducing false
alerts such as:
• visual/audio indicators;
• 2 step activation mechanism; and
• including a description of testing procedures in the beacon user manual.
Depending on the intended use of the beacon, administrations should also consider the
recommendations of international organizations (e.g. IMO, ICAO, ITU, etc.). Administrations are
urged to harmonise their requirements with those defined by other administrations or international
organizations.

6-3

Administrations are urged to test beacons to the full requirements, or accept type approval results
from other administrations, and to only approve beacons for use that have received Cospas-Sarsat
type approval and passed all national type approval testing.
– END OF SECTION 6 –

7-1

7.
GENERAL GUIDELINES TO ADMINISTRATIONS, MANUFACTURERS
AND DISTRIBUTIONS
7.1
Guidelines to Administrations
406 MHz beacon coding protocols have been developed to satisfy maritime (EPIRB),
aeronautical (ELT) and personal (PLB) applications.
Regardless of the application or protocol used, the creation and maintenance of a registration
database is very important. Administrations are responsible for the definition and control of
beacon identifications registered in their national databases. All measures should be undertaken
to avoid possible duplication of beacon identifications.
Using the Cospas-Sarsat type approval certificate number may help ensure that the serial
number assigned by a manufacturer provides a unique beacon 15 Hex ID, independent of the
country of registration indicated by the country code. When a beacon 15 Hex ID is assigned by
the national administration of the country designated by the country code, bit 43 can be set to
“0” and the content of bits 44 to 83 redefined as required. However, in that case, the national
administration must ensure that the beacon 15 Hex ID is unique.
In selecting the best coding protocol, administrations should consider:
• whether harmony with beacon coding for other applications is desirable, where
national SAR systems support other than just one user community
(maritime/aviation/PLBs);
• what protocol is already in common use;
• availability of useful emergency information;
• timely availability of up-to-date registration data;
• ability to forward automatically to RCCs information from the database together
with 406 MHz alerts;
• ease and timeliness of updating registration database information;
• beacon cost;
• ease of beacon replacement world-wide;
• ease of re-coding beacons, if required;
• availability of extra bits in the protocol for national use, if required; and
• that the location protocols which can be used for encoding beacon position data, as
well as the beacon identification data, provide for 406 MHz GEOSAR alerts with
beacon location information not otherwise available.

7-2

Having selected the appropriate protocol, administrations should:
• become well informed on the unique capabilities of the various 406 MHz beacon
types and select those for use which best support their national requirements;
• promulgate clear and timely guidance to manufacturers and owners on coding and
registration procedures;
• ensure that reliable means are provided for automatic or fast access to database
information for SAR authorities;
• cooperate with other administrations, manufacturers, owners and organizations to
help resolve any registration or information retrieval problems that may arise;
• disseminate procedures via ICAO, IMO, Cospas-Sarsat, Inmarsat and other service
providers on how beacon registration database information can be obtained by SAR
services, and inform the Cospas-Sarsat Secretariat of the details of their point of
contact for 24 hour access to registered information (telephone, facsimile, telex
numbers);
• encourage manufacturers and distributors to advise customers, upon purchase of
properly coded beacons, about registration requirements, and refer unresolved
coding and registration issues to proper national authorities for resolution; and
• encourage manufacturers and distributors to educate users about the maintenance
of beacons.
In order to ensure that 406 MHz beacons are correctly coded and registered, administrations
should make arrangements for periodic testing and on-board inspection of beacons. Periodic
testing or inspection should include a check of the beacon coding and a verification of
appropriate beacon registration.
7.2
Guidelines to Manufacturers and Distributors
Beacon manufacturers and distributors are an important part of the coding and registration
process. They should ensure that a beacon is properly coded to meet the requirements of the
administration authorising its use. In addition, they should inform the beacon owner of the
requirements of the registering administration as a part of the instruction material provided
with the beacon.
In order to facilitate the examination of beacon coding and registration during periodic beacon
testing or inspections, beacon manufacturers should make provisions to ensure that the beacon
15 Hex ID, together with the hexadecimal presentation of the full length beacon message are
adequately displayed on the exterior of the beacon. For location protocol beacons, the 15 Hex
ID and full length beacon message displayed should correspond to position data set to default
values.
Manufacturers/distributors should cooperate with administrations in all countries where their
products are introduced to implement coding and registration procedures. Coding beacons for
export is a particular concern. Improper coding and registration of beacons limit the
effectiveness of the System.

7-3

On selling a beacon, manufacturers or distributors should:
determine the identity of the administration authorising its use;
provide the user with a beacon that meets the requirements of the authorising
administration;
provide beacon registration guidance to the owner;
inform the owner of his responsibilities regarding registration;
comply with administration registration requirements imposed upon the
manufacturer; and
provide beacon maintenance advice to the user.
Manufacturers/distributors should be aware that the use of some kinds of 406 MHz beacons
are not authorised in a number of countries.
Manufacturers should refer unresolved beacon coding and registration issues to the proper
national authorities for resolution.
– END OF SECTION 7 –

![Image 1 from page 82](/images/cospas-sarsat/G-series/G005/G005_page_82_img_1.png)

![Image 2 from page 82](/images/cospas-sarsat/G-series/G005/G005_page_82_img_2.png)

![Image 3 from page 82](/images/cospas-sarsat/G-series/G005/G005_page_82_img_3.png)

![Image 4 from page 82](/images/cospas-sarsat/G-series/G005/G005_page_82_img_4.png)

![Image 5 from page 82](/images/cospas-sarsat/G-series/G005/G005_page_82_img_5.png)

![Image 6 from page 82](/images/cospas-sarsat/G-series/G005/G005_page_82_img_6.png)

ANNEXES TO THE
COSPAS-SARSAT GUIDELINES
ON 406 MHz BEACON
CODING, REGISTRATION
AND TYPE APPROVAL

A-1

ANNEX A: EXAMPLES OF 406 MHz BEACON CODES
1)  Maritime User Protocol with MMSI
Bit Field Name
Content
Bit Field
Bits
Location
Message Format:
Short Message


Protocol Flag:
User Protocol


Country Code:
257 Norway
27-36

User Protocol Type:
Maritime
37-39

Trailing 6 digits of the
Ship Station Identity
(modified-Baudot code):

40-75


Specific EPIRB:

76-81

Spare:
Not Used
82-83

Radio-locating:
121.5 MHz
84-85

BCH-1:
21-bit BCH Code 86-106

Emergency
Code Flag:
Not Used


Beacon Activation:
Manual Only


Emergency/National Code
or National use data:
Not used
109-112

Beacon 15 Hex ID (bits 26 to 85): A029C 2900D 97591
406 MSG (Short) (bits 25 to 112): 5014E 14806 CBAC8 D2DAA 00
Bits 25 26 27     36 37    40                                75 76  81  83  85
───┼─┼─┼──────────┼─┬─┬─┼────────────────────────────────────┼──────┼─┬─┼─┬─┼─
│0│1│0100000001│0│1│0│011100001010010000000011011001011101│011001│0│0│0│1│
───┴─┴─┴──────────┴─┴─┴─┴────────────────────────────────────┴──────┴─┴─┴─┴─┴─
Bits  86                      112
────┼───────────────────────────┼─
│101001011011010101000000000│
────┴───────────────────────────┴─

A-2

2)  Radio Call Sign User Protocol
(radio call sign includes 2 of maximum 3 last characters (digits))
Message Format:
Short Message
Protocol Flag:
User Protocol
Country Code:
219 Denmark
User Protocol Type:
Radio Call Sign
Radio Call Sign:
XPAO2
Specific EPIRB:

Radio-locating:
121.5 MHz
Emergency/National Use:
Not Used
Beacon Activation:
Automatic or Manual
Beacon 15 Hex ID (bits 26 to 85): 9B7B7 B788C AA9D1
406 MSG (Short) (bits 25 to 112): 4DBDB DBC46 554E8 C8BD7 10
Bits 25 26 27     36 37    40                    63 64        75 76  81  83  85
───┼─┼─┼──────────┼─┬─┬─┼────────────────────────┼────────────┼──────┼─┬─┼─┬─┼─
│0│1│0011011011│1│1│0│110111101101111000100011│001010101010│011101│0│0│0│1│
───┴─┴─┴──────────┴─┴─┴─┴────────────────────────┴────────────┴──────┴─┴─┴─┴─┴─
Bits  86                      112
────┼───────────────────────────┼─
│100100010111101011100010000│
────┴───────────────────────────┴─
3)  ELT Serial Identification
Message Format:
Short Message
Protocol Flag:
User Protocol
Country Code:
503 Australia
User Protocol Type:
Serial
Beacon Type:
Aviation
Serial Number:

National Use Bits:

Radio-locating:
121.5 MHz
Emergency/National Use:
Not Used
Beacon Activation:
Automatic or Manual
Beacon 15 Hex ID (bits 26 to 85): BEEC0 358DC 00001
406 MSG (Short) (bits 25 to 112): 5F760 1AC6E 00000 E4A09 10
Bits 25 26 27     36 37    40      44                63 64      73 74      83  85
───┼─┼─┼──────────┼─┬─┬─┼─┬─┬─┬─┼────────────────────┼──────────┼──────────┼─┬─┼─
│0│1│0111110111│0│1│1│0│0│0│0│00001101011000110111│0000000000│0000000000│0│1│
───┴─┴─┴──────────┴─┴─┴─┴─┴─┴─┴─┴────────────────────┴──────────┴──────────┴─┴─┴─
Bits  86                       112
────┼───────────────────────────┼─
│110010010100000100100010000│
────┴───────────────────────────┴─

A-3

4)  Aircraft Nationality and Registration Marking
(marking includes 5 of maximum 7 alphanumeric characters)
Message Format:
Short Message
Protocol Flag:
User Protocol
Country Code:
316 Canada
User Protocol Type:
Aviation
Aircraft Registration Marking:
C7518
ELT Number:
0 (First ELT)
Radio-locating:
121.5 MHz
Emergency/National Use:
Emergency Code On
Beacon Activation:
Manual Only
Nature of Distress:
No Fire, Medical Help Required, Disabled
Beacon 15 Hex ID (bits 26 to 85): A7864 92E70 174C1
406 MSG (Short) (bits 25 to 112): 53C32 49738 0BA60 FD0F5 26
Bits 25 26 27     36 37    40                                      81  83  85
───┼─┼─┼──────────┼─┬─┬─┼──────────────────────────────────────────┼─┬─┼─┬─┼─
│0│1│0100111100│0│0│1│100100100100101110011100000001011101001100│0│0│0│1│
───┴─┴─┴──────────┴─┴─┴─┴──────────────────────────────────────────┴─┴─┴─┴─┴─
Bits  86                      112
────┼───────────────────────────┼─
│111110100001111010100100110│
────┴───────────────────────────┴─
5)  Personal User Protocol
Message Format:
Short Message
Protocol Flag:
User Protocol
Country Code:
273 Russia
User Protocol Type:
Serial
Beacon Type:
Personal Locator Beacon
Serial Number:

National Use Bits:

Radio-locating:
121.5 MHz
Emergency/National Use:
Not Used
Beacon Activation:
Manual Only
Beacon 15 Hex ID (bits 26 to 85): A22F0 35044 00001
406 MSG (Short) (bits 25 to 112): 51178 1A822 00000 BB4E2 C0
Bits 25 26 27     36 37    40      44                63 64      73 74      83  85
───┼─┼─┼──────────┼─┬─┬─┼─┬─┬─┬─┼────────────────────┼──────────┼──────────┼─┬─┼─
│0│1│0100010001│0│1│1│1│1│0│0│00001101010000010001│0000000000│0000000000│0│1│
───┴─┴─┴──────────┴─┴─┴─┴─┴─┴─┴─┴────────────────────┴──────────┴──────────┴─┴─┴─
Bits  86                      112
────┼───────────────────────────┼─
│011101101001110001011000000│
────┴───────────────────────────┴─
 Effective as of 1 November 2011.

A-4

6)  Test User Protocol
Message Format:
Short Message
Protocol Flag:
User Protocol
Country Code:
725 Chile
User Protocol Type:
Test
Binary Data Field:

Radio-locating:
None
Emergency/National Use:
Not Used
Beacon Activation:
Manual Only
Beacon 15 Hex ID (bits 26 to 85): DABFE 0F83E 0F83C
406 MSG (Short) (bits 25 to 112): 6D5FF 07C1F 07C1E 02121 C0
Bits 25 26 27     36 37    40                                        83  85
───┼─┼─┼──────────┼─┬─┬─┼────────────────────────────────────────────┼─┬─┼─
│0│1│1011010101│1│1│1│11111000001111100000111110000011111000001111│0│0│
───┴─┴─┴──────────┴─┴─┴─┴────────────────────────────────────────────┴─┴─┴─
Bits  86                      112
────┼───────────────────────────┼─
│000001000010010000111000000│
────┴───────────────────────────┴─

A-5

7)  EPIRB Serial Identification User-location Protocol
(Encoded position = 43 32' N, 1 28' E)
Bit Field Name
Content
Bit Field
Bits
Location
Message Format:
Long Message


Protocol Flag:
User Protocol


Country Code:
477 Hong Kong
27-36

User Protocol Type:
Serial
37-39

Beacon type:
Maritime (float
free)
40-42

C-S Type approval
Certificate Indicator:
Type Approved


Serial Number:

44-63

National use:
Not used
64-73

C/S Certificate No:

74-83

Radio-locating:
121.5 MHz
84-85

BCH-1:
21-bit BCH Code 86-106

Position Data Source:
Internal


Latitude Flag:
N


Latitude in Degrees:

109-115

Latitude in Minutes:

116-119

Longitude Flag:
E


Longitude in Degrees:

121-128

Longitude in Minutes:

129-132

BCH-2:
12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): BBAD5 EE4A4 00191
406 MSG (Long) (bits 25 to 144): DDD6A F7252 000C8 C236C A5700 17151
Bits 25 26 27     36 37    40      44                63 64      73 74      83  85
───┼─┼─┼──────────┼─┬─┬─┼─┬─┬─┬─┼────────────────────┼──────────┼──────────┼─┬─┼─
│1│1│0111011101│0│1│1│0│1│0│1│01111011100100101001│0000000000│0001100100│0│1│
───┴─┴─┴──────────┴─┴─┴─┴─┴─┴─┴─┴────────────────────┴──────────┴──────────┴─┴─┴─
Bits  86                106    109      119   121      132 133      144
────┼─────────────────────┼─┼─┼───────────┼─┼────────────┼────────────┼
│100001000110110110010│1│0│01010111000│0│000000010111│000101010001│
────┴─────────────────────┴─┴─┴───────────┴─┴────────────┴────────────┴

A-6

8)  Standard Location Protocol with MMSI
(Encoded position = 43 43' 56" N, 0 58'52"E)\*
Bit Field Name
Content
Bit Field
Bits
Location
Message Format:
Long Message


Protocol Flag:
Location Prot.


Country Code:
257 Norway
27-36

Standard Protocol Type:
EPIRB-MMSI
37-40

Trailing 6 digits of the
Ship Station Identity
(in binary form): 506153
41-60

Specific EPIRB
(in binary form): 2
61- 64

Latitude Flag:
N


Latitude in degrees:

66-72

Latitude in ¼ degree
increment:
¾
73-74

Longitude Flag:
E


Longitude in degrees:

76-83

Longitude in ¼ degree
increment:
¼
84-85

BCH-1:
21-bit BCH Code
86-106

Fixed bits:
107-110

Position data provided by:
external
navig. device


121.5 auxiliary radio
location device:
yes


Latitude offset sign:


Latitude offset in min.:

114-118

Latitude offset in sec.:

119-122

Longitude offset sign:


Longitude offset in min.:

124-128

Longitude offset in sec.:

129-132

BCH-2:
12-bit BCH Code
133-144

Beacon 15 Hex ID (bits 26 to 85): 2024F 72524 FFBFF†
406 MSG (Long) (bits 25 to 144): 90127 B9292 2BC02 B4968 F5045 0220B
Bits 25 26 27     36 37      41                60   64   66      74  76      85
───┼─┼─┼──────────┼─┬─┬─┬─┼────────────────────┼────┼─┼─────────┼─┼──────────┼─
│1│0│0100000001│0│0│1│0│01111011100100101001│0010│0│010101111│0│0000000101│
───┴─┴─┴──────────┴─┴─┴─┴─┴────────────────────┴────┴─┴─────────┴─┴──────────┴─
Bits  86                106    109      114  119    123   132  133      144
────┼─────────────────────┼─┼─┼─┼───┼─┼─────┼────┼─┼─────┼────┼────────────┼
│011010010010110100011│1│1│0│101│0│00001│0001│0│10000│0010│001000001011│
────┴─────────────────────┴─┴─┴─┴───┴─┴─────┴────┴─┴─────┴────┴────────────┴
* This example uses the location protocol coding system defined in section A3.3.1 of document C/S T.001, Issue 3 - Revision 8 where the location
encoded in PDF-1 may not be the closest to the actual location.  This method of encoding will not be permitted after 1 November 2010, see Example
10 for an example of the current encoding method.
† With default values for position data.

A-7

9) National Location Protocol
(Encoded position = 43 31' 56'' N, 1 25'52''E)\*
Bit Field Name
Content
Bit Field
Bits `
Location
Message Format:
Long Message


Protocol Flag:
Location Prot. 26

Country Code:
257 Norway
27-36

National Protocol Type:
EPIRB Serial
37-40

Serial Number:

41-58

Latitude Flag:
N


Latitude in Degrees:

60-66

Latitude in Minutes:

67-71

Longitude Flag:
E


Longitude in Degrees:

73-80

Longitude in Minutes:

81-85

BCH-1:
21-bit BCH Code 86-106

Fixed bits:
107-109

additional data flag:
position data
as defined by
Cospas-Sarsat


Position data provided by: external
navig. device


121.5 auxiliary radio
location device:
no


Latitude offset sign:


Latitude offset in min.:

114-115

Latitude offset in sec.:

116-119

Longitude offset sign:


Longitude offset in min.: 2
121-122

Longitude offset in sec.: 8
123-126

Additional Beacon type
identification:

127-132

BCH-2:
12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): 20341 500BF 81FE0
406 MSG (Long) (bits 25 to 144): 901A0 A804A E0017 69AC9 B4028 AA140
Bits 25 26 27     36 37      41              58  60    66 67  71 73     80 81   85
───┼─┼─┼──────────┼─┬─┬─┬─┼──────────────────┼─┼───────┼─────┼─┼────────│─────┼─
│1│0│0100000001│1│0│1│0│000010101000000001│0│0101011│10000│0│00000001│01110│
───┴─┴─┴──────────┴─┴─┴─┴─┴──────────────────┴─┴───────┴─────┴─┴────────┴─────┴─
Bits  86                106    109         116       123   127   133        144
────┼─────────────────────┼─┼─┼─┼─┼──┼─┼──┼────┼─┼──┼────┼──────┼────────────┼
│110100110101100100110│1│1│0│1│00│0│00│0001│0│10│0010│101010│000101000000│
────┴─────────────────────┴─┴─┴─┴─┴──┴─┴──┴────┴─┴──┴────┴──────┴────────────┴
10) Standard Location Protocol with MMSI
(Actual Location = 43 43' 56" N, 0 11’10” E)
(Encoded position = 43 43' 56" N, 0 11’12” E)
* This example uses the location protocol coding system defined in section A3.3.1 of document C/S T.001, Issue 3 -
Revision 8 where the location encoded in PDF-1 may not be the closest to the actual location.  This method of encoding
will not be permitted after 1 November 2010, see Example 11 for an example of the current encoding method.
 With default values for position data.

A-8

Bit Field Name
Content
Bit Field
Bits
Location
Message Format:
Long Message


Protocol Flag:
Location Prot. 26

Country Code:
257 Norway
27-36

Standard Protocol Type:
EPIRB-MMSI
37-40

Trailing 6 digits of the
Ship Station Identity
(in binary form):

41-60

Specific EPIRB
(in binary form):

61-64

Latitude Flag:
N


Latitude in degrees:

66-72

Latitude in ¼ degree
increment:
¾
73-74

Longitude Flag:
E


Longitude in degrees:

76-83

Longitude in ¼ degree
increment:
¼
84-85

BCH-1:
21-bit BCH Code 86-106

Fixed bits:
107-110

Position data provided by: external
navig. device


121.5 auxiliary radio
location device:
yes


Latitude offset sign:


Latitude offset in min.:

114-118

Latitude offset in sec.:

119-122

Longitude offset sign:


Longitude offset in min.: 3
124-128

Longitude offset in sec.: 48
129-132

BCH-2:
12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): 2024F 724E4 FFBFF\*
406 MSG (Long) (bits 25 to 144): 90127 B9272 2BC00 FF7B3 B5044 3CA54
Bits 25 26 27     36 37     41                 60   64  66      74  76       85
───┼─┼─┼──────────┼─┬─┬─┬─┼────────────────────┼────┼─┼─────────┼─┼──────────┼─
│1│0│0100000001│0│0│1│0│01111011100100100111│0010│0│010101111│0│0000000001│
───┴─┴─┴──────────┴─┴─┴─┴─┴────────────────────┴────┴─┴─────────┴─┴──────────┴─
Bits  86                 106   109      114  119    124   129   133      144
────┼─────────────────────┼─┼─┼─┼───┼─┼─────┼────┼─┼─────┼────┼────────────┼
│111111101111011001110│1│1│0│101│0│00001│0001│0│00011│0010│101001010100│
────┴─────────────────────┴─┴─┴─┴───┴─┴─────┴────┴─┴─────┴────┴────────────┴
11) National Location Protocol
(Actual Location = 43 42' 58'' N, 0 0' 58'' E)
(Encoded position = 43 43' 0'' N, 0 1' 0'' E)
Bit Field Name
Content
Bit Field
Bits
Location
* With default values for position data

A-9

Message Format:
Long Message


Protocol Flag:
Location Prot. 26

Country Code:
257 Norway
27-36

National Protocol Type:
EPIRB Serial
37-40

Serial Number:

41-58

Latitude Flag:
N


Latitude in Degrees:

60-66

Latitude in Minutes:

67-71

Longitude Flag:
E


Longitude in Degrees:

73-80

Longitude in Minutes:

81-85

BCH-1:
21-bit BCH Code 86-106

Fixed bits:
107-109

additional data flag:
position data
as defined by
Cospas-Sarsat


Position data provided by: external
navig. device


121.5 auxiliary radio
location device:
no


Latitude offset sign:
+


Latitude offset in min.:

114-115

Latitude offset in sec.:

116-119

Longitude offset sign:
+


Longitude offset in min.: 1
121-122

Longitude offset in sec.: 0
123-126

Additional Beacon type
identification:

127-132

BCH-2:
12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): 20341 500BF 81FE0\*
406 MSG (Long) (bits 25 to 144): 901A0 A804A EA000 2F3B3 F4A14 2A843
Bits 25 26 27     36 37      41              58  60    66 67  71 73     80 81  85
───┼─┼─┼──────────┼─┬─┬─┬─┼──────────────────┼─┼───────┼─────┼─┼────────│─────┼─
│1│0│0100000001│1│0│1│0│000010101000000001│0│0101011│10000│0│00000000│00000│
───┴─┴─┴──────────┴─┴─┴─┴─┴──────────────────┴─┴───────┴─────┴─┴────────┴─────┴─
Bits  86                106    109         116       123   127   133        144
────┼─────────────────────┼─┼─┼─┼─┼──┼─┼──┼────┼─┼──┼────┼──────┼────────────┼
│010111100111011001111│1│1│0│1│00│1│01│0000│1│01│0000│101010│100001000011│
───┴─────────────────────┴─┴─┴─┴─┴──┴─┴──┴────┴─┴──┴────┴──────┴────────────┴
- END OF ANNEX A –
* With default values for position data.

B-1

ANNEX B: MODIFIED-BAUDOT CODE
Table B.1: Modified-Baudot Code
Letter
Code
MSB
LSB
Letter
Code
MSB
LSB
Figure
Code
MSB
LSB
A
B
C
D
E
F
G
H
I
J
K
L
M


N
O
P
Q
R
S
T
U
V
W
X
Y
Z


(   )\*
( - )**
/


MSB: most significant bit
*  Space
LSB: least significant bit
** Hyphen
Note: The modified-Baudot code is used to encode alphanumeric characters in beacon messages.
- END OF ANNEX B -

C-1

ANNEX C: BINARY CODED DECIMAL
To encode a decimal number in the Binary Coded Decimal (BCD) format, each digit of the decimal
number is encoded using a four bit binary pattern as illustrated below:
For Example 127 is represented as:
1        2        7
0001  0010  0111
The following table represents the decimal numbers from 0 to 9 and the “space character” in BCD
format authorized for use in the Radio Call Sign User protocol.
Decimal Number
BCD


“space character”

- END OF ANNEX C -

D-1

ANNEX D: GUIDELINES ON THE USE OF THE BEACON REGISTRATION
CHECKSUM
National Administrations wishing to implement a beacon registration checksum should note the
following guidance.
• Beacon manufacturers should calculate the 5 character checksum based on the 15 or 23
hexadecimal Unique Identification Number (UIN) for serialized beacons.
• The beacon manufacturer should include the 5 character checksum on the registration
documentation that it provides to the first buyer of the beacon. Note that some national
administration registration documents may not contain space for the checksum. The
beacon manufacturer should not provide a checksum when the beacon manufacturer
cannot determine the beacon ID in their factory (e.g., for EPIRBs containing a Maritime
User Protocol – MMSI, or ELTs containing an Aircraft 24-bit address), as the beacon
coding details are not known until the beacon is about to be installed on a specific aircraft
or vessel.
• The 5 character checksum should not be placed on the beacon itself only on the
registration form provided with the beacon.
• The Five Character Checksum should be implemented using the algorithm provided in
Appendix 1.
• Administrations that implement the checksum should ensure that the checksum is
calculated correctly. Administrations may decide that checksums should only be
generated by beacon manufacturers. If an Administration decides that the checksum
should be implemented by distributors and service agents it should note that this may be
difficult to achieve and regulate.
• Administrations should not require the checksum to be computed for beacons already on
the market.

D-2

Appendix 1 to Annex D - Implementation of Five Character Checksum for UIN
The algorithm defined below produces a running sum using the ASCII decimal values for each
character modified by arithmetic operations involving primary numbers. Intermediate results are
directly truncated to avoid integer variable overflows, restricting all values within the positive range
of values associated with standard 4 byte integers (0 to 2,147,483,647). The final result is also
truncated to an integer of 20 bits or less, which yields the desired five hexadecimal characters. In the
pseudo-code listing below the symbols (\*, /, -, +) represent standard arithmetic operators of
multiplication, division, subtraction and addition respectively, and inline comments follow the
designator of //.
// Initializations:
ReturnLimit
= 1048576
// used to limit the return value to a 20 bit result
RunningSumLimit = 538471
// large prime which will not cause an overflow
ConstPrimVal
= 3911
// small prime value, stays constant throughout
ModifierLimit
= 3847
// small prime which will not cause an overflow
Modifier
= 3803
// modifier, simply initialized to a prime value
RunningSum
= 0
// holds the running value of the checksum
// Main Computation:
Loop for first (BcnIdLength – 1)  hexadecimal characters in UIN, 1 to (BcnIdLength – 1):
// incorporate a character into running checksum
DecimalValue = ASCII decimal value of this character (See Table 1)
TmpLongValue = (RunningSum * Modifier) + DecimalValue;
TmpLongValue2 = TmpLongValue / RunningSumLimit;  // whole number quotient
RunningSum = TmpLongValue - (TmpLongValue2 * RunningSumLimit); // remainder
// Compute next Modifier
TmpLongValue = ConstPrimVal * Modifier;
TmpLongValue2 = TmpLongValue / ModifierLimit;
// whole number quotient
Modifier = TmpLongValue - (TmpLongValue2 * ModifierLimit);
// remainder
End Loop
// Process Final Character:
DecimalValue = ASCII decimal value of this character (See Table 1)
TmpLongValue = (RunningSum * Modifier) + DecimalValue;
// Truncation to 20 Bits for final checksum value:
TmpLongValue2 = TmpLongValue / ReturnLimit;
// whole number quotient
CheckSumValue = TmpLongValue - (TmpLongValue2 * ReturnLimit);
// remainder
The CheckSumValue, now 20 bits in length, is then translated to a 5 character hexadecimal
representation by converting 4 bit blocks as per standard mechanisms (see Table D.2).

D-3

Table D.1: Translation of characters to ASCII Decimal Values
Char
Dec
Char
Dec
Char
Dec
Char
Dec


C


D


A

E


B

F

Table D.2: Standard Translation of 4 Bits Blocks to Hexadecimal Characters
Bits
Char
Bits
Char
Bits
Char
Bits
Char


C


D


A

E


B

F
Table D.3: Example UIN Inputs and Resulting Checksums
# UIN
Checksum
1 2DCC3FB834FFBFF
885BC
2 2DCC3FB858FFBFF
AE919
3 ADCE089F7C4106D
D31F8
4 ADCE08AA044006D
B3066
5 ADCE08ABE84106D
56B73
6 ADCE08BC004086D
97A1D
7 ADCE08BC744006D

8 2DCC44328EFFBFF
93F7C
9 ADCE08958C4046D
3B7A0
10 ADCE0895A04046D
58C78
11 2DC8555076FFBFF
A8163
12 ADCE08969C4046D
0D618
13 ADCE089A1C4006D
EA65B
14 ADCE08B69C4106D
33ADA
15 ADCE08BB484106D
71DCF
16 2DCE4E1FE0FFBFF
9ADD3
17 2DCE4E17B8FFBFF
2DBC4
18 ADCC07FC0440401
F95BB
19 ADCC07FCB440401
F093A
20 ADCC07FCB840401
B539B
21 ADCE0884984046D
BA05E
22 2DCC3FC806FFBFF
AA605
23 2DCC445744FFBFF
3DA69
24 ADCD02355542801
2D88A
25 ADCD02354542801
7CC0C
26 ADF7DA6D7090000000F9129 2C019
27 9EF7DA6D709000000000000 BC494
28 ADF7DA6D7092E33BA475940 E1A38
29 A037DA6D7092937D7175940 25A20
30 B5F46E783F23924E9D65028 5052C
31 9977DA6D709000000000000 A3BEC

D-4

# UIN
Checksum
32 ADF587AA62B157AE36DC552 6E036
33 A2F669AB2D930E18709B40C 47E37
34 ADF68E50F4B47C5D5700000 6AAD4
35 99B49C6B4E9444914B00000 620B8
36 A794B4C00872E33B9D64A04 1A5E4
37 CF559BC97704D7B87B00000 428B0
38 9E15CA4E9DA396A62CB83D0 CC69C
39 AF54F301DC75A77F98D3FFF 73526
40 A2D7691BC1714264B696523 C1D43
41 9D149C6C22B38E39A5C5774 09F64
42 CCB7EA73355000000000000 C79D4
43 9A7400030395CB3D62BBFFF F9B02
44 9A749FFF0395CB3D62BBFFF 54092
45 A794CEE960B2C2C54DA6AB8 5351C
46 9C55E7DC0172F33D7E75974 CE074
47 9A14A18EEE82CA363DE6DE4 A66B4
48 CF54D901AF93FA6EAD72B90 4B93C
49 CE1631B32394C147FA00000 34D44
50 BB34CB138F5000000000000 53BA8
- END OF ANNEX D -
- END OF DOCUMENT –

Cospas-Sarsat Secretariat
1250 René-Lévesque Blvd. West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada
Telephone: +1 514 500 7777
Fax: +1 514 500 7996
Email: mail@cospas-sarsat.int
Website: http://www.cospas-sarsat.int