Ryan Malloy 4ed92efd69 refactor: move spec references out of published site

Cospas-Sarsat specification summaries moved to reference/ for internal
use only. Links updated to point to official cospas-sarsat.int site.

The extracted images remain in public/ for use in other pages.

2026-02-13 05:03:09 -07:00

196 KiB

Raw Blame History

title

description

sidebar

documentId

series

seriesName

documentType

isLatest

issue

revision

documentDate

originalTitle

T001: C/S T.001 - Issue 4 - Rev. 13

Official Cospas-Sarsat T-series document T001

badge

text	variant
T	note

T001

Technical

specification

true

October 2025

C/S T.001 - Issue 4 - Rev. 13

📋 Document Information

Series: T-Series (Technical) Version: Issue 4 - Revision 13 Date: October 2025 Source: Cospas-Sarsat Official Documents

SPECIFICATION FOR COSPAS-SARSAT 406 MHz DISTRESS BEACONS C/S T.001 Issue 4 – Revision 13

SPECIFICATION FOR COSPAS-SARSAT 406 MHz DISTRESS BEACONS History Issue Revision Date Comments

Approved by the Cospas-Sarsat Steering Committee (CSSC-15)

Approved by the Cospas-Sarsat Council

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

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

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

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

Editorial changes, approved by the Cospas-Sarsat Council (CSC-25) as Corrigendum to C/S T.001 Issue 3 - Rev.3

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

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

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

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

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

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-47)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TABLE OF CONTENTS Page History ........................................................................................................................................ i Table of Contents ................................................................................................................................. ii List of Figures ................................................................................................................................. v List of Tables ................................................................................................................................. v 1. Introduction ............................................................................................................. 1-1 1.1 Purpose ....................................................................................................................... 1-1 1.2 Scope .......................................................................................................................... 1-1 2. System Requirements ............................................................................................. 2-1 2.1 Beacon Functional Elements ...................................................................................... 2-1 2.2 Digital Message Generator ......................................................................................... 2-1 Repetition Period ...........................................................................................2-1 Total Transmission Time ...............................................................................2-2 Unmodulated Carrier .....................................................................................2-2 Digital Message .............................................................................................2-4 2.2.4.1 Bit Synchronization ....................................................................................................2-4 2.2.4.2 Frame Synchronization ...............................................................................................2-4 2.2.4.3 Format Flag ................................................................................................................2-4 2.2.4.4 Message Content ........................................................................................................2-4 2.3 Modulator and 406 MHz Transmitter ........................................................................ 2-5 Transmitted Frequency ..................................................................................2-5 Transmitter Power Output .............................................................................2-6 Antenna Characteristics .................................................................................2-7 Spurious Emissions ........................................................................................2-7 Data Encoding................................................................................................2-8 Modulation .....................................................................................................2-8 Voltage Standing-Wave Ratio .......................................................................2-8 Maximum Continuous Transmission .............................................................2-8 3. DIGITAL MESSAGE CONTENT ........................................................................ 3-1 3.2 Basic Structure ............................................................................................................ 3-1 3.3 Beacon Coding ........................................................................................................... 3-2 3.4 Cancellation Message (ELT(DT) only) ...................................................................... 3-2 4. ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS .................... 4-1 4.1 General ....................................................................................................................... 4-1 4.2 Thermal Environment................................................................................................. 4-1 Operating Temperature Range .......................................................................4-1 Temperature Gradient ....................................................................................4-1 Thermal Shock ...............................................................................................4-1 4.3 Mechanical Environment ........................................................................................... 4-2 4.4 Other Environmental Requirements ........................................................................... 4-3 4.5 Operational Requirements .......................................................................................... 4-3

Duration of Continuous Operation ................................................................4-3 Other Operational Requirements ...................................................................4-3 Auxiliary Radio-Locating Device ..................................................................4-3 Beacon Self-Test Mode .................................................................................4-4 Encoded Position Data ...................................................................................4-7 4.5.5.1 General .......................................................................................................................4-7 4.5.5.2 Message Content and Timing .....................................................................................4-7 4.5.5.3 Internal Navigation Device Performance ...................................................................4-8 4.5.5.4 Internal Navigation Device Timing ............................................................................4-9 4.5.5.5 External Navigation Device Input ............................................................................4-10 4.5.5.6 ELT(DT) Navigation Device Requirements .............................................................4-10 Beacon Activation........................................................................................4-12 4.5.6.1 ELT(DT) Modes of Operation ..................................................................................4-13 RLS Beacon Requirements ..........................................................................4-14 4.5.7.1 GNSS Receiver ........................................................................................................4-15 4.5.7.2 RLS GNSS Receiver Operation ...............................................................................4-15 4.5.7.2.1 Operation Cycle ........................................................................................................4-15 4.5.7.2.2 Derivation of Moffset ...............................................................................................4-17 4.5.7.3 Indications of RLS and RLM ...................................................................................4-17 4.5.7.4 Confirmation of a Return-Link Message Receipt .....................................................4-18 4.5.7.5 RLS Beacon Documentation ....................................................................................4-18 Beacon Labelling and Marking ....................................................................4-18 Operator Controlled Voice Transceivers .....................................................4-19 ELT(DT)s Specifically Designed to Withstand a Crash Impact ..................4-20 4.5.10.1 Introduction ..............................................................................................................4-20 4.5.10.2 Beacon Hex ID .........................................................................................................4-20 4.5.10.3 Burst Repetition Period (with Crash Detection) .......................................................4-20 4.5.10.4 GNSS Update Rate (after Crash Detection) .............................................................4-21 4.5.10.5 Duration of Continuous Operation ...........................................................................4-21 4.5.10.6 Homing and Locating Signals ..................................................................................4-22 ELT(DT)s Combined with Automatic ELTs ...............................................4-22 4.5.11.1 Introduction ..............................................................................................................4-22 4.5.11.2 Beacon Coding and Beacon Hex ID .........................................................................4-22 4.5.11.3 Burst Repetition Period ............................................................................................4-23 4.5.11.4 System Requirements ...............................................................................................4-23 4.5.11.5 Cancellation Message ...............................................................................................4-24 4.5.11.6 Encoded Position Data and Navigation Device Performance ..................................4-24 4.5.11.7 Duration of Continuous Operation ...........................................................................4-24 4.5.11.8 Class of Operation ....................................................................................................4-24 4.5.11.9 Homing and Locating Signals ..................................................................................4-24 External Power Source for ELT(DT)s .........................................................4-25 ANNEX A BEACON CODING ............................................................................................... A-1 A1 GENERAL ................................................................................................................ A-1 A1.1 Summary ....................................................................................................... A-1 A1.2 Message Format Flag, Protocol Flag, and Country Code ............................. A-2 A1.2.1 Format Flag ............................................................................................................... A-2 A1.2.2 Protocol Flag ............................................................................................................. A-2 A1.2.3 Country Code ............................................................................................................ A-2 A1.3 Protocol Codes .............................................................................................. A-3

A2 USER PROTOCOLS ................................................................................................ A-5 A2.1 Structure of User Protocols ........................................................................... A-5 A2.2 Maritime User Protocol ................................................................................ A-7 A2.3 Radio Call Sign User Protocol ...................................................................... A-8 A2.4 Aviation User Protocol ................................................................................. A-9 A2.5 Serial User Protocol ...................................................................................... A-9 A2.5.1 Serial Number ......................................................................................................... A-10 A2.5.2 Aircraft 24-bit Address ............................................................................................ A-11 A2.5.3 Aircraft Operator Designator and Serial Number .................................................... A-11 A2.6 Test User Protocol ...................................................................................... A-12 A2.7 Orbitography Protocol ................................................................................ A-12 A2.8 National User Protocol................................................................................ A-12 A2.9 Non-Protected Data Field ........................................................................... A-13 A2.9.1 Maritime Emergency code ...................................................................................... A-14 A2.9.2 Non-Maritime Emergency code .............................................................................. A-14 A2.9.3 National Use ............................................................................................................ A-15 A3 LOCATION PROTOCOLS .................................................................................... A-17 A3.1 Summary ..................................................................................................... A-17 A3.2 Default Values in Position Data .................................................................. A-18 A3.3 Definition of Location Protocols ................................................................ A-19 A3.3.1 Position Data ........................................................................................................... A-19 A3.3.2 Supplementary Data ................................................................................................ A-19 A3.3.3 Test Location Protocols ........................................................................................... A-21 A3.3.4 User-Location Protocols (See Figure A7) ............................................................... A-23 A3.3.5 Standard Location Protocols (see Figure A8) .......................................................... A-25 A3.3.6 National Location Protocol (see Figure A9) ............................................................ A-28 A3.3.7 RLS Location Protocol (see Figure A10) ................................................................ A-31 A3.3.8 ELT(DT) Location Protocol (see Figure A11) ........................................................ A-36 ANNEX B BCH AND CRC CalculationS ............................................................................... B-1 B1 Sample 21-Bit BCH Code Calculation ...................................................................... B-1 B2 Sample 12-Bit BCH Code Calculation ...................................................................... B-4 ANNEX C EXAMPLES OF RLS GNSS RECEIVER TIMING .......................................... C-1 ANNEX D RLS Information .................................................................................................... D-1

LIST OF FIGURES Figure 2.1: Burst Transmission Scheme for ELT(DT)s transmitting the 3LD aircraft operator designator in PDF-2....................................................................................................2-1 Figure 2.2: Short Message Format ......................................................................................................2-4 Figure 2.3: Long Message Format ......................................................................................................2-5 Figure 2.4: Spurious Emission Mask for 406.0 to 406.1 MHz Band ..................................................2-7 Figure 2.5: Data Encoding and Modulation Sense ...............................................................................2-8 Figure 2.6: Definition of Modulation Rise and Fall Times ..................................................................2-9 Figure 2.7: Definition of Modulation Symmetry .................................................................................2-9 Figure 4.1: Temperature Gradient .......................................................................................................4-2 Figure A1: Data Fields of the Short Message Format ....................................................................... A-3 Figure A2: Data Fields of the Long Message Format ........................................................................ A-3 Figure A3: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols ............... A-6 Figure A4: Summary of User Protocols Coding Options ................................................................ A-16 Figure A5: Outline of Location Protocols........................................................................................ A-18 Figure A6: General Format of Long Message for Location Protocols ............................................ A-22 Figure A7: User-Location Protocol.................................................................................................. A-24 Figure A8: Standard Location Protocols .......................................................................................... A-27 Figure A9: National Location Protocol ............................................................................................ A-30 Figure A10: RLS Location Protocol ................................................................................................ A-35 Figure A11: ELT(DT) Location Protocol ........................................................................................ A-40 Figure B1: Sample 21-Bit BCH Error-Correcting Code Calculation ............................................... B-3 Figure B2: Sample 12-Bit BCH Error-Correcting Code Calculation ............................................... B-5 LIST OF TABLES Table A1: Format Flag and Protocol Flag Combinations .................................................................... A-3 Table A2: Protocol Codes Assignments ............................................................................................ A-4 Table A3: Modified-Baudot Code ..................................................................................................... A-7 Table A4: Maritime Emergency Codes in Accordance with the Modified (1) IMO Nature of Distress Indication ................................................................................................... A-15 Table A5: Non-Maritime Emergency Codes ................................................................................... A-15

1-1

INTRODUCTION 1.1 Purpose The purpose of this document is to define the minimum requirements to be used for the development and manufacture of 406 MHz Emergency Locator Transmitters (ELTs), Emergency Position-Indicating Radio Beacons (EPIRBs), and Personal Locator Beacons (PLBs). In this document, the term ELT indicates an aviation distress beacon, an EPIRB a maritime distress beacon, and a PLB a distress beacon for personal use. Specifications that are critical to the Cospas-Sarsat System are defined in detail; specifications which could be developed by the national authorities are identified in more general terms. Where there are specific requirements in this document for a distress tracking ELT (ELT(DT)) these refer to a specific type of ELT designed to be activated prior to a crash and to function in compliance with the ICAO GADSS* requirements for the location of an aeroplane in distress, aimed at establishing, to a reasonable extent, the location of an accident site within a 6 NM radius. An ELT(DT) may be activated automatically upon detection of a distress condition while in flight or it may also be activated manually. 1.2 Scope This document contains the minimum requirements that apply to Cospas-Sarsat 406 MHz distress beacons. It is divided into the following sections: Section 2 gives the system requirements applicable to all types of beacons. When met, these requirements will enable the beacons to provide the intended service in terms of location probability and accuracy and will not disturb the system operation. Section 3 deals with the beacon message content. Basic message structure is defined. Assignment and meaning of the available data bits are defined in Annex A to this specification. Section 4 defines a set of environmental and operational requirements. These requirements are not intended to be exhaustive and may be complemented by more detailed national or international standards (e.g., RTCA standards for ELTs). However, they represent the minimum environmental and operational performance requirements for a 406 MHz beacon to be compatible with the Cospas-Sarsat System.

See ICAO Convention on International Civil Aviation Annex 6, Part 1.

1-2

Annex A defines the beacon coding. Annex B provides samples of error correcting code calculations, Moffset calculations and CRC code sample. A full list of acronyms used in this document can be found in document C/S S.011, “Cospas-Sarsat Glossary”.

END OF SECTION 1 -

2-1

SYSTEM REQUIREMENTS 2.1 Beacon Functional Elements This section defines the requirements for the two following functional elements of a 406 MHz distress beacon: digital message generator; and modulator and 406 MHz transmitter. 2.2 Digital Message Generator The digital message generator will key the modulator and transmitter so that the message defined in section 3 is transmitted. Repetition Period The repetition period shall not be so stable that any two transmitters appear to be synchronized closer than a few seconds over a 5-minute period. The intent is that no two beacons will have all of their bursts coincident. The repetition period (TR) shall be randomised around a mean value of 50 seconds, so that time intervals between the beginnings of two successive bursts are randomly distributed on the interval from 47.5 to 52.5 seconds. The average repetition period shall be 50 seconds ± 1.5 seconds. For ELT(DT)s (except those transmitting the 3LD* aircraft operator designator in PDF-2) the value of the repetition period shall be as follows: From beacon activation, transmit a total of 24 bursts, the time interval between the beginning of two successive bursts shall be 5 seconds +0.0 / - 0.2 seconds. The first burst timing shall meet the requirements of 4.5.6; Then transmit a further 18 bursts commencing 10 seconds + 0.0 / - 0.2 after the burst 24, at time intervals between the beginning of two successive bursts of 10 seconds +0.0 / - 0.2 seconds; and The next burst (burst number 43) shall then start between 27.0 and 30.0 seconds after the beginning of burst 42. Subsequent bursts shall be randomized with uniform (flat) distribution around a mean value of 28.5 seconds so that the time

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.

2-2

intervals between the beginnings of two successive bursts (TR) are randomly distributed on the interval 27.0 to 30.0 seconds. The standard deviation over 18 successive bursts of TR shall be greater than 0.8 seconds. The minimum value of TR observed over the 18 successive bursts shall be between 27.0 and 27.2 seconds, the maximum value of TR observed over the 18 successive bursts shall be between 29.8 and 30.0 seconds. For ELT(DT)s transmitting the 3LD aircraft operator designator in PDF-2, the transmission scheme is as follows. An illustrative version of this is provided in Figure 2.1. From beacon activation, transmit a total of 24 bursts, the time interval between the beginning of two successive bursts shall be 5 seconds +0.0 / - 0.2 seconds and every 4th burst starting with burst 2 shall transmit the 3LD. The first burst timing shall meet the requirements of 4.5.6. Then transmit a further 18 bursts commencing 10 seconds + 0.0 / - 0.2 after the 24th burst, at time intervals between the beginning of two successive bursts of 10 seconds + 0.0 / - 0.2 seconds. In addition, transmit an additional burst, containing the 3LD, 5 seconds +/- 0.5 seconds after the beginning of the first of these 18 bursts and then after every 6th burst (i.e. 3 additional bursts with the 3LD, interleaved between the 18 bursts, making a total of 21 bursts). The next burst shall then start between 27.0 and 30.0 seconds after the beginning of the last (45th) burst and subsequent bursts shall be randomized with uniform (flat) distribution around a mean value of 28.5 seconds so that the time intervals between the beginnings of two successive bursts (TR) are randomly distributed on the interval 27.0 to 30.0 seconds. In addition, an additional burst containing the 3LD shall be transmitted after the 16th of these bursts and then after every 30th burst thereafter at 15 seconds +/- 0.5 seconds after the beginning of the previous burst. The standard deviation over 18 successive bursts of TR (excluding bursts containing the 3LD) shall be greater than 0.8 seconds. The minimum value of TR observed over the 18 successive bursts shall be between 27.0 and 27.2 seconds, and the maximum value of TR observed over the 18 successive bursts shall be between 29.8 and 30.0 seconds (ignoring bursts containing the 3LD). Total Transmission Time The total transmission time, measured at the 90 percent power points, shall be 440 ms ±1 percent for the short message and 520 ms ±1 percent for the long message. Unmodulated Carrier The initial 160 ms ±1 percent of the transmitted signal shall consist of an unmodulated carrier at the transmitter frequency measured between the 90 percent power point and the beginning of the modulation.

2-3

Note - The times in seconds under the axis of each set of bursts are for reference only and do not necessarily indicate where bursts will occur as timing tolerances will vary this. Figure 2.1: Burst Transmission Scheme for ELT(DT)s transmitting the 3LD aircraft operator designator in PDF-2

2-4

Digital Message a) Short Message The final 280 ms ±1 percent of the transmitted signal shall contain a 112-bit message at a bit rate of 400 bps ±1 percent; b) Long Message The final 360 ms ±1 percent of the transmitted signal shall contain a 144-bit message at a bit rate of 400 bps ±1 percent. For ELT(DT)s, and RLS location protocol beacons, the final 360 ms ±1 percent of the transmitted signal shall contain a 144-bit message at a bit rate of 400 bps ±0.1 percent. c) Cancellation Message (ELT(DT) only) ELT(DT)s shall also have means of deactivation by the same means of activation which shall be followed by a cancellation message sequence, as defined in section 3.4. 2.2.4.1 Bit Synchronization A bit-synchronization pattern consisting of "1"s shall occupy the first 15-bit positions. 2.2.4.2 Frame Synchronization A frame synchronization pattern consisting of 9 bits shall occupy bit positions 16 through 24. The frame synchronization pattern in normal operation shall be 000101111. However, if the beacon radiates a modulated signal in the self-test mode, the frame synchronization pattern shall be 011010000 (i.e. the last 8 bits are complemented). 2.2.4.3 Format Flag Bit 25 is a format (F) flag bit used to indicate the length of the message to follow. Value "0" indicates a short message; value "1" indicates a long message. 2.2.4.4 Message Content The content of the remaining 87 bits (short message - see Figure 2.2) or 119 bits (long message - see Figure 2.3) is defined in section 3. Figure 2.2: Short Message Format 87 BITS (SEE SECTION 3) 160 ms CARRIER

BITS

BITS (2) (1) NOTE: (3)

2-5

Figure 2.3: Long Message Format Notes: (1) Bit Synchronization : 15 "1" bits (2) Frame Synchronization : 000101111 (except as in section 4.5.4) (3) "0" bit indicates short-message format "1" bit indicates long-message format 2.3 Modulator and 406 MHz Transmitter Transmitted Frequency* To ensure adequate System capacity and an efficient use of the available frequency spectrum in the band 406.0 - 406.1 MHz allocated by the ITU for the operation of low-power satellite emergency position-indicating radiobeacons, a number of channels have been defined in the allocated band and will be assigned by Cospas-Sarsat from time to time, as necessary to satisfy capacity requirements. The frequency channels in the band 406.0 - 406.1 MHz are defined by the centre frequency of the channels, as assigned by Cospas-Sarsat. Except as provided below for beacons type approved by Cospas-Sarsat for operation at 406.025 MHz and 406.028 MHz, the beacon carrier frequency shall be set in accordance with the Cospas-Sarsat 406 MHz Channel Assignment Table, as provided in document C/S T.012 “Cospas-Sarsat 406 MHz Frequency Management Plan”, at the designated centre frequency of the appropriate channel ±1 kHz, and shall not vary more than ± 5 kHz from that channel centre frequency in 5 years. The carrier frequency of beacons operating in the 406.025 MHz channel in accordance with the Cospas-Sarsat 406 MHz Channel Assignment Table shall be set at 406.025 MHz ±2 kHz. The carrier frequency shall not vary more than ± 5 kHz from 406.025 MHz in 5 years. The carrier frequency of beacons operating in the 406.028 MHz channel in accordance with the Cospas-Sarsat 406 MHz Channel Assignment Table shall be set at 406.028 ± 1 kHz. The carrier frequency shall not vary more than +2 kHz /-5 kHz from 406.028 MHz in 5 years.

This section of the beacon specification does not apply to Cospas-Sarsat System beacons (i.e., orbitography or calibration beacons). The transmitted frequency requirements for orbitography beacons are detailed in document C/S T.006. 119 BITS (SEE SECTION 3) 160 ms CARRIER

BITS

BITS (2) (1) NOTE: (3)

2-6

The transmitted frequency short-term variations shall not exceed 2 parts in 109 in 100 ms. The transmitted frequency medium-term stability shall be defined by the mean slope of the frequency versus time over a 15-minute period and by the residual frequency variation about the mean slope. The mean slope shall not exceed 1 part in 109 per minute, except as noted below. The residual frequency variation shall not exceed 3 parts in 109. After allowing 15-minutes for beacon warm-up, the medium-term frequency stability requirements shall be met for all defined environmental conditions, except for the temperature gradient and the thermal shock as defined in sections 4.2.2 and 4.2.3 respectively. The mean slope of the medium-term frequency stability measurements shall not exceed 2 parts in 109 per minute, and the residual frequency variation shall not exceed 3 parts in 109: • during the variable temperature conditions of the temperature gradient (+/- 5 C/h slope) defined in section 4.2.2 and for the 15 minute periods immediately after the temperature had stabilised at the maximum or minimum values; and • during the thermal shock defined in section 4.2.3. It is recommended that distress transmissions commence as soon as possible after activation, but in accordance with section 4.5.6. The mean slope and the residual frequency variation shall be measured as follows: Data shall be obtained by making 18 sequential frequency measurements, one every repetition period (50 sec ±5 percent, see section 2.2.1) over an approximate 15-minute interval; each measurement shall be a 100-ms frequency average performed during the modulated part of the message. The mean slope is defined as that of the least-squares straight-line fit to the 18 data points. Residual frequency variation is defined as the root mean square (RMS) error of the points relative to the least-squares estimate. For ELT(DT)s, the requirement of medium-term stability (mean slope and residual frequency variation) does not apply. Transmitter Power Output For all beacon types other than ELT(DT), the transmitter power output shall be within the limits of 35 to 39 dBm measured into a 50-Ohm load. This power output shall be maintained during the minimum operating lifetime of 24 hours (or for a longer period, as specified by National Administrations, or by International Organisations, or as declared by the beacon manufacturer, if it is different from 24 hours), at any temperature throughout the specified operating temperature range. Power output rise time shall be less than 5 ms measured between the 10% and 90% power points. The power output is assumed to rise linearly from zero and therefore must be zero prior to about 0.6 ms before the beginning of the rise time measurement; if it is not zero, the maximum acceptable level is -10 dBm. For ELT(DT)s, the transmitter power output shall be within the limits of 36 dBm to 39 dBm measured into a 50-Ohm load. This power output shall be maintained during the minimum operating lifetime of 370-minutes (or for a longer period, as specified by National Administrations or by International

2-7

Organizations, or as declared by the beacon manufacturer, if it is different from 370 minutes), or for an ELT(DT) specifically designed to withstand a crash, or an ELT(DT) combined with an Automatic ELT for the Duration of Continuous Operation as defined in either 4.5.10.5 or 4.5.11.7 as applicable, at any temperature throughout the specified operating temperature range. Power output rise time shall be less than 2 ms measured between the 10% and 90% power points. The power output is assumed to rise linearly from zero and therefore must be zero prior to about 0.6 ms before the beginning of the rise time measurement; if it is not zero, the maximum acceptable level is -10 dBm. Antenna Characteristics The following antenna characteristics are defined for all azimuth angles and for elevation angles greater than 5° and less than 60°:

Pattern : hemispherical
Polarization : circular (RHCP) or linear
Gain : between: -3 dBi and 4 dBi over 90% of the above region -2 dBi and 6 dBi over 90% of the above region for ELT(DT)s
Antenna VSWR : not greater than 1.5:1 The antenna characteristics should be measured in a configuration as close as possible to its operational condition. Spurious Emissions The in-band spurious emissions shall not exceed the levels specified by the signal mask in Figure 2.4, when measured in a 100 Hz resolution bandwidth. Figure 2.4: Spurious Emission Mask for 406.0 to 406.1 MHz Band Pc (POWER OUTPUT OF UNMODULATED CARRIER) 0 dBc

dBc

35 dBc
35 dBc

dBc

kHz

kHz fc

kHz

kHz 24 kHz

24 kHz 406.1 MHz 406.0 MHz FREQUENCY (fc = BEACON CARRIER FREQUENCY)

2-8

Data Encoding The data shall be encoded biphase L, as shown in Figure 2.5. Figure 2.5: Data Encoding and Modulation Sense Modulation The carrier shall be phase modulated positive and negative 1.1 ± 0.1 radians peak, referenced to an unmodulated carrier. Positive phase shift refers to a phase advance relative to nominal phase. Modulation sense shall be as shown in Figure 2.5. The rise (R) and fall (F) times of the modulated waveform, as shown in Figure 2.6, shall be 150 ± 100 s. For ELT(DT)s, the rise (R) and fall (F) times of the modulated waveform, shall be between 50 µs and 150 µs. Modulation symmetry (see Figure 2.7) shall be such that:

 + −     Voltage Standing-Wave Ratio The modulator and 406 MHz transmitter shall be able to meet all requirements, except for those in paragraph 2.3.2 (transmitter power output), at any VSWR between 1:1 and 3:1, and shall not be damaged by any load from open circuit to short circuit. Maximum Continuous Transmission The distress beacon shall be designed to limit any inadvertent continuous 406 MHz transmission to a maximum of 45 seconds.

2-9

Modulated Signal Time Figure 2.6*: Definition of Modulation Rise and Fall Times Time Modulated Signal Figure 2.7†: Definition of Modulation Symmetry

END OF SECTION 2 -

Figure not to scale. † Figure not to scale.

3-1

DIGITAL MESSAGE CONTENT 3.2 Basic Structure The digital message which is transmitted by the 406 MHz beacon consists of: 112 bits for the short message; and 144 bits for the long message. These bits are divided into five groups: The first 24 bits transmitted, positions 1 through 24, are system bits; they are defined in section 2 and are used for bit and frame synchronization. (1) The following 61 bits, positions 25 through 85, are data bits. This bit group is referred to as the first protected data field (PDF-1). The first data bit (position 25) indicates if the message is short or long: "0" = short message, "1" = long message. (2) The following 21 bits, positions 86 through 106, are a Bose-Chaudhuri-Hocquenghem or BCH (82,61) error-correcting code. This bit group is referred to as the first BCH error-correcting field (BCH-1). This code is a shortened form of a BCH (127,106) triple error-correcting code, as described in Annex B. This code can detect and correct up to three bit errors in the 82 bits of (PDF-1 + BCH-1). The combination of PDF-1 and BCH-1 is referred to as the first protected field. (3) The following group consists of data bits, the number and definition of these bits depends on the message format, as follows: Short message: the last 6 bits of the message in positions 107 through 112, these data bits are not protected. This bit group is referred to as the non-protected data field; Long message: the following 26 bits of the message in positions 107 through 132. This bit group is referred to as the second protected data field (PDF-2). (4) The last 12 bits of the long message, positions 133 through 144, are a Bose-Chaudhuri- Hocquenghem or BCH (38,26) error-correcting code. This bit group is referred to as the second BCH error-correcting field (BCH-2). This code is a shortened form of a BCH (63,51) double error-correcting code, as described in Annex B. This code can detect and correct up to 2 bit errors in the 38 bits of (PDF-2 + BCH-2). The combination of PDF-2 and BCH-2 is referred to as the second protected field.

3-2

3.3 Beacon Coding Beacon coding methods are defined in Annex A to this specification. Specific operational requirements for beacon coding, such as the self-test mode and the encoding of position data, are defined in section 4 of this specification. Beacon message protocols that support encoded location information (e.g., User-Location, Standard Location and National Location) shall only be used in beacons that are designed to accept encoded location information from a navigation system. The 15 hexadecimal characters that uniquely identify each 406 MHz beacon are called the beacon identification or beacon 15 Hex ID. This beacon identification comprises bits 26 to 85 of PDF-1. For location protocols, the position data bits in PDF-1 are set to the default values specified in Annex A. For purposes of non-operational testing (e.g., type-approval testing), beacons shall support message encoding with test variants for each of the declared message protocols intended for use in that beacon, defined in sections A1.3 and A2.6 (for user protocols), A3.3.3 (for test location protocols (not including RLS and ELT(DT))), A3.3.7.1 and A3.3.7.3 (for RLS location protocol) and A3.3.8.1 and A3.3.8.4 (for ELT(DT) location protocol). 3.4 Cancellation Message (ELT(DT) only) When the ELT(DT) is deactivated the ELT(DT) shall transmit the first cancellation messages within 5 seconds, and transmit a total of 10 identical cancellation messages at intervals of 10 seconds ±0.5 seconds, after which time the beacon shall cease transmitting. In the case the ELT(DT) is activated (e.g., triggered) during the cancellation sequence, the beacon shall terminate the cancellation transmission sequence and reinitiate the alert sequence per section 2.2.1. The content of the Cancellation Message is documented in Annex A, section A3.3.8 and table A11.

END OF SECTION 3 -

4-1

ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS 4.1 General As explained in section 1.2, the environmental and operational requirements defined in this section are not intended to be exhaustive. They are minimum requirements, which may be complemented by national or international standards. 4.2 Thermal Environment Operating Temperature Range Three standard classes of operating temperature range are defined, inside which the system requirements of section 2 shall be met: Class 0: -55°C to +70°C Class 1: -40°C to +55°C Class 2: -20°C to +55°C Temperature Gradient All system requirements of section 2, including the frequency requirements defined in section 2.3.1, shall be met when the fully packaged beacon is subjected to the temperature gradient shown in Figure 4.1. Thermal Shock All system requirements of section 2 shall be met, including the mean slope of the medium-term frequency stability measurements which shall not exceed 2.0 parts in 109 per minute, for measurements beginning 15 minutes after simultaneously activating the beacon and applying a thermal shock of 30°C within the specified operating temperature range of the beacon. Subsequently, system requirements shall continue to be met for a minimum period of two (2) hours. For ELT(DT)s all system requirements of section 2 shall be met, excluding the medium-term frequency stability requirements, for measurements beginning with the first transmission after simultaneously activating the beacon and applying a thermal shock of 50°C within the specified operating temperature range of the beacon. Subsequently, system requirements shall continue to be met for a minimum period of two (2) hours.

4-2

NOTES: Tmax = + 70°C (Class 0 beacon) Tmax = + 55°C (Class 1 & 2 beacons) Tmin = - 55°C (Class 0 beacon) Tmin = - 40°C (Class 1 beacon) Tmin = - 20°C (Class 2 beacon) tstart = test start time tstop = test stop time ton = beacon turn-on time after 2 hour “cold soak” tmeas = start time of frequency stability measurement (ton + 15 min, except for ELT(DT)s where tmeas = ton) A* = 7°C/hour for Class 0 (45oC/hour for ELT(DT)) A* = 5°C/hour for Class 1 and Class 2 (33oC/hour for ELT(DT)) α = For ELT(DT)s the time between points C and D is reduced on the down-ramp test to one (1) hour. SLOPE = +A* °C/h SLOPE = -A* °C/h TIME tmeas 2h 2h 1h 2hα TEMPERATURE (°C) ton Twarm-up = 15 min Tmin tstart tstop C D Figure 4.1: Temperature Gradient 4.3 Mechanical Environment Beacons shall be submitted to vibration and shock tests consistent with their intended use.

4-3

Internationally-recognized standards such as RTCA/DO-183* for ELTs could be used by the national authorities. 4.4 Other Environmental Requirements Other environmental requirements such as humidity tests, altitude tests, over/under pressure tests, waterproofness tests, sand and dust tests, fluids susceptibility tests, etc., may be defined by national authorities, preferably using internationally-recognized standards. 4.5 Operational Requirements Duration of Continuous Operation The minimum duration of continuous operation shall be at least 24 hours† at any temperature throughout the specified operating temperature range. The minimum duration of continuous operation for an ELT(DT) to meet the ICAO GADSS requirement at any temperature throughout the specified operating temperature range shall be 370 minutes‡. At the end of the 370-minute period, the ELT(DT) shall continue transmitting on the same schedule as before the 370-minute limit was reached until the ELT(DT) is either deactivated, or runs out of battery life. Minimum duration of continuous operation requirements for Crash Survivable ELT(DT)s can be found in section 4.5.10.5 and for Combined ELT(DT)s in section 4.5.11.5. Other Operational Requirements Other operational requirements such as installation and maintenance methods, remote monitoring, activation methods on planes or boats, etc. may be defined by national authorities. Auxiliary Radio-Locating Device The transmission of the 406 MHz satellite signal shall take precedence over any Radio-Locating Signals. Homing signal types should be momentarily interrupted, delayed, rescheduled, or eliminated according to the relevant standard for each type, in order to ensure that homing signals are not transmitted at the same time as the 406-MHz signal to satellites.

Document RTCA/DO-183 was obsolete in 1989, and later was replaced with document RTCA/DO-204B, subject to future changes. † For installations meeting IMO GMDSS requirements, a minimum operating lifetime of 48 hours at any temperature throughout the specified operating temperature range is necessary. ‡ This duration is based on ICAO standards for Extended Diversion Time operations (EDTO) and the maximum diversion time capability of existing aircraft types, as of April 2018.

4-4

The distress beacon may transmit radio-locating signals in compliance with appropriate national or international standards. The inclusion of any Radio-Locating Signals within a beacon and the prioritization of these Radio-Locating Signals is the responsibility of the appropriate national or international bodies. Any such radio-locating device must satisfy all the national performance standards applicable to radio-locating devices at the selected frequency. Beacon Self-Test Mode All beacons shall include a self-test mode of operation. In the self-test mode beacons shall transmit a 406 MHz signal with digital message encoded in accordance with Annex A to this specification and 121.5 MHz signal (if applicable). The content of the self-test message shall always provide the beacon 15 Hex ID, except for location protocol beacons when transmitting a GNSS self-test message encoded with location data. The self-test mode (or GNSS self-test mode) shall not be used for the purposes of repetitive automated interrogation of the beacon status. A beacon (e.g., ELT(DT)) may contain a different test mode that can be used for repetitive automated interrogation of its status, but operation of the beacon in this different test mode shall not result in the transmission of a 406 MHz signal or other radio locating signals (if applicable), nor interfere with the normal operation of the beacon. In the self-test mode the digital message must have a frame synchronization pattern of 011010000. This bit pattern complements the last 8 bits of the normal frame synchronization pattern so that this test burst will not be processed by the satellite equipment. The complete self-test transmission must be limited to one burst only regardless of the duration of activation of the self-test control. The maximum duration of the self-test mode transmission should be 440 ms (±1%) for a short message and 520 ms (±1%) for a long message. Except for ELT(DT)s, which shall transmit long self-test message, other types of beacons coded with a Location Protocol may transmit either a long self-test message or a short self-test message. If a 440 ms (short self- test message) transmission is used for beacons encoded with Location Protocol long format messages, the message shall be truncated (stop at bit 112) without changing the long message format flag bit 25 from a 1. ELT(DT)s coded with a 3LD in PDF-2 shall transmit a long self-test message with the rotating field and the encoded 3LD in PDF-2 (if the ELT(DT) is capable of transmitting a 3LD in PDF-2, but has not been coded with a 3LD, then the default 3LD shall be used). The self-test mode shall be activated by a separate switch position. The self-test function shall perform an internal check and provide distinct indication (which shall occur during the declared timeframe for the self-test mode) that: the self-test mode has been initiated; RF power is being emitted at 406 MHz and at 121.5 MHz, if applicable;

4-5

the internal check has passed successfully, or has failed; the beacon battery may not have sufficient energy to support beacon operation for the manufacturer-declared minimum operating lifetime*† ; and for RLS-capable beacons, when coded with the RLS Location protocol (i.e., the RLS functionality is enabled), the beacon shall: i) provide an indication that RLS functionality is enabled, and ii) activate the RLS and RLM indicator(s) to confirm to the user that the indicator(s) are functional. The beacon shall be designed to ensure an automatic termination of the self-test mode immediately after completion of the self-test cycle and indication of the self-test results. Regardless of the self- test switch position, this shall not prevent the beacon from being activated automatically or manually, as applicable, once the self-test mode has terminated. For location protocol beacons the content of the encoded position data field of the self-test message shall be the default values specified in Annex A. Additionally, location protocol beacons may optionally provide for the transmission of a GNSS self-test message encoded with location data. ELT(DT) beacons shall include a GNSS self-test mode resulting in a single burst transmission. All ELT(DT)s, including those capable of transmitting a 3LD in PDF-2, shall transmit a long GNSS self-test message with location data encoded in PDF-1 and PDF-2 (bits 113 and 114 shall indicate the location freshness). Location protocol beacons which provide for the transmission of an encoded position in a GNSS self-test message shall: activate the GNSS self-test mode via a distinct operation from the normal self-test mode, but the GNSS self-test mode may be activated via the same self-test switch(es) or operation provided that it shall require a separate, deliberate action by the user that would limit the likelihood of inadvertent activation, and shall not result in more than a single self-test burst regardless of the duration of activation of the GNSS self-test control; provide for that in the case of internal GNSS receivers powered by the primary‡ beacon battery the number of GNSS self-tests shall be limited by the beacon design to prevent inadvertent battery depletion;

By decision of the Cospas-Sarsat Council at its Fifty-seventh Session, this requirement will only be mandatory for new beacon models submitted for type approval testing after 1 January 2018, as a target, subject to further review and consideration. † Self-test indication of insufficient battery energy shall commence prior to the point, at which the residual battery energy is less than the energy required to support the declared minimum operating lifetime, as declared by the beacon manufacturer. ‡ The primary battery is the battery which is powering the 406 MHz function.

4-6

provide a distinct indication to register successful completion or failure of the GNSS self-test; provide, for beacons with internal navigation devices:

a separate distinct indication that the limited number of GNSS self-test attempts has been attained, which shall be immediately indicated to the user once the GNSS Self-test has been initiated,
a means to prevent any RF-transmissions or further GNSS receiver power drain, if further GNSS self-test activations are attempted, once the GNSS Self-test limit has been reached; ensure that the duration of the GNSS self-test is limited to a maximum time duration set by the manufacturer, noting that:
in the case where the beacon fails to encode the location into the 406 MHz message within this time limit the GNSS self-test shall cease, the beacon shall indicate a GNSS self-test failure and may transmit a single self-test burst with default location data in both PDF-1 and PDF-2,
in the case where the beacon encodes the location into the 406 MHz message within this time limit the GNSS self-test shall cease at that time (before the time limit is reached), indicate a GNSS self-test pass and may transmit a single self-test burst containing the valid location data in both PDF-1 and PDF-2; provide an automatic termination of GNSS self-test mode, irrespective of the switch position, immediately after completion of the GNSS self-test cycle and indication of the test results; for beacons that provide a GNSS self-test using both the internal navigation device and the external navigation interface:
when the GNSS Self-test is initiated, the beacon shall attempt to obtain location data from the internal navigation device, if this data is available,
if location data is not available from the internal navigation device, then the beacon shall obtain the location data from the external navigation interface,
if the location data from the external navigation interface is not available, the beacon shall wait to obtain location data from the internal navigation device for the maximum duration of the GNSS self-test, as declared by the beacon manufacturer; and include instructions for the GNSS self-test in the Beacon Instruction Manual which shall include a clear warning on the use and limitations of this function, noting that instructions for the GNSS self-test shall not be included on the beacon itself.

4-7

Encoded Position Data* 4.5.5.1 General Beacon position data, obtained from a navigation device internal, integral† or external to the beacon, may be encoded in the beacon message. Position data can be encoded in either the PDF-2 part of the message, or in both PDF-1 and PDF-2 parts of the message. The two levels of position resolution that can be encoded in the beacon message include: • position data with resolution of 4 seconds in PDF-2, given as an offset of the position data provided in PDF-1 with a resolution of 30 minutes, 15 minutes or 2 minutes; and • position data with resolution of 4 minutes in PDF-2, together with any of the user protocol identification methods used in PDF-1. Operation or failure of an internal or external navigation device providing position data to the beacon shall not degrade beacon performance. ELT(DT)s shall comply with the requirements of section 4.5.5.6 instead of sections 4.5.5.2 to 4.5.5.5. 4.5.5.2 Message Content and Timing Position data shall be encoded into the beacon message according to one of the methods specified in Annex A. The identification data and encoded position data are protected by a BCH error- correcting code. A 21-bit BCH code (BCH-1) protects the data of the first protected data field (PDF-1) and a 12-bit BCH code (BCH-2) protects the data of the second protected data field (PDF-2). The BCH codes shall always correspond to the message content. The beacon shall recompute these codes each time the message content is changed. The beacon shall commence transmissions upon activation even if no valid position data are available. Until valid position data is available, the content of the encoded position data field of the message shall be the default values specified in Annex A. The first input of position data into the beacon message shall occur as soon as valid position data becomes available. All beacons with internal navigation devices shall provide position data updates, in accordance with section 4.5.5.4. If, after providing valid data, the navigation input fails or is not available, the beacon message shall retain the last valid position for 4 hours ± 5 minutes after the last valid position data input. After 4 hours ± 5 minutes the encoded position shall be set to the default values specified in Annex A.

ELTs carried to satisfy the requirements of ICAO Annex 6, Parts I, II and III shall operate in accordance with ICAO Annex 10. † An integral navigation device is a part of the beacon system but may be separate to the beacon transmitter and shall comply with the performance requirements of an internal navigation device.

4-8

When the beacon radiates a 406 MHz signal in the self-test mode, the content of the encoded position of the self-test message shall be set to the default values specified in Annex A, except for location protocol beacons in the optional GNSS self-test mode, when the beacon transmits a single self-test message with encoded position. 4.5.5.3 Internal Navigation Device Performance An internal navigation device shall be capable of global operation and shall conform to an applicable international standard. An internal navigation device shall incorporate self-check features to ensure that erroneous position data is not encoded into the beacon message. The self- check features shall prevent position data from being encoded into the beacon message unless minimum performance criteria are met. These criteria could include the proper internal functioning of the device, the presence of a sufficient number of navigation signals, sufficient quality of the signals, and sufficiently low geometric dilution of precision. The distance between the position transmitted in the beacon message and the known* beacon position at the time of the position update shall not exceed:

500 m for beacons transmitting messages encoded with the Standard, National, or RLS Location protocols,
5.25 km for beacons transmitting messages encoded with the User-Location protocol. The encoded position data shall be provided in the WGS 84 or GTRF geodetic reference systems. The internal navigation device shall provide valid data within 10 minutes after its activation. Internal navigation device cold start shall be forced at every beacon activation. Cold start refers to the absence of time dependent or position dependent data in memory, which might affect the acquisition of the GNSS position. 4.5.5.3.1 ELTs with an Internal Navigation Device Powered Externally Prior to Activation If an internal navigation device cold start is forced upon application of external power to the internal navigation device, and does not cold start upon beacon activation, then the requirements of this section apply. For ELTs with externally powered internal navigation devices, which are continuously operational prior to beacon activation, and are designed to obtain and update position data from an internal

The known beacon position shall have a 2-D location accuracy of ± 10 meters or better, which may be achieved by placing the beacon on the earth surface in a surveyed position with known geographical coordinates, or by determining the beacon position with a high-resolution GNSS receiver.

4-9

GNSS receiver and retain position data in the beacon memory, prior to the beacon activation, the internal navigation device cold start shall be forced on each initial power up of the internal navigation device. To facilitate the provision of position data prior to activation, the ELT shall attempt to update the position retained in memory from the internal navigation device at intervals of no longer than 2 seconds. If, after ELT activation, current navigation data is not available, then the ELT shall transmit its first and subsequent 406-MHz messages with the last position available prior to ELT activation (as retained in beacon memory for this purpose) until a new position is available or 4 hours ± 5 minutes has elapsed. The ELT shall not use external power to power the internal navigation device once activated. After activation the beacon shall only be powered by the internal battery, apart from external interfaces to/from the beacon approved for use with the beacon (e.g., Remote Control Panel, ARINC interface, etc.). 4.5.5.4 Internal Navigation Device Timing* The internal navigation device within the beacon shall be activated immediately after the beacon is turned on. Once the navigation device acquires a fix, it shall continue to attempt to acquire locations for a further period of at least 10 seconds and encode the location with the lowest HDOP obtained during this period into the next available beacon message. Between each attempt to obtain a ‘fix’ the navigation device may be put into a sleep mode that may retain ephemeris and/or almanac data, such that when it is subsequently woken up it warm starts. Subsequent valid updated location ‘fixes’ shall be encoded into the next available beacon message. The navigation device search/sleep timing should be determined by the beacon manufacturer to optimize location performance whilst conserving battery capacity, subject to the following minimum requirements: The internal navigation device shall make an attempt to obtain an initial location for a period of at least 10 minutes after beacon activation unless a location is obtained sooner than this. After this initial attempt to obtain a location, the internal navigation device shall make subsequent attempts to obtain an initial location, or an updated location, as applicable, at intervals of no more than 15 minutes and no less than every 4 minutes and 25 seconds, measured from the end of the last update attempt, for

These requirements are mandatory for new beacon models first submitted for type approval testing after 1 December 2021, however manufacturers may voluntarily choose to comply with these requirements before this date. For beacons first submitted for type approval testing prior to this date, the version of C/S T.001 in force at the time of submission shall apply. Type approved beacons subject to change notices do not have to comply with these latest internal navigation device timing requirements and may continue to comply with the version of C/S T.001 that was in force at the time of the original type approval, unless the manufacturer decides to update the beacon navigation system, in which case the applicability of the these requirements will be as of 1 December 2022.

4-10

the remainder of the manufacturer declared minimum operating lifetime of the beacon*†. Whenever an initial location or an updated location is obtained, it shall be encoded into the next available beacon message to be transmitted. If an updated location is not obtained prior to the transmission of the next beacon message then the previous location (or if there was no previous location, default position values) shall be transmitted until either a location becomes available or 4 hours ± 5 minutes have elapsed (after which time the encoded position shall be set to the default values). Attempts at obtaining an initial location or location update shall require the navigation device to be powered up for a period of at least 90 seconds each time, unless a location is obtained sooner than this, in which case the navigation device may then be put into a sleep mode 10 seconds later (noting that if this occurs after 80 seconds, this 10-second period can be reduced accordingly to maintain the total 90 seconds navigation device ‘on’ time). 4.5.5.5 External Navigation Device Input It is recommended that beacons, which are designed to accept data from an external navigation device, be compatible with an applicable international standard, such as the IEC Standard on Digital Interfaces (IEC Publication 61162). Features should be provided to ensure that erroneous position data is not encoded into the beacon message. For a beacon designed to operate with an external navigation device, if appropriate navigation data input is present, the beacon shall produce a digital message with the properly encoded position data and BCH code(s) within 1 minute after its activation. If a beacon is designed to accept position data from an external navigation device prior to beacon activation, navigation data input should be provided at intervals not longer than: • 20 minutes for EPIRBs and PLBs; or • 1 minute for ELTs. 4.5.5.6 ELT(DT) Navigation Device Requirements ELT(DT)s shall incorporate an internal navigation device and may incorporate an interface to an external navigation device (e.g., the aircraft avionics), which produce navigation data for encoding into the beacon message. ELT(DT) shall be encoded with the ELT(DT) Location Protocol. The BCH codes shall always match the message content. The ELT(DT) shall recompute these codes each time the message content is changed.

For EPIRBs with VDR functionality, after at least 48 hours of operation, the update rate can be extended to a maximum of once every 60 minutes for the remainder of the operating lifetime, if required. † IMO Performance standards applicable to EPIRBs to be used on SOLAS-compatible vessels (Resolution MSC.471 (101) applicable from 1 July 2022, Annex, Part 4, section .1 requires that, when the EPIRB is activated, the GNSS receiver position fix shall be updated at intervals of no more than five minutes.

4-11

The first ELT(DT) transmission shall occur no more than 5 seconds after the beacon activation. If, after the ELT(DT) activation, current navigation data is not available, then the ELT(DT) shall transmit its first and subsequent 406-MHz messages with the last position available prior to the ELT(DT) activation (which shall be retained in beacon memory for this purpose) and with the encoded position freshness (to an accuracy of 5 seconds). To facilitate the provision of position data prior to activation, the ELT(DT) shall attempt to update the position retained in memory from either the internal navigation device or the external navigation input at intervals of no longer than 2 seconds. If no position is available prior to the ELT(DT) activation, or if 4 hours ± 5 minutes elapse since the last valid position data input, the ELT(DT) shall transmit the default position values specified in Annex A until such time, as navigation data becomes available either from an internal GNSS receiver or, if applicable, from an external navigation device. If navigation data is available, 406-MHz transmissions shall contain a valid encoded position, calculated within the 2 seconds immediately prior to a 406-MHz transmission, and the encoded position freshness. The initial position transmitted in the first burst may be obtained from either the internal navigation device or from the external navigation device input.* The transmission in the beacon message of this external source of position is only subsequently allowed if the internal GNSS receiver is not able to produce a valid encoded position less than 2 seconds before the burst. If position data is available from both sources, within 2 seconds before any subsequent burst, then the location produced by the internal GNSS receiver has priority over the external source of data. Internal navigation device cold start shall be forced on each initial power up of the internal navigation device, but shall not occur if the ELT(DT) is subsequently activated or between ELT(DT) transmissions. Cold start refers to the absence of time dependent or position dependent data in the beacon’s or in the GNSS receiver’s memory, which might affect the acquisition of the GNSS position. ELT(DT)s shall attempt to acquire fresh position information prior to every 406 MHz transmission and shall encode the latest position obtained within less than 2 seconds (defined as current position) prior to each burst into that transmission. For ELT(DT)s using rotating field data in PDF-2, (e.g., the aircraft operator 3LD), the current position is transmitted with its full resolution (using both PDF-1 and PDF-2) according to the transmission scheme described in section 2.2.1. If an updated position is not available within 2 seconds immediately prior to every 406 MHz transmission, then the ELT(DT) shall transmit the latest position that it has, unless this position is more than 4 hours old, in accordance with section 4.5.5.2, in which case it shall revert to transmitting the default position until such time as an updated position is available.

The internal navigation device or even the entire ELT(DT) may be powered by an external source prior to its activation in order to comply with this requirement.

4-12

The freshness of the encoded location transmitted by the ELT(DT) shall be indicated in the ELT(DT) message as defined in Annex A.3.3.8. The internal navigation device shall be capable of global operation and shall conform to an applicable international standard. The internal navigation device shall incorporate self-check features to ensure that erroneous position data is not encoded into the beacon message. The self- check features shall prevent position data from being encoded into the ELT(DT) message unless minimum performance criteria are met. These criteria could include the proper internal functioning of the device, the presence of a sufficient number of navigation signals, sufficient quality of the signals, and sufficiently low geometric dilution of precision. The navigation device shall provide a 3-D position which shall be encoded into the ELT(DT) message in accordance with Annex A.3.3.8. If a 3-D position is not available, then a 2-D position shall be provided and the altitude bits in the message shall be set to their default values. The distance between the position provided by the internal navigation device, at the time of the position update, and the 2D position contained in the next 406 MHz transmission from the ELT(DT) while static shall not exceed 200 m. The distance between the altitude provided by the internal navigation device, at the time of the position update, and the altitude contained in the next 406 MHz transmission from the ELT(DT) while static shall not exceed 700 m. The encoded position data shall be provided in the WGS 84 or GTRF geodetic reference systems. If the ELT(DT) incorporates an interface to an external navigation device, it is recommended that this be compatible with an applicable international standard, such as the IEC Standard on Digital Interfaces (IEC Publication 61162). When the ELT(DT) radiates a 406 MHz signal in the self-test mode, the content of the encoded position of the self-test message shall be set to the default values specified in Annex A, except when transmitting an optional GNSS self-test, when the ELT(DT) shall radiate a single self-test message with encoded position. Beacon Activation The beacon should be designed to prevent inadvertent activation. After activation, the beacon shall not transmit a 406 MHz distress message until at least one repetition period (as defined in section 2.2.1) has elapsed. Thereafter the beacon shall not transmit more frequently than the minimum repetition period (as defined in section 2.2.1) regardless of the duration of activation of any controls or the activation of any combination of controls. Once activated and transmitting 406 MHz distress messages, the activation of any control other than the ‘Off’ or ‘Reset’ controls shall not stop the beacon from transmitting or result in transmission of messages with inverted frame sync (self-test bursts).

4-13

ELTs when automatically activated by G-switch / deformation shall transmit the first 406 MHz distress message as soon as possible, which shall be within no more than 15 seconds after beacon activation*. For ELT(DT)s, the transmission of 406 MHz distress messages shall start within 5 seconds after beacon activation, as defined in section 2.2.1. 4.5.6.1 ELT(DT) Modes of Operation ELT(DT)s shall allow for automatic and manual means of activation. All ELT(DT )s shall include a means of receiving information from the aircraft to determine whether the ELT(DT) is on the ground or in the air and shall take this status into account when activated. ELT(DT)s shall also have means of deactivation by the same means of activation which shall be followed by a cancellation message sequence. Standalone ELT(DT)s (i.e., those that do not comply with either sections 4.5.10 or 4.5.11) should function as follows. National Administrations or Aviation Authorities may define additional functionality. Activation Criteria Activation Means Manual Avionics On Ground 406 Distress Tracking (DT) sequence and 121.5 optional if available Avionics Disabled In Air 406 DT sequence only preferred, 121.5 optional if available 406 DT sequence only If the beacon is activated in one aircraft state (e.g., In Flight) and the aircraft transitions to another state (e.g., On Ground) while the beacon is still activated, the beacon transmission characteristics should behave as indicated for the new aircraft state as per the table above. Consequently: • If the ELT(DT) has been automatically activated by the triggering system†, it shall only be de-activated by the same means.

This requirement is mandatory to new beacon models submitted for type-approval testing at accepted test facilities after 1 January 2018. † For example, triggered in compliance with EUROCAE ED-237

4-14

• If the ELT(DT) has been automatically activated by the beacon*, it shall only be deactivated by manually resetting the beacon. • If the beacon has been manually activated (i.e., from the cockpit), it shall only be manually de-activated. • If the beacon has been activated by any combination of activation means, it can only be de-activated once each activation means has been deactivated. • Bits 107 and 108 of the ELT(DT) Location Protocol message shall indicate the most recent means of activation. If one means of activation is removed but others remain then Bits 107 and 108 shall revert to indicating the previous most recent means of activation. Thus an ELT(DT) shall as a minimum have the following modes of operation: OFF - The complete ELT(DT) (and any related components) is/are unpowered. ARMED - The ELT(DT) or some parts of it may if required be powered up, such that when it is activated automatically† or manually, it can start transmitting within 5 seconds and meet the requirements in this specification for ELT(DT)s including the provision of encoded location in the first burst. However, until the ELT(DT) is activated there are no outputs from the ELT(DT) at all (e.g., no 406 MHz or Homing Signal transmissions). ON - The ELT(DT) has been either activated automatically and/or has been manually activated and is transmitting 406 MHz signals in full compliance with the ELT(DT) requirements in this specification. RESET – The ELT(DT) is deactivated and ceases transmitting distress alerts and instead transmits a sequence of cancellation messages as defined by section 3.3. Upon completion of the cancellation message sequence, the ELT(DT) reverts to the ARMED condition. The ELT(DT) can only be deactivated as defined above. RLS Beacon Requirements Beacons with a Return Link Service (RLS) function shall support message encoding with the RLS Location Protocol and a Location Test Protocol‡, and shall meet the following additional requirements.

For example, triggered by G-switch / deformation. † For example, triggered in compliance with EUROCAE ED-237 or by G-switch / deformation. ‡ The location test protocol may be either Standard Location Test or National Location Test protocol and must be used in addition to the RLS Location Test protocol.

4-15

4.5.7.1 GNSS Receiver The RLS beacon shall contain an internal GNSS Receiver capable of receiving and decoding Return Link Messages (RLMs) from a Cospas-Sarsat recognised Return Link Service Provider (RLSP) and of providing these messages to the beacon in an IEC 61162-1 compliant sentence, or in an equivalent proprietary sentence defined by the GNSS-receiver manufacturer. If the GNSS receiver is capable of processing signals from only one GNSS constellation, this shall be the associated RLS provider’s constellation, and satellites should be tracked above 5 degrees of elevation. If the GNSS receiver is capable of processing signals from several GNSS constellations (multi-constellation GNSS receiver), such a receiver shall prioritize the reception from satellites of the GNSS constellation associated with the RLS provider above 5 degrees of elevation over other GNSS constellations. The following Return Link Messages have been defined to date: • Acknowledgement Type-1 RLM: An automated response that acknowledges receipt of the RLS request, • Test Return Link Message: An RLM dedicated for testing, including automatic response that acknowledges receipt of the RLS request from an RLS beacon coded with an RLS Location Test Protocol. The definition of the RLM message content included as part of the Galileo L1 navigation message is defined in the Galileo Open Service Public Signal in Space ICD Issue 1.3. 4.5.7.2 RLS GNSS Receiver Operation 4.5.7.2.1 Operation Cycle In addition to the beacon’s normal GNSS receiver operating cycle as defined in section 4.5.5.4, or as defined by the beacon manufacturer if the receiver is designed to be active more frequently than those requirements, the RLS beacon shall: when encoded with an RLS Location Protocol maintain the GNSS receiver in an active mode of operation for a minimum period of 30 minutes after beacon activation or until a valid RLM message is acquired or the beacon is deactivated, whichever occurs first, such that it can continuously check for receipt of an RLM message and Coordinated Universal Time (UTC), during this period; as soon as possible determine UTC from the GNSS receiver and maintain a clock for at least 6 hours from the time the beacon was first activated, to an accuracy of better than three seconds (once UTC has been acquired) or until the beacon is deactivated (if UTC is not acquired see (e) below);

4-16

if an RLM message has not been received within the first 30 minutes period, then, at the end of this time, utilise UTC time to next activate the GNSS receiver* at the next occurrence of UTC Moffset† minutes (where 0 ≤ Moffset ≤ 59), to check for receipt of an RLM, for a minimum period of 15 minutes, or until an RLM message is acquired (e.g. if the first 30 minute period ended at 02:29 and Moffset is 15 minutes, then next activate the GNSS receiver at 03:15, or if Moffset is 44 minutes, then next activate the GNSS receiver at 02:44); then during each subsequent hour reactivate* the GNSS receiver (in accordance with section 4.5.5.4 and this section 4.5.7.2) to check for receipt of an RLM for a minimum period of 15 minutes at Moffset minutes, with 0 ≤ Moffset ≤ 59, past the hour until either an RLM message is received or 6 hours has elapsed since the beacon was activated or the beacon is deactivated; if UTC cannot be determined within 30 minutes after beacon activation the beacon shall attempt to obtain UTC using the timings detailed in section 4.5.5.4. If UTC is then determined the beacon shall continue as per c) and d) above from the next occurrence of UTC Moffset minutes; and once an RLM message is received, or after 6 hours has elapsed since beacon activation, whichever is sooner, the beacon shall revert to the GNSS timings in section 4.5.5.4. For instance, if the beacon is activated at 03.17h UTC, then the GNSS receiver would remain active until at least 03.47h UTC, or until an RLM message is acquired if sooner, or the beacon is deactivated, if it is deactivated before that time. If an RLM message is acquired within this period, then the beacon reverts to the GNSS timings in section 4.5.5.4. If an RLM message is not acquired, then it would re- activate at the next occurrence of Moffset past the hour and remain active until at least Moffset+15, or until an RLM message is acquired, or the beacon is deactivated and it would then reactivate again during the next hour at Moffset until Moffset+15, etc. The scheme continues as above until an RLM message is acquired, or 6 hours has elapsed since beacon activation, that is in this example until 09.17h UTC, at which time if an RLM wasn’t acquired earlier the GNSS Receiver reverts to the GNSS timings in section 4.5.5.4. If the beacon is deactivated then the entire operation cycle commences again from the beginning when the beacon is next activated. NOTE – The Galileo system will cease sending RLM messages back to the beacon, either once it receives an RLM Acknowledgement confirming that the RLM has been received by the beacon, or 6 hours have elapsed since the first RLS Request message from the beacon was received by the RLSP, whichever is the sooner.

There is no specific requirement to deactivate the GNSS receiver between position updates so the “next activation” may simply consist of ensuring that the GNSS receiver remains on at the start of this period. The GNSS receiver may have been previously activated due to a required GNSS position update and not as a result of the Moffset timing. † Note that in between Moffset activations the GNSS receiver must also comply with the requirements in section 4.5.5.4.

4-17

4.5.7.2.2 Derivation of Moffset The value of Moffset per each beacon is computed from the beacon 15 Hex ID, where the 19 bits containing the coarse position of the beacon are considered to be filled with default bits. More specifically: Moffset = BIN2DEC(CRC16(Beacon 15 Hex ID in Binary)) mod 60 Where BIN2DEC and CRC16 are functions performing the conversion of binary number to a decimal number and the CRC-16 of a stream of bits with polynomial x16+x15+x2+1 respectively. The CRC-16 is used to obtain a uniform distribution of Moffset. An example calculation of Moffset is shown in Figure B.3 in Annex B. 4.5.7.3 Indications of RLS and RLM The beacon shall provide distinct RLS Type 1 request and RLM indication designed to advise the user that: • a Type 1 RLS (or Type 1 RLS Test) request has been transmitted, and • the beacon has received a Type 1 Return Link Message (RLM Type 1) (or Test Return Link Message (Test RLM Type 1)) associated with this beacon. The RLS and RLM indications shall: be readily visible to the user when the beacon is operated in all its normal operational configurations as declared by the manufacturer; be clearly visible to the user in direct sunlight; provide distinct unique indication; remain inactive at all times when the beacon message is encoded with any protocol other than the RLS Location Protocol or RLS Location Test Protocol; within 5 seconds after the beacon encoded with the RLS Location Protocol or RLS Location Test Protocol transmits an initial RLS request , commence indication of an RLS request until either a valid RLM Type 1 or Test RLM message is received, or the beacon is deactivated, or the beacon battery is discharged; within 5 seconds of the beacon receiving a valid RLM Type 1 or Test RLM message, commence a distinct RLM indication until either the beacon is deactivated or the beacon battery is discharged; only provide the RLM indication when the beacon has received an RLM Type 1 or Test RLM message with the 15 Hex ID programmed into these messages that match this beacon 15 Hex ID; and if the RLS functionality is enabled, provide an indication during the self-test mode in accordance with section 4.5.4 e).

4-18

4.5.7.4 Confirmation of a Return-Link Message Receipt Upon receipt of an Acknowledgement Type-1 RLM or a Test RLM associated with the beacon 15 Hex ID, the beacon shall, within 1 minute, acknowledge the RLM receipt by changing the coding of bits 111 and 112 in its message as defined for the RLS Location Protocol in sectionA3.3.7.2. Once changed, bits 111 and 112 shall no longer be changed until the beacon is switched off or the beacon battery is depleted.* Once the beacon has received an Acknowledgement Type-1 RLM or a Test RLM and has acknowledged the RLM receipt, the GNSS Receiver shall continue to function as required by section 4.5.7.2.1 unless the beacon is coded as a "Type-1 only capable" RLS beacon as defined in section A.3.3.7.3. In this specific case only, the GNSS receiver may revert to operating as defined within Section 4.5.5.4, taking into account the time elapsed between the moment of activation and the moment when the Type-1 RLM message is received, until either the beacon is deactivated or the beacon performance ceases to meet specification due to battery depletion. Example: A beacon is activated at 9:00. It transmits emergency signals for 2 hours and 30 minutes. During the period from 11:00 to 11:15 it receives a Type-1 RLM Acknowledgement. The GNSS receiver could then revert to operating in accordance to the requirements for internal GNSS receiver without the RLS capability which specifies that, for the first 6 hours after beacon activation, the navigation device shall attempt location update at least once every 30 minutes. 4.5.7.5 RLS Beacon Documentation The operation of the RLS function shall be clearly explained in the User Manual including the performance characteristics of the overall RLS system. Suggested minimum text is provided in Annex D. Beacon Labelling and Marking All beacons shall have the following information indelibly marked on the exterior of the beacon: beacon model name, beacon manufacturers name, Cospas-Sarsat type approval certificate number (C/S TAC Number), beacon 15-Hex ID, Aircraft operator 3LD - for ELT(DT)s coded with a 3LD in PDF-2, beacon operating temperature range, minimum operating lifetime,

Transmission of RLMs associated with the beacon 15 HEX ID may be stopped by the RLSP upon a successful receipt of the confirmation of the RLM reception by the beacon.

4-19

for RLS-capable beacons:

wording on the Beacon Identity label (label with C/S TAC Number / 15-Hex ID) indicating whether the RLS function is enabled or disabled,
marking(s) to indicate which are the RLS and RLM indicator(s). Operator Controlled Voice Transceivers If an operator-controlled voice transceiver integrated with a beacon uses the same power source as the beacon, then there are additional considerations affecting the beacon operating lifetime: • the maximum cumulative duration of voice-transceiver transmission that does not reduce available power-source energy below the amount needed to operate the beacon for its declared minimum operating lifetime; and • transceiver operational features that mitigate the effects of unintentional transmissions by limiting the duration of each transmission to a certain maximum time (“time-out timer”). An operator-controlled voice transceiver that shares a power source with the beacon is assumed to be a transceiver used only in distress situations (similar to a 121.5-MHz homing signal sharing a beacon’s power source). Therefore, the voice transceiver shall not be capable of drawing power from the shared power source until after the beacon has been activated. The manufacturer shall specify a maximum cumulative voice-transceiver transmit-mode ‘on’ time that ensures that sufficient energy is available from the common (beacon/transceiver) power supply to allow the beacon to meet the manufacturer’s declared Minimum Operating Lifetime. The declared maximum cumulative transmit-mode ‘on’ time shall not be less than 10% of the declared Minimum Operating Lifetime for the beacon. The declared maximum cumulative transmit-mode ‘on’ time shall be clearly reflected in the beacon instruction manual, together with an explanation/warning to the user that voice-transceiver transmit operation exceeding the declared maximum cumulative transmit-mode ‘on’ time will reduce duration of operation of the activated 406- MHz beacon. An operator-controlled voice transceiver as described above should ideally include a means to prevent continuous transmission by the voice transceiver beyond a predetermined limit of time set by the beacon manufacturer’s design, once the Push-To-Talk (PTT) switch has been operated (“time-out” timer). If this feature is included in the design, continuous transmission by the voice transceiver shall not exceed 30 minutes. Releasing and reactivating the PTT switch should reset the “time-out timer” for this function. Operator controlled voice transceivers in beacons without the above “time-out timer” function shall be deemed to transmit continuously for the purposes of the operating lifetime at minimum temperature test.

4-20

ELT(DT)s Specifically Designed to Withstand a Crash Impact 4.5.10.1 Introduction Potentially there may be ELT(DT)s that have additional functionality, as defined by National Administrations and/or Aviation Authorities, which are designed to: 1) function both prior to a crash and after a crash, and withstand crash impact conditions; 2) be activated in-flight or by crash; 3) have homing and locating signals; and/or 4) have extended operating life. Crash Survivable ELT(DT)s should function as follows. If the beacon is activated in one aircraft state (e.g., In Flight) and the aircraft transitions to another state (e.g., On Ground) while the beacon is still activated, the beacon transmission characteristics should behave as indicated for the new aircraft state as per the table above. If there is a conflict between the requirements of this section and any other section of this document, then this section takes precedence. 4.5.10.2 Beacon Hex ID The Hex ID of the ELT(DT) shall not change from when activated in flight compared to when operating after a crash. 4.5.10.3 Burst Repetition Period (with Crash Detection) If the ELT(DT) includes a crash detection function, within 5 seconds of a crash the ELT(DT) shall initiate or restart the transmission schedule for an ELT(DT) as if the ELT(DT) had just been activated Activation Criteria Activation Means Manual Automatic Activation by the Beacon Avionics Trigger Unknown aircraft state 406 Distress Tracking (DT) sequence only preferred, homing permitted 406 FGB sequence and homing 406 DT sequence only On Ground 406 DT sequence and homing 406 Post Crash (PC) sequence and homing Disabled In Flight 406 DT sequence only preferred homing permitted 406 PC sequence and homing 406 DT sequence only

4-21

as defined in section 2.2.1 and maintain this transmission schedule for the first 95 bursts (approximately 30 minutes) after the crash detection. After burst number 95 (after crash detection), the ELT(DT) shall transmit bursts with a repetition period randomized with uniform (flat) distribution around a mean value of 120 seconds, so that the time intervals between the beginnings of two successive bursts (TR) are randomly distributed over the interval of 115 to 125 seconds. After burst number 95 (after crash detection), the standard deviation over the next 18 successive bursts of TR shall be greater than 2.5 seconds. The minimum value of TR observed over the 18 successive bursts shall be between 115.0 and 115.2 seconds, the maximum value of TR observed over the 18 successive bursts shall be between 124.8 and 125.0 seconds. For an ELT(DT) transmitting the 3LD in PDF-2, after burst number 95, after the crash detection, the 3LD is no longer required to be transmitted. Operation after 370 minutes without crash detection If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash mode or has not been deactivated, then it shall continue transmitting on the same schedule (with the GNSS encoded location updated before each transmitted burst) as before the 370-minute limit was reached until the ELT(DT) is either deactivated, gets a subsequent “crash” indication to transition to the “post- crash” mode, runs out of battery life or reaches the minimum duration of continuous operation, whichever occurs first. 4.5.10.4 GNSS Update Rate (after Crash Detection) During a 30-minute period after a crash detection, the GNSS encoded location shall be updated before each transmitted burst, as per section 4.5.5.6. Beyond 30 minutes, the GNSS encoded location shall be updated in accordance with section 4.5.5.4 and 4.5.5.5 (if applicable). The transmission in the beacon message of the external source of position is only subsequently allowed if the internal GNSS receiver is not able to produce a valid encoded position in accordance with section 4.5.5.4. If position data is available from both sources, before any subsequent burst, then the location produced by the internal GNSS receiver has priority over the external source of data. 4.5.10.5 Duration of Continuous Operation The minimum duration of continuous operation under worst case conditions for this type of ELT(DT) shall be at least 24 hours at any temperature throughout the specified operating temperature range. This is to be understood to mean the total operating time which is a combination of the time prior to a crash (minimum of 10 minutes and maximum of 370 minutes) and post-crash. For the avoidance of doubt, if the ELT(DT) continues to operate after 370 minutes without crash detection, then the 24-hour minimum duration of continuous operation does not apply and might be reduced as a result of the extended operation in this pre-crash mode.

4-22

4.5.10.6 Homing and Locating Signals The inclusion or otherwise of one or more homing signals in the ELT(DT) and the activation and duration of any homing signal transmissions are the responsibility of national administrations. ELT(DT)s Combined with Automatic ELTs 4.5.11.1 Introduction Potentially there may be ELT(DT)s that have combined functionality, that is they function as an ELT(DT) during a flight, but on detection of an incident perform as an Automatic ELT (either an ELT(AD), ELT(AF) or ELT(AP)), such a combined ELT would be required to meet the regulatory requirements set by National Administrations and/or Aviation Authorities, for both an ELT(DT) and the type of Automatic ELT that it is combined with. However, from a Cospas-Sarsat perspective there are certain key functions of such a combined ELT that need to be clearly defined related to its performance and operation and the transition from an ELT(DT) to either an ELT(AD), ELT(AF) or ELT(AP) as follows. ELT(DT)s combined with Automatic ELTs should function as follows. Activation Criteria Activation Means Manual Automatic Activation by the Beacon Avionics Trigger Unknown aircraft state 406 Distress Tracking (DT) sequence only preferred, homing permitted 406 FGB sequence and homing 406 DT sequence only On Ground 406 FGB sequence and homing 406 FGB sequence and homing Disabled In Flight 406 DT sequence only preferred, homing permitted 406 FGB sequence and homing 406 DT sequence only If the beacon is activated in one aircraft state (e.g., In Flight) and the aircraft transitions to another state (e.g., On Ground) while the beacon is still activated, the beacon transmission characteristics should behave as indicated for the new aircraft state as per the table above. If there is a conflict between the requirements of this section and any other section of this document, then this section takes precedence. 4.5.11.2 Beacon Coding and Beacon Hex ID The combined ELT(DT) and Automatic ELT shall be encoded with the ELT(DT) Location Protocol at all times. The Beacon Coding shall not change to another Protocol when operating as an Automatic ELT.

4-23

The 15-Hex ID shall remain the same regardless of whether the device is operating as an ELT(DT) or as an automatic ELT. Bits 107 and 108 in the ELT(DT) Location Protocol shall be used to indicate both the ELT(DT) and Automatic ELT means of activation. The most recent means of activation, whether by the ELT(DT) or the Automatic ELT shall be encoded and transmitted in the beacon message. 4.5.11.3 Burst Repetition Period When activated as an ELT(DT) the beacon shall meet the burst repetition requirements for an ELT(DT) as defined in section 2.2.1. When activated as an Automatic ELT or if transitioning from an ELT(DT) to an Automatic ELT then the combined device shall commence the burst repetition requirements for a non-ELT(DT) 406 MHz beacon as defined in section 2.2.1. For ELT(DT)s combined with an automatic ELT and transmitting the 3LD in PDF-2, the transmissions for the first five minutes after activation as an automatic ELT shall alternate between the encoded location and the 3LD in PDF-2, starting with the encoded location. Operation after 370 minutes without crash detection If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash mode or has not been deactivated, then it shall continue transmitting on the same schedule (with the GNSS encoded location updated before each transmitted burst) as before the 370-minute limit was reached until the ELT(DT) is either deactivated, gets a subsequent “crash” indication to transition to the “post- crash” (Automatic ELT) mode, runs out of battery life or reaches the minimum duration of continuous operation, whichever occurs first. 4.5.11.4 System Requirements The combined ELT(DT) and Automatic ELT shall meet the more stringent requirements that apply to either part of the device (except where stated otherwise below), for the operating temperature range (as per section 4.2.1) of the beacon under test. Specifically, the combined device shall: a) comply with the Digital Message Requirements for an ELT(DT) (section 2.2.4 b)); b) comply with the Medium-Term Frequency Stability Requirements for a non-ELT(DT) 406 MHz beacon (section 2.3.1); c) meet the Transmitter Power Output requirements for an ELT(DT) (section 2.3.2) while operating as an ELT(DT), when operating as an Automatic ELT or when transitioning from an ELT(DT) to an Automatic ELT then the Power Output requirement of the combined device may be relaxed to that of a non-ELT(DT) 406 MHz beacon (section 2.3.2); d) comply with the Modulation rise and fall times for an ELT(DT) (section 2.3.6); e) comply with both the Temperature Gradient requirements for an ELT(DT) and the Temperature Gradient requirements for a non-ELT(DT) 406 MHz beacon (section 4.2.2); and f) comply with both the Thermal Shock requirements for an ELT(DT) and the Thermal Shock requirements for a non-ELT(DT) 406 MHz beacon (section 4.2.3).

4-24

4.5.11.5 Cancellation Message The cancellation message shall function as it would for an ELT(DT) (as defined in section 3.3) while functioning as an Automatic ELT as well as while functioning as an ELT(DT). 4.5.11.6 Encoded Position Data and Navigation Device Performance While operating as an ELT(DT) the navigation device shall comply with the requirements of section 4.5.5.6. When operating as an Automatic ELT, that is automatically activated, the navigation device shall comply with the requirements of sections 4.5.5.3, 4.5.5.4 and 4.5.5.5 (if applicable). When operating as an Automatic ELT, that is manually activated, the navigation device shall comply with the requirements of section 4.5.5.6, for a period of at least 6 hours and 10 minutes, after which time the navigation device shall comply with the requirements of sections 4.5.5.3, 4.5.5.4 and 4.5.5.5 (if applicable). The transmission in the beacon message of position from an external source of navigation information is only subsequently allowed if the internal GNSS receiver is not able to produce a valid encoded position in accordance to the section 4.5.5.4. If position data is available from both sources, before any subsequent burst, then the location produced by the internal GNSS receiver has priority over the external source of data. 4.5.11.7 Duration of Continuous Operation The minimum duration of continuous operation under worst case conditions for this type of combined ELT shall be a combination of the minimum duration of continuous operation for an ELT(DT) (370 minutes) and the minimum duration of continuous operation for a non-ELT(DT) 406 MHz beacon (24 hours), thus resulting in a total of at least 30 hours and 10 minutes. For the avoidance of doubt, if the combined ELT continues to operate after 370 minutes without crash detection then the 30 hours and 10 minutes minimum duration of continuous operation does not apply, and might be reduced as a result of the extended operation in the ELT(DT) mode. 4.5.11.8 Class of Operation The combined device may, if required, function at different classes of temperature as an ELT(DT) or Automatic ELT (e.g., the ELT(DT) part of the device may be specified to operate as a Class 1 device, while the Automatic ELT part of the device may be specified to operate as a Class 2 device). 4.5.11.9 Homing and Locating Signals The inclusion or otherwise of one or more homing signals in the combined device and the activation and duration of any homing signal transmissions are the responsibility of national administrations.

4-25

External Power Source for ELT(DT)s The ELT(DT) shall have its own integral or internal power source. However, when available, all ELT(DT)s (including those in compliance with sections 4.5.10 and 4.5.11) may use the external aircraft electrical power source. An ELT(DT) shall comply with all applicable requirements regardless of power source. In addition, the ELT(DT) performance shall not be impacted by switching between power sources. – END OF SECTION 4 –

ANNEXES TO THE SPECIFICATION FOR COSPAS-SARSAT 406 MHz DISTRESS BEACONS

A-1

ANNEX A BEACON CODING A1 GENERAL A1.1 Summary This annex defines the 406 MHz beacon digital message coding. The digital message is divided into various bit fields as follows: Short Message Format (see Figure A1) Bit Field Name Bit Field Location

Bit synchronization bit 1 through bit 15
Frame synchronization bit 16 through bit 24
First protected data field (PDF-1) bit 25 through bit 85
First BCH error correcting field (BCH-1) bit 86 through bit 106
Non-protected data field bit 107 through bit 112 Long Message Format (see Figure A2) Bit Field Name Bit Field Location
Bit synchronization bit 1 through bit 15
Frame synchronization bit 16 through bit 24
First protected data field (PDF-1) bit 25 through bit 85
First BCH error correcting field (BCH-1) bit 86 through bit 106
Second protected data field (PDF-2) bit 107 through bit 132
Second BCH error correcting field (BCH-2) bit 133 through bit 144 The bit synchronization and frame synchronization fields are defined in sections 2.2.4.1 and 2.2.4.2, respectively. The first protected data field (PDF-1) and the non-protected data field of the short message are defined in section 3.1 and section A2 of this Annex, and shown in Figures A1, A3 and A4. The first protected data field (PDF-1) and the second protected data field (PDF-2) of the long message are defined in section 3.1 and section A3 of this Annex, and shown in Figures A2, A5, A6, A7, A8, A9, A10 and A11. The BCH error correcting fields BCH-1 and BCH-2 fields are defined in section 3.1 and the corresponding 21 bit BCH error-correcting code and 12 bit BCH error-correcting code are described at Annex B.

A-2

A1.2 Message Format Flag, Protocol Flag, and Country Code The bit allocations for the message format flag, protocol flag and country code are identical in all beacon protocols. They are assigned in PDF-1 of the short and the long messages as follows: Bits Usage

format flag (F)

protocol flag (P) 27-36 country code A1.2.1 Format Flag The format flag (bit 25) shows whether the message is short or long using the following code: F=0 short format F=1 long format A1.2.2 Protocol Flag The protocol flag (bit 26) indicates which type of protocol is used to define the structure of encoded data, according to the following code: P=0 standard location protocols or national location protocol P=1 user protocols or user-location protocols. The various protocols are identified by a specific protocol code, as described in section A1.3. A1.2.3 Country Code Bits 27-36 designate a three-digit decimal country code number expressed in binary notation. Country codes are based on the International Telecommunication Union (ITU) Maritime Identification Digit (MID) table available on the ITU website (http://www.itu.int/en/ITU- R/terrestrial/fmd/Pages/mid.aspx). National administrations which were allocated more than one MID code may opt to use only one of these codes. However, when the 6 trailing digits of a MMSI are used to form the unique beacon identification, the country code shall always correspond to the first 3 digits of the MMSI code. 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. Exceptionally when 98MIDXXXX is used in encoding EPIRB onboard craft associated with a parent ship in accordance with recommendation ITU-R M.585, 98M is filled into the country code field in binary notation and the trailing six digits IDXXXX are filled into bits 40-75 using the modified-Baudot code. For all types of protocols, except the test protocols, the country code designates the country of beacon registration, where additional information can be obtained from a database. But when 98MIDXXXX is used in encoding craft associated with a parent ship, country code 98M doesn’t designate the country of beacon registration, the 3rd, 4th and 5th digits MID provide this.

A-3

A1.3 Protocol Codes Each coding protocol is identified by a unique protocol code defined as follows:

3-bit code in bits 37 to 39 for user and user-location protocols;

4-bit code in bits 37 to 40 for standard location and national location protocols, RLS Location Protocol and ELT(DT) Location Protocol. Table A1 shows the combinations of the format flag and the protocol flag which identify each category of coding protocols. The protocol codes assignments are summarized in Table A2. Table A1: Format Flag and Protocol Flag Combinations Format Flag (bit 25) → Protocol Flag (bit 26) 

(short)

(long)

(protocol code: bits 37-40) Not Used Standard Location Protocols National Location Protocol RLS Location Protocols ELT(DT) Location Protocol

(protocol code: bits 37-39) User Protocols User Protocols (*) User-Location Protocols Figure A1: Data 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 Figure A2: Data 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

Only Orbitography and National User protocols (see section A2.7 and document C/S T.006, and section A2.8, respectively).

A-4

Table A2: Protocol Codes Assignments A2-A: User and User-Location Protocols (F=0, P=1) short message (F=1, P=1) long message Protocol Codes (Bits 37 - 39)

EPIRB - Maritime User Protocol: (MMSI, 6 digits)

(radio call sign, 6 characters)

EPIRB - Radio Call Sign User Protocol
ELT - Aviation User Protocol (aircraft registration markings)
Serial User Protocol:

bits 40, 41, 42 used to identify beacon type: 000 ELTs with serial identification number; 001 ELTs with aircraft operator designator & serial number; 010 float free EPIRBs with serial identification number; 100 non float free EPIRBs with serial identification number; 110 PLBs with serial identification number; 011 ELTs with aircraft 24-bit address; 101 & 111 spares. bit 43 = 0: serial identification number is assigned nationally; or bit 43 = 1: identification data include the C/S type approval certificate number. 5. Test User Protocol

Orbitography Protocol
National User Protocol*
Not to be used (allocated to Second Generation Beacons)

A2-B: Standard National, RLS and ELT(DT) Location Protocols (F=1, P=0) long message Protocol Codes (Bits 37 - 40) Standard Location Protocols

EPIRB - MMSI/Location Protocol
ELT - 24-bit Address/Location Protocol
Serial Location Protocols a) ELT - serial

b) ELT - aircraft operator designator

c) EPIRB-serial

d) PLB-serial

Ship Security
National Location Protocol a) ELT

b) EPIRB

c) PLB

The National User Protocol has certain bits which are nationally defined, as described in section A2.8.

A-5

Test location Protocols a) Standard Test Location Protocol

b) National Test Location Protocol

RLS Location Protocol
ELT(DT) Location Protocol
Spare 0000, 0001 A2 USER PROTOCOLS This section defines the user protocol message formats which can be used to encode the beacon identification and other data in the message transmitted by a 406 MHz distress beacon. A2.1 Structure of User Protocols The user protocols have the following structure: bits usage

format flag (short message=0, long message =1)

protocol flag (=1) 27-36 country code 37-39 protocol code 40-83 identification data 84-85 auxiliary radio-locating device type(s) Bits 37-39 in the protocol code field designate one of the user protocol codes as listed in Table A2-A, and indicate how the remaining bits of identification data are encoded/decoded. Bits 40-83 are used to encode the identification data of the beacon and, together with the protocol flag, the country code, the protocol code, and bits 84-85, shall form a unique identification for each beacon, i.e. the beacon 15 Hex ID. They will be discussed separately for each user protocol. Bits 84-85 are used to indicate for all user protocols excluding the orbitography protocol, the type of auxiliary radio-locating device(s) forming part of the particular beacon. The assignment of bits is as follows: bits 84-85 auxiliary radio-locating device type

no auxiliary radio-locating device

121.5 MHz

maritime 9 GHz Search and Rescue Radar Transponder (SART)

other auxiliary radio-locating device(s) 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. The bit assignments for user protocols, in PDF-1 of the 406 MHz beacon digital message, are summarized in Figure A3.

A-6

Figure A3: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols

MARITIME USER PROTOCOL Bits 25 26 27 36 37 39 40

.....

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

.....

Country Code

Radio Call Sign (42 bits)

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

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

.....

Country Code

Aircraft Registration Marking (42 bits) E N 1 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

39 40

...... F

Country Code

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

39 40

...... …

Country Code

As Defined in C/S T.018 (46 bits) Notes: RL

Auxiliary radio-locating device (see section A2.1) 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 section A2.4) *

Effective as of 1 November 2011.

A-7

Table A3: 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 EPIRB messages containing MMSI or radio call sign identification, and in ELTs containing the aircraft registration marking or the 3-letter aircraft operator designator. A2.2 Maritime User Protocol The maritime user protocol has the following structure: Bits Usage

format flag (=0)

protocol flag (=1) 27-36 country code 37-39 user protocol code (=010) 40-75 radio call sign or trailing 6 digits of MMSI 76-81 specific beacon number 82-83 spare (=00) 84-85 auxiliary radio-locating device type(s) Bits 40-75 designate the radio call sign or the last 6 digits of the 9 digit maritime mobile service identity (MMSI) using the modified-Baudot code shown in Table A3. This code enables 6 characters to be encoded using 36 bits (6x6 = 36). This data will be right justified with a modified-Baudot space (100100) being used where no character exists. If all characters are digits, the entry is interpreted as the trailing 6 digits of the MMSI. This coding method should be used only if the first 3 digits 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 or are 98M forming the first three digits of an MMSI in the form 98MIDXXXX for craft associated with a parent vessel.

A-8

Bits 76 to 81 are used to identify specific beacons on the same vessel (the first or only float free beacon shall 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). The maritime user and the radio call sign user protocols may be used for beacons that require coding with a radio call sign. The maritime user protocol may be used for radio call signs of 6 or fewer characters. Radio call signs of 7 characters must be encoded using the radio call sign user protocol. A2.3 Radio Call Sign User Protocol The radio call sign user protocol is intended to accommodate a vessel's radio call sign of up to seven characters, where letters may be used only in the first four characters, thereby complying with the ITU practice on formation of radio call signs. The radio call sign user protocol has the following structure: Bits Usage

format flag (=0)

protocol flag (=1) 27-36 country code 37-39 user protocol code (=110) 40-75 radio call sign 40-63 first 4 characters (modified-Baudot) 64-75 last 3 characters (binary-coded decimal) 76-81 specific beacon number 82-83 spare (=00) 84-85 auxiliary radio-locating device type(s) Bits 40 to 75 contain the radio call sign of up to 7 characters. Radio call signs of fewer than 7 characters should be left justified in the radio call sign field (bits 40-75) and padded with "space" (1010) characters in the binary-coded decimal field (bits 64-75). Bits 76 to 81 are used to identify specific beacons on the same vessel (the first or only float free beacon shall 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).

A-9

A2.4 Aviation User Protocol The aviation user protocol has the following structure: Bits Usage

format flag (=0)

protocol flag (=1) 27-36 country code 37-39 user protocol code (=001) 40-81 aircraft registration marking 82-83 specific ELT number  84-85 auxiliary radio-locating device type(s) Bits 40-81 designate the aircraft registration marking which is encoded using the modified-Baudot code shown in Table A3. This code enables 7 characters to be encoded using 42 bits (6x7=42). This data will be right justified with a modified-Baudot space (100100) being used where no character exists. Bits 82-83 are used to create a unique ELT identification when several ELTs coded with the Aviation User protocol are installed on the same aircraft. “00” indicates the first ELT on the aircraft coded with this protocol and “01”, “10” and “11” identify additional ELTs, all coded with the Aviation User protocol.* A2.5 Serial User Protocol The serial user protocol is intended to permit the manufacture of beacons whose 15 Hex ID will be identified in a data base giving specifics about the unit. The following types of serial identification data can be encoded in the beacon: • serial number • 24-bit aircraft address number • aircraft operator designator and a serial number. Bits 40-42 indicate the beacon type with serial identification data encoded, as follows: 000 indicates an aviation ELT serial number is encoded in bits 44-63 010 indicates a maritime float free EPIRB serial number is encoded in bits 44-63 100 indicates a maritime non float free EPIRB serial number is encoded in bits 44-63 110 indicates a personal locator beacon (PLB) serial number is encoded in bits 44-63

indicates the aircraft 24-bit address is encoded in bits 44-67 and specific ELT number in bits 68-73 if several ELTs, encoded with the same 24-bit address, are carried in the same aircraft

Effective as of 1 November 2011.

A-10

indicates an aircraft operator designator and a serial number are encoded in bits 44-61 and 62-73, respectively. Bit 43 is a flag bit to indicate that the Cospas-Sarsat type approval certificate number is encoded. If bit 43 is set to 1:

bits 64-73 should either be set to all 0s or allocated for national use and control (and will be made public when assigned by the responsible administration) or used as defined for coding the aircraft 24-bit address or aircraft operator designator;

bits 74-83 should be encoded with the Cospas-Sarsat type approval certificate number which is assigned by the Cospas-Sarsat Secretariat for each beacon model approved according to the type approval procedure of document C/S T.007. The certificate number is to be encoded in binary notation with the least significant bit on the right. If bit 43 is set to 0:

bits 64-83 are for national use and control (and will be made public when assigned by the responsible administration) or used as defined for coding the aircraft 24-bit address or aircraft operator designator. Details of each type of serial identification data are given hereunder. A2.5.1 Serial Number The serial user protocol using a serial number encoded in the beacon message has the following structure: Bits 25 26 27 36 37 40 44 63 64 73 74 83 85 ---+--+--+------------+-----+-----+-+-----------------+-------------+-------------+---+- ¦ ¦ ¦ Country ¦ ¦ ¦ ¦ (20 bits) ¦ All "0" or ¦ C/S cert. No. ¦ ¦0 ¦1 ¦ Code ¦0 1 1¦T T T¦C¦ Serial Number ¦ Nat. Use ¦ or Nat. Use ¦R L¦

Bits Usage

format flag (= 0)

protocol flag (=1) 27-36 country code 37-39 user protocol code (=011) 40-42 beacon type (=000, 010, 100 or 110)

flag bit for Cospas-Sarsat type approval certificate number 44-63 serial number 64-73 all 0s or national use 74-83 C/S type approval certificate number or national use 84-85 auxiliary radio-locating device type(s) Bits 44-63 designate a serial identification code number ranging from 0 to 1,048,575 (i.e., 220-1) expressed in binary notation, with the least significant bit on the right.

A-11

This serial number encoded in the beacon message is not necessarily the same as the production serial number of the beacon. A2.5.2 Aircraft 24-bit Address The serial user protocol using the aircraft 24-bit address has the following structure: Bits 25 26 27 36 37 40 44 67 68 73 74 83 85 ---+--+--+------------+-----+-----+-+-----------------+-------------+-------------+---+- ¦ ¦ ¦ Country ¦ ¦ ¦ ¦ Aircraft ¦ Additional ¦ C/S Cert.No.¦ ¦ ¦0 ¦1 ¦ Code ¦0 1 1¦0 1 1¦C¦ 24-bit Address ¦ ELT No.s ¦ or Nat. Use ¦R L¦

Bits Usage

format flag (= 0)

protocol flag (=1) 27-36 country code 37-39 user protocol code (=011) 40-42 beacon type (=011)

flag bit for Cospas-Sarsat type approval certificate number 44-67 aircraft 24-bit address 68-73 specific ELT number, if several ELTs encoded with the same 24-bit address are carried in the same aircraft 74-83 C/S type approval certificate number or national use 84-85 auxiliary radio-locating device type(s) Bits 44-67 are a 24-bit binary number assigned to the aircraft. Bits 68-73 contain the 6-bit specific ELT number, in binary notation with the least significant bit on the right, which is an order number of the ELT in the aircraft, where “000000” indicates the first ELT on the aircraft coded with this protocol and “000001”, “000010”, “000011”, etc., identify additional ELTs, all coded with the Aircraft 24-bit Address User protocol. The purpose of this specific number is to produce different 15 Hex numbers containing the same 24-bit address. A2.5.3 Aircraft Operator Designator and Serial Number The serial user protocol using the aircraft operator designator and serial number has the following structure: Bits 25 26 27 36 37 40 44 61 62 73 74 83 85 ---+--+--+------------+-----+-----+-+-------------------+-----------+-------------+---+- ¦ ¦ ¦ Country ¦ ¦ ¦ ¦ Operator 3-letter ¦ Serial ¦ C/S Cert. No. ¦ ¦0 ¦1 ¦ Code ¦0 1 1¦0 0 1¦C¦ Designator ¦ Number ¦ or Nat. Use ¦R L¦

Bits Usage

format flag (=0) 27-36 country code 37-39 user protocol code (=011) 40-42 beacon type (=001)

flag bit for Cospas-Sarsat type approval certificate number 44-61 aircraft operator designator

A-12

62-73 serial number assigned by operator 74-83 C/S type approval certificate number or national use 84-85 auxiliary radio-locating device type(s) Bits 44-61 are 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). The 3 letters are encoded using the modified-Baudot code of Table A3. Bits 62 to 73 are a serial number (in the range of 1 up to 4095) as designated by the aircraft operator, encoded in binary notation, with the least significant bit on the right. A2.6 Test User Protocol The test user protocol will be used for demonstrations, type approval, national tests, training exercises, etc. Mission Control Centres (MCCs) will not forward messages coded with this protocol unless requested by the authority conducting the test. The test user protocol has the following structure: Bits Usage

format flag (short message = 0, long message = 1)

protocol flag (=1) 27-36 country code 37-39 test user protocol code (=111) 40-85 national use A2.7 Orbitography Protocol The orbitography protocol is for use by special system calibration transmitters and is intended for use only by operators of the Local User Terminals. Therefore, it is not further described in this document. A2.8 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 coded into the country code field.

The list of designators, comprising about 3000 operating agencies, authorities or services world-wide, is published by ICAO in document 8585, and can be purchased from ICAO in printed and electronic form.

A-13

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 has the following structure: Bits 25 26 27 36¦37 ¦40 85 86 106 107 132¦133 144¦ ---+--+--+----------+-----+---------------------------+-------------+-------------¦--------¦ ¦ ¦ ¦ Country ¦ ¦ National Use ¦ BCH Code ¦National Use BCH Code¦ ¦F ¦1 ¦ Code ¦1 0 0¦ (46 bits) ¦ (21 bits) ¦ (26 bits) ¦(12 bits) ---------------------------------------------------------------------------------¦--------¦ Bits Usage

format flag (short message =0, long message =1)

protocol flag (=1) 27-36 country code 37-39 national user protocol code (=100) 40-85 national use 86-106 21-bit BCH code 107-112 national use 113-132 national use (if long message) 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 recomputed and that such changes do not occur more frequently than once every 20 minutes. It should be noted that distress alert messages encoded with the national user protocol can be passed within the Cospas-Sarsat System only as hexadecimal data, and the content of the message can only be interpreted by the appropriate national administration. A2.9 Non-Protected Data Field The non-protected data field consists of bits 107 to 112, which can be encoded with emergency code / national use data as described below. However, when neither the emergency code nor the national use data have been implemented, nor such data entered, the following default coding should be used for bits 107 to 112: 000000: for beacons that can be activated only manually, i.e. bit 108 = 0 (see below) 010000: for beacons that can be activated both manually and automatically, i.e., bit 108 = 1 (see below). Bit 107 is a flag bit that should be automatically set to (=1) if emergency code data has been entered in bits 109 to 112, as defined below.

A-14

Bit 108 indicates the method of activation (the switching mechanism) that has been built into the beacon: bit 108 set to (=0) indicates that a switch must be manually set to “on” after the time of the distress to activate the beacon; bit 108 set to (=1) indicates that the beacon can be activated either manually or automatically. A float-free beacon shall have bit 108 set to 1. A2.9.1 Maritime Emergency code The emergency code is an optional feature that may be incorporated in a beacon to permit the user to enter data in the emergency code field (bits 109-112) after beacon activation of any maritime protocol (i.e. maritime user protocol, maritime serial user protocols, and radio call sign user protocol). If data is entered in bits 109 to 112 after activation, then bit 107 should be automatically set to (=1) and bits 109 to 112 should be set to an appropriate maritime emergency code shown in Table A4. If a beacon is pre-programmed, bits 109 to 112 should be coded as "unspecified distress" (i.e. 0000). A2.9.2 Non-Maritime Emergency code The emergency code is an optional feature that may be incorporated in a beacon to permit the user to enter data in the emergency code field (bits 109-112) of any non-maritime protocol (i.e. aviation user protocol, serial user aviation and personal protocols, or other spare protocols). If data is entered in bits 109 to 112, then bit 107 should be automatically set to (=1) and bits 109 to 112 should be set to an appropriate non-maritime emergency code shown in Table A5.

A-15

Table A4: Maritime Emergency Codes in Accordance with the Modified (1) IMO Nature of Distress Indication IMO Indication(2 ) Binary Code Usage

1001 to 1111 Fire/explosion Flooding Collision Grounding Listing, in danger of capsizing Sinking Disabled and adrift Unspecified distress (3) Abandoning ship Spare (could be used in future for assistance desired or other information to facilitate the rescue if necessary) (1) Modification applies only to code "1111", which is used as a "spare" instead of as the "test" code. (2) IMO indication is an emergency code number, it is different from the binary encoded number. (3) If no emergency code data has been entered, bit 107 remains set to (=0). Table A5: Non-Maritime Emergency Codes Bits Usage (1)

No fire (=0); fire (=1) No medical help (=0); medical help required (=1) Not disabled (=0); disabled (=1) Spare (=0) (1) If no emergency code data has been entered, bit 107 remains set to (=0). A2.9.3 National Use When bit 107 is set to (=0), codes (0001) through (1111) for bits 109 to 112 may be used for national use and should be set in accordance with the protocol of an appropriate national authority.

A-16

Figure A4: Summary of User Protocols Coding Options b 25: Message format flag: 0 = short message, 1 = long message b 26: Protocol flag: 1 = User protocols b 27 - b 36: Country code number: 3 digits, as listed in Appendix 43 of the ITU Radio Regulations b 37 - b 39: User protocol code: 000 = Orbitography 110 = Radio call sign 001 = Aviation 111 = Test 010 = Maritime 100 = National 011 = Serial 101 = Spare b 37 - b 39: 010 = Maritime user 110 = Radio call sign user 011 = Serial user 001 = Aviation user 100 = National User b 40 - b 75: Trailing 6 digits of MMSI or radio call sign (modified- Baudot) b 40 - b 63: First four characters (modified-Baudot) b 40 - 42: Beacon type 000 = Aviation 001 = Aircraft Operator 011 = Aircraft Address 010 = Maritime (float free) 100 = Maritime (non float free) 110 = Personal b 40 - b 81: Aircraft Registration Marking (modified - Baudot) b 40 - 85: National use b 43: C/S Certificate flag b 64 - b 75: Last three characters (binary coded decimal) b 44 - b 73: Serial No. and other data b 76 - b 81: Specific beacon (modified-Baudot) b 76 - b 81: Specific beacon (modified-Baudot) b 74 - b 83: C/S Cert. No. or National use b 82 - b 83: 00 = Spare b 82 - b 83: 00 = Spare b 82 - b 83: Specific ELT number* b 84 - 85: Auxiliary radio-locating device type(s): 00 = No Auxiliary radio-locating device 01 = 121.5 MHz 10 = Maritime locating: 9 GHz SART 11 = Other auxiliary radio-locating device(s) b 86 - b 106: BCH code: 21-bit error-correcting code for bits 25 to 85 b 107: Emergency code use of b 109 - b 112: 0 = National use, undefined (default = 0) 1 = Emergency code flag b 107 - 112: National use b 108: Activation type: 0 = Manual activation only 1 = Automatic and manual activation b 109 - b 112: Nature of distress: Maritime emergency codes (see Table A.4) (default = 0000) Non-maritime emergency codes (see Table A5) (default = 0000)

Effective as of 1 November 2011.

A-17

A3 LOCATION PROTOCOLS This section defines the protocols which can be used with the 406 MHz beacon message formats for encoding beacon position data, as well as the beacon identification data, in the digital message transmitted by a 406 MHz distress beacon. A3.1 Summary Five types of location protocols are defined for use with the long message*, as shown in Figure A5. User-Location Protocols. These location protocols are for use with the long message format. The beacon identification data is provided in PDF-1 by one of the user protocols defined in section A2 (see Figure A3). Position data is provided as latitude and longitude, to 4-minute resolution, encoded into PDF-2. Standard Location Protocols. These location protocols are for use with the long message format. The beacon identification data is provided in a standardized format in 24 bits of PDF-1. Position data to 15-minute resolution is also given in PDF-1, with position offsets to 4-second resolution in PDF-2. National Location Protocol. This location protocol is for use with the long message format. The beacon identification data is provided in a nationally-defined format in 18 bits of PDF-1. Position data, to 2-minute resolution, is given in PDF-1, with position offsets to 4-second resolution in PDF-2. Return Link Service (RLS) Location Protocol†. This location protocol is for use with the long message format. The beacon identification data is provided in 26 bits of PDF-1 where the first two bits define the beacon type and the remaining 24 bits define the RLS truncated TAC number and serial number. Position data, to 30-minute resolution, is given in PDF-1, with position offsets to 4-second resolution in PDF-2. PDF-2 also contains six supplementary data bits which contain RLS data. ELT(DT) Location Protocol‡. This location protocol is for use with the long message format. The beacon identification data is provided in 26 bits of PDF-1 where the first two bits define the type of beacon identity and the remaining 24 bits provide that identity. Position data to 30-minute resolution is also given in PDF-1, with position offsets to 4-second resolution in PDF-2. PDF-2 also contains six supplementary data bits which contain altitude and other ELT(DT) data. * Cospas-Sarsat no longer permits the use of short format location protocols. Information on these protocols is available in C/S T.001, Issue 3- Revision 7. † By decision of the Cospas-Sarsat Council at its Fifty-Seventh Session, this protocol will be effective as of 1 January 2018, as a target, subject to further review and consideration. ‡ By decision of the Cospas-Sarsat Council at its Fifty-Seventh Session, this protocol will be effective as of 1 January 2018, as a target, subject to further review and consideration.

A-18

A3.2 Default Values in Position Data The following default values shall be used in all encoded position data fields of the location protocols, when no valid data is available: a) all bits in degrees fields set to "1", with N/S, E/W flags set to "0"; b) all bits in the minutes fields set to "0", with  signs set to "1"; and c) all bits in the seconds fields set to "1" (the value "1111" = 60 sec is out of range). This pattern shall also be transmitted if the beacon radiates a 406 MHz message in the self-test mode. Additionally, if a location protocol beacon includes an optional GNSS self-test and this fails to provide a valid location to encode into the transmitted self-test message, then the beacon may radiate a single self-test message with the above default data. However if a location protocol beacon with optional GNSS self-test obtains a location, then the beacon may radiate a single self-test message with encoded position. Figure A5: 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 Posit. 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

A-19

A3.3 Definition of Location Protocols The general structure of location protocols is illustrated in Figure A6. A3.3.1 Position Data* 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. All rounding shall follow normal rounding conventions, for example with a resolution of 4, 0.000 to 1.999 shall be rounded down to 0 and 2.000 to 3.999 shall be rounded up to 4. In each location field the Most Significant Bit (MSB) is the lowest numbered bit in the message which is not a N/S, E/W or Δ sign flag bit. For User Location Protocols, the position encoded in PDF-2 shall be as close as possible to the actual position. For Standard Location, National Location, RLS Location, and ELT(DT) Location Protocols the position is encoded as follows. The coarse position encoded in PDF-1 is selected to be as close as possible to the actual position. The actual position is then rounded following the above rules to the nearest 4 seconds. The offset to be encoded in PDF-2 is then calculated by subtracting the coarse position encoded in PDF-1 from the rounded position, ensuring that the sign of the offset is included in PDF-2†. If there is no offset in either latitude or longitude (or both) in PDF-2 (i.e. the offset minutes and seconds are all zeroes) then the appropriate offset data flag shall be set to its default value (i.e., 1). When a position is encoded in PDF-1, the higher resolution information given in PDF-2 is an offset ( latitude and  longitude) relative to position provided in PDF-1. The latitude and longitude values contained in 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). A3.3.2 Supplementary Data The following supplementary data are provided in location protocols, in addition to the required identification data and available position data.

Beacons submitted for type approval testing prior to 1 November 2010 may at manufacturers choice use the location protocol coding system defined in A3.3.1 or the previous system as defined in section A3.3.1 of document C/S T.001, Issue 3 - Revision 8. Manufacturers who choose to use the location encoding system defined in A3.3.1 may use the answer sheets in C/S T.007, Issue 3 - Revision 9. Manufacturers who submit for type approval testing after 1 November 2010 must use the answer sheets in C/S T.007, Issue 3 - Revision 10. † Note that the encoded location in PDF-1 will be closest to the actual, but in some cases may not be the closest location to the rounded location.

A-20

A3.3.2.1 Source of Position Data This information is encoded in bit 107 for the user-location protocol and RLS location protocol or bit 111 for the standard and national location protocols with the following interpretation: "0" = the encoded position data is provided by an external navigation device "1" = the encoded position data is provided by an internal navigation device A3.3.2.2 Auxiliary Radio Locating Device (homing transmitter) Code The "121.5 MHz homing" data is encoded in bit 112 for the standard and national location protocols (short and long versions) and in bit 108 for the RLS location protocol where: "1" = indicates a 121.5 MHz auxiliary radio locating device "0" = indicates other or no auxiliary radio locating devices; and in bits 84-85 for the user-location protocols as follows: "00" = no auxiliary radio locating device "01" = 121.5 MHz auxiliary radio locating device "10" = maritime locating: 9 GHz Search and Rescue Radar Transponder (SART) "11" = other auxiliary radio-locating device(s). A3.3.2.3 ELT(DT) Activation mechanism This information is encoded in bits 107 and 108 for the ELT(DT) Location Protocol as defined in section A3.3.8.3. A3.3.2.4 ELT(DT) Altitude above sea level This information is encoded in bits 109 to 112 for the ELT(DT) Location Protocol as defined in section A3.3.8.3. A3.3.2.5 ELT(DT) Encoded Location Status and PDF-2 rotating field indicator This information is encoded in bits 113 and 114 for the ELT(DT) Location Protocol with the following interpretation: • “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).

A-21

A3.3.2.6 RLS Data Bits 109 and 110 Return Link Message (RLM) Request Bits 111 and 112 Beacon Feedback (on receipt of RLM) Bits 113 and 114 Return Link Service (RLS) Provider A3.3.3 Test Location Protocols The test protocol for all coding methods (i.e. "user" and "location" protocols, except for the ELT(DT) and RLS location 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"). The ELT(DT) and RLS location protocols both have their own test protocols build into their protocol.

A-22

Figure A6: General Format of Long Message for Location Protocols 1 24→

27 36→ 37 39 → 40 41 83→

86 106→ 107 112 → 113 132→ 133 144→ ----------- 61 BITS ----------→ PDF-1 BCH-1 ------ 26 BITS ------→ PDF-2 BCH-2

F O R M A T C O U N T R Y C O D E

USER-LOCATION PROTOCOLS (P=1) Identification Data (same as User Protocols) See Figure A7

USER-LOCATION PROTOCOLS Latitude / Longitude Data (4 Minute Resolution) See Figure A7 BIT & FRAME SYNCHRONIZAT. PATTERNS & P R O T O C O L F L A G S

STANDARD LOCATION PROTOCOLS (P=0) Identification & Position Data (1/4 Degree Resolution) See Figure A8 21-BIT BCH ERROR CORRECTING CODE STANDARD LOCATION PROTOCOLS  Latitude /  Longitude (4 Second Resolution)

Supplementary Data See Figure A8 12-BIT BCH ERROR CORRECTING CODE

NATIONAL LOCATION PROTOCOLS (P=0) Identification & Position Data (2 Minute Resolution) See Figure A9 NATIONAL LOCATION PROTOCOLS  Latitude /  Longitude (4 Second Resolution)

Supplementary Data See Figure A9

RLS LOCATION PROTOCOLS (P=0) Identification & Position Data (30 Minute Resolution) See Figure A10 RLS LOCATION PROTOCOLS  Latitude /  Longitude (4 Second Resolution)

Supplementary Data See Figure A10

ELT(DT) LOCATION PROTOCOL (P=0) Identification & Position Data (30 Minute Resolution) See Figure A11 ELT(DT) LOCATION PROTOCOL  Latitude /  Longitude (4 Second Resolution)

Supplementary Data or Aircraft Operator 3LD See Figure A11   F= 1 PROTOCOL CODE LONG MESSAGE FORMAT - 144 BITS→ P= 0 or 1 See Table A2

A-23

A3.3.4 User-Location Protocols (See Figure A7) A3.3.4.1 These protocols (identified by F=1, P=1) provide for encoding latitude / longitude data with resolution to 4 minutes in PDF-2. Beacon identification data shall be encoded in PDF-1 using any of the user protocols defined in section 2, except the orbitography protocol and the national user protocol which are specific to a particular application or a particular country. A3.3.4.2 The protocol codes (bits 37 to 39) are defined in Table A2-A for user and user-location protocols. A3.3.4.3 The 26 bits available in PDF-2 are defined as follows: bit 107: encoded position data source "0" = the encoded position data is provided by an external navigation device "1" = 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

minute increments (default value of bits 108 to 119 = 0 1111111 0000); and 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

minute increments (default value of bits 120 to 132 = 0 11111111 0000).

A-24

Figure A7: User-Location Protocol 1 24→

27 36→ 37 | |40 85→ 39→| 83→| 86 106→ 107 112→ 113 132→ 133 144→ ------ 61 BITS -----→ PDF-1 BCH-1 ------ 26 BITS -----→ PDF-2 BCH-2

F O R M A T C O U N T R Y P R O T O C O IDENTIFICATION DATA POSITION DATA (ALL USER-LOCATION PROTOCOLS) BIT & FRAME SYNCHRONIZ. PATTERNS & P R C O D E L C O D MARITIME USER PROTOCOL (MMSI OR RADIO CALL SIGN) (PC=010) 21-BIT BCH ERROR CORRECTING CODE

LATITUDE LONGITUDE 12-BIT BCH ERROR CORRECTING CODE O T O C E (PC) RADIO CALL SIGN USER PROTOCOL (PC=110)

O L F AIRCRAFT NATIONALITY AND REGISTRATION MARKINGS (PC=001) N / S DEG 0 - 90 (1 deg.) MIN 0 - 56 (4min) E / W DEG 0 - 180 (1 deg.) MIN 0 - 56 (4min) L A G S SERIAL USER PROTOCOL (ELTs, PLBs, EPIRBs) (PC=011) TEST USER PROTOCOL (PC=111)     84,85 = Homing  107 = Encoded Position Data source: 1= Internal, 0 = external F=1 See See Figure A3 for details (except for the Test User Protocol – see section A2.6) P=1 Table A2 of identification data

A-25

A3.3.5 Standard Location Protocols (see Figure A8) A3.3.5.1 The standard location protocols, identified by the flags F=1, P=0 and the protocol codes no. 1 to 4 of Table A2-B, have the following structure: a) PDF-1: bits 37 to 40: 4-bit protocol code as defined in Table A2-B bits 41 to 64: 24 bits of identification data bits 65 to 85: 21 bits of encoded position data to 15 minute resolution; b) PDF-2: bits 107 to 112: 4 fixed bits and 2 bits of supplementary data bits 113 to 132 20-bit position offset ( latitude,  longitude), to 4 second resolution. A3.3.5.2 The 24 bits of identification data (bits 41 to 64) can be used to encode: a) (PC=0010) the last six digits of MMSI in binary form in bits 41 to 60 (20 bits), plus a 4-bit specific beacon number (0 to 15) in bits 61 to 64, to distinguish between several EPIRBs on the same ship; b) (PC=0011) a 24-bit aircraft address (only one ELT per aircraft can be identified using this protocol); or c) (PC=01xx, see Note 1) a 24-bit unique serial identification including: (i) the 10-bit Cospas-Sarsat type approval certificate number of the beacon (1 to 1,023) in bits 41 to 50, and a 14 bit serial number (1 to 16,383) in bits 51 to 64; or (ii) a 15-bit aircraft operator designator (see Notes 1 & 2) in bits 41 to 55, and a 9-bit serial number (1 to 511) assigned by the operator in bits 56 to 64. d) (PC=1100) the last six digits of MMSI in binary form in bits 41 to 60 (20 bits), plus four spare fixed bits, 61 to 64, set to “0000”.

Notes: 1. The last two bits of the protocol code (bits 39-40) are used as follows (see also Table A2): 00 ELT-serial 10 EPIRB-serial 01 ELT-aircraft operator designator 11 PLB-serial 2. The aircraft operator designator (3 letters) can be encoded in 15 bits using a shortened form of the modified-Baudot code (i.e.: all letters in the modified-Baudot code are coded in 6 bits, with the first bit = "1". This first bit can, therefore, be deleted to form a 5-bit code)

A-26

A3.3.5.3 The 21 bits of position data in PDF-1 are encoded as follows: a) bits 65 to 74: latitude data (10 bits) providing 15 minute resolution, including: • bit 65: N/S flag (N=0, S=1) • bits 66 to 74: degrees (0 to 90) in 1/4 degree increments (default value of bits 65 to 74 = 0 111111111); and b) bits 75 to 85: longitude data (11 bits) providing 15 minute resolution, including: • bit 75: E/W flag (E=0, W=1) • bits 76 to 85: degrees (0 to 180) in 1/4 degree increments (default value of bits 75 to 85 = 0 1111111111). A3.3.5.4 The 26 bits available in PDF-2 are defined as follows: a) bits 107 to 109: ="110" (fixed); b) bit 110: ="1" (fixed); c) bit 111: encoded position data source "0" = the encoded position data is provided by an external navigation device "1" = the encoded position data is provided by an internal navigation device; d) bit 112: 121.5 MHz auxiliary radio locating device included in beacon (1 = yes, 0 = no); 121.5 MHz auxiliary radio locating devices are not authorised for beacons coded with the ship security format (i.e. when bits 37 – 40 = 1100); e) bits 113 to 122:  latitude with 4 second resolution: • 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); and f) bits 123 to 132:  longitude with 4 second resolution: • 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). A3.3.5.5 The test protocol using the above format is encoded by setting bits 37-39 to "111" and bit 40 to "0".

A3.3.5 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”.

A-27

Figure A8: Standard Location Protocols 1 24→

27 36→ 37 40→|41 85→ | 86 106→

113 132→ 133 144→ ----------- 61 BITS ------------→ PDF-1 BCH-1 ------- 26 BITS --------→ PDF-2 BCH-2

F O R PC 24 BITS IDENTIFICATION DATA 21 BITS LATITUDE LONGITUDE S U P  LATITUDE  LONGITUDE M A C O

P L

T & U N T 00 10 MMSI (last 6 digits, binary) B.No 0 -15 LAT LON E M E M I S E M I S E BIT & FRAME SYNCHRONIZ PATTERNS P R R Y

AIRCRAFT 24 BIT ADDRESS N DEG E DEG 21-BIT BCH ERROR CORRECTING CODE N T A R

N U T E C O N D

N U T E C O N D 12-BIT BCH ERROR CORRECTING CODE O T C O

S 0 - 90 W 0 - 180 Y S S S S O C O D E 01 01 AIRCRAFT OPER. DESIGNATOR SERIAL No 1 - 511 D A 0 - 30 0-56 0-30 0-56 L

(1/4 d.) (1/4 d.) T A (1min) (4s) (1min) (4s) F L A G 01 10

C/S TA No 1 – 1023 SERIAL No 1 - 16383

11 00 MMSI (last 6 digits, binary) Fixed

  107 = “1” F=1 0100 ELT-Serial  108 = “1” P=0 0110 EPIRB-Serial  109 = “0” 0111 PLB  110 = “1”  111 = Encoded Position Data Source: 1= int., 0 = ext. 1110 Test  112 = 121.5 MHz Homing: 1=Yes, 0 = No

A-28

A3.3.6 National Location Protocol (see Figure A9) A3.3.6.1 The national location protocol, identified by the flags F=1, P=0 and the protocol codes in series no. 4 of Table A2-B, has the following structure: a) PDF-1: bits 37 to 40: 4-bit protocol code as defined in Table A2-B, bits 41 to 58: 18-bit identification data consisting of a serial number assigned by the appropriate national authority, bits 59 to 85: 27 bits of position data to 2 minute resolution; b) PDF-2: bits 107 to 112: 3 fixed bits set to "110", 1-bit additional data flag, describing the use of bits 113 to 132, and 2 bits of supplementary data, bits 113 to 126: 14-bit position offset ( latitude,  longitude) to 4 second resolution, or alternate national use, and bits 127 to 132: 6 bits reserved for national use (additional beacon type identification or other). A3.3.6.2 The 27 bits of position data in PDF-1 are encoded as follows: a) bits 59 to 71: latitude data (13 bits) with 2 minute resolution: • 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); and b) bits 72 to 85: longitude data (14 bits) with 2 minute resolution: • 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).

A-29

A3.3.6.3 The 38 bits available in PDF-2 are defined as follows: a) bit 107 to 109: ="110" (fixed); b) bit 110: additional data flag (1 =  position data as described below in bits 113 to 132; 0 = other to be defined nationally); c) bits 111: encoded position data source "0" = the encoded position data is provided by an external navigation device "1" = the encoded position data is provided by an internal navigation device; d) bit 112: 121.5 MHz auxiliary radio locating device included in beacon (1 = yes, 0 = no); e) bits 113 to 119: if bit 110 = 1,  latitude with 4 second resolution: • 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 113 to 119: if bit 110 = 0, national use; f) bits 120 to 126: if bit 110 = 1,  longitude with 4 second resolution: • 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 120 to 126: if bit 110 = 0, national use; and g) bits 127 to 132: Additional beacon identification (national use) (default value of bits 127 to 132 = 000000). A3.3.6.4 The test protocol using the above format is encoded by setting bits 37-39 to "111" and bit 40 to "1".

A3.3.6 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”.

A-30

Figure A9: National Location Protocol 1 24→

27 36→ 37 40→|41 85→ | 86 106→

113 132→ 133 144→ ------ 61 BITS -----→ PDF-1 BCH-1 ------ 26 BITS -----→ PDF-2 BCH-2

F O R M 18 BITS IDENTI- FICATION 27 BITS LATITUDE LONGITUDE S U P  LATITUDE  LONGITUDE A T C O P R

P L

N A BIT & FRAME SYNCHRONIZ. PATTERNS & P R O T O C O L F L A G U N T R Y C O D E O T O C O L C O D E NATIONAL ID NUMBER N S D E G R E E S 0 - 90 (1 deg) M I N U T E S 0 - 58 (2 m) E W D E G R E E S 0 - 180 (1 deg) M I N U T E S 0 - 58 (2m) 21-BIT BCH ERROR CORRECTING CODE E M E N T A R Y D A T A

M I N U T E S 0 - 3 (1m) S E C O N D S 0 - 56 (4 s.)

M I N U T E S 0 - 3 (1m) S E C O N D S 0 - 56 (4 s.) T I O N A L U S E 12-BIT BCH ERROR CORRECTING CODE    107 = “1” F=1 See  108 = “1” P=0 Table A2  109 = “0” 1000 ELT  110 = Additional Data Flag: 1 =  Position, 0 = Nat. Assignment 1010 EPIRB  111 = Encoded Position Data Source: 1 = Internal, 0 = external 1011 PLB  112 = 121.5 MHz Homing: 1= Yes, 0 = No 1111 Test

A-31

A3.3.7 RLS Location Protocol (see Figure A10) A3.3.7.1 The RLS location protocol, identified by the flags F=1, P=0 and the protocol code in series no. 7 of Table A2-B, has the following structure: a) PDF-1: bits 37 to 40: 4-bit protocol code defined as 1101, bits 41 to 42: 2-bit beacon type data set to “00” for ELT, “01” for EPIRB, “10” for PLB, and “11” for Location 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 46: Set to “1111” indicate that this is an RLS Location Protocol coded with an MMSI, and bits 41 to 42 and bits 47 to 66 have a different use as defined above and below bits 43 to 46: Set to any combination of bits other than “1111” indicate that the RLS Location Protocol is coded with either a TAC or National RLS and Serial Number bits 43 to 52: 10 bit truncated*†‡ C/S RLS TAC number or National RLS Number except when bits 43 to 46 are set to “1111”,

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.

A-32

bits 53 to 66: 14-bit identification data consisting of a production serial number (1 to 16,383) assigned by the manufacturer associated with a C/S RLS TAC number (001 to 919), except when bits 43 to 46 are set to “1111”, or bits 53 to 66: 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† bits 67 to 85: 19 bits of position data to 30 minute resolution; b) PDF-2: bits 107 & 108: 2 bits of supplementary data bits 109 to 114: 6 bits reserved for RLS Data. bits 115 to 132: 18-bit position offset ( latitude,  longitude) to 4 second resolution. The 19 bits of position data in PDF-1 are encoded as follows: a) bits 67 to 75: latitude data (9 bits) with 30 minute resolution, including: • bit 67: N/S flag (N=0, S=1) • bits 68 to 75: degrees (0 to 90) in 1/2 degree increments (default value of bits 67 to 75 = 0 11111111); and b) bits 76 to 85: longitude data (10 bits) with 30 minute resolution, including: • bit 76: E/W flag (E=0, W=1) • bits 77 to 85: degrees (0 to 180) in 1/2 degree increments (default value of bits 76 to 85 = 0 111111111).

TAC numbers 950 to 959 are currently unallocated. † 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 or a 9-digit MMSI in the form 98MIDXXXX for craft associated with a parent vessel with 98M in bits 27 to 36 and "IDXXXX" in bits 47 to 66.

A-33

A3.3.7.2 The 26 bits available in PDF-2 are defined as follows: a) bits 107 and 108 Supplementary Data (1) bits 107: encoded position data source "0" = the encoded position data is provided by an external navigation device "1" = the encoded position data is provided by an internal navigation device; (2) bit 108: 121.5 MHz auxiliary radio locating device included in beacon (1 = yes, 0 = no); b) bits 109 to 114: RLS Data (1) Bits 109-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 (e.g., Type-2)*: "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. (2) Bits 111-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 (or any other manually generated RLM) : "1": RLM Type-2 received by this beacon, "0": RLM Type-2 not (yet) received by this beacon. (3) Bits 113-114: RLS Provider Identification:

The condition bit 109 = “0” and bit 110 = “0” is an invalid condition; at least one of these two bits must always be a “1”.

A-34

"01": GALILEO Return Link Service Provider "10": GLONASS Return Link Service Provider* “11”: BDS Return Link Service Provider* "00": Spare (for other RLS providers) c) bits 115 to 123:  latitude with 4 second resolution: • bit 115:  sign (0 = minus, 1 = plus) • bit 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); d) bits 124 to 132:  longitude with 4 second resolution: • 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 124 to 132 = 1 0000 1111) A3.3.7.3 Users should utilize the Return Link Service Location Test protocol identified with bits 41-42 set to “11” described in section A3.3.7.1 when testing an RLS-capable beacon.

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 by the Cospas-Sarsat Council operational within the Cospas-Sarsat Programme. Type approval certificates allowing these versions of RLS Location protocols will not be issued until the RLS service provider has been approved for operational use in the System. † Section A3.3.7 defines the coding scheme for the RLS 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.

A-35

Figure A10: RLS Location Protocol 1 24→

27 36→ 37 40→|41 85→ 86 106→

115 132→ 133 144→ 61 BITS PDF-1 BCH-1 26 BITS PDF-2 BCH-2

BIT & FRAME SYNCHRONIZ . PATTERNS F O R M A T & P R O T O C O L F L A G 26 BITS IDENTIFICATION 19 BITS LATITUDE LONGITUDE S U P L E M E N T A R Y D A T A  LATITUDE  LONGITUDE C O P R

U N T R Y C O D E O T O C O L C O D E B E A C O N T Y P E RLS TAC or NRN or RLS ID S N E U R M I B A E L R or N S D E G R E E S 0 - 90 (1/2 deg) E W D E G R E E S 0 - 180 (1/2 deg) 21-BIT BCH ERROR CORRECTING CODE

M I N U T E S 0 - 15 (1m) S E C O N D S 0 - 56 (4 s.)

M I N U T E S 0 - 15 (1m) S E C O N D S 0 - 56 (4 s.) 12-BIT BCH ERROR CORRECTING CODE Bits 43-46 ‘1111’ Bits 47-66 Last 6 digits of MMSI If bits 43 to 46 = 1111 107 = Encoded Position Data Source: 1 = Internal, 0 = external F=1 1101 “00” =ELT “00” First EPIRB 108 = 121.5 MHz Homing: 1= Yes, 0 = No P=0 “01”=EPIRB “01” Second EPIRB 109 and 110 = Return Link Message (RLM) Request “10”=PLB 111 and 112 = Beacon Feedback (on receipt of RLM) “11”=RLS Location Test protocol 113 and 114 = Return Link Service (RLS) Provider NRN – National RLS Number (see section A.3.3.7.1)

A-36

A3.3.8 ELT(DT) Location Protocol (see Figure A11) A3.3.8.1 The ELT(DT) location protocol, identified by the flags F=1, P=0 and the protocol code in series no. 8 of Table A2-B, has the following structure: a) PDF-1: bits 37 to 40: 4-bit protocol code defined as 1001; bits 41 to 42: 2 bits for type of beacon identity set to “00” for Aircraft 24-bit address *, “01” for Aircraft operators designator and serial number†, “10” for TAC with serial number†, and “11” reserved for future use; bits 43 to 66: 24 bits of beacon identification data: • (Bits 41 and 42 “00”) a 24-bit aircraft address (only one ELT per aircraft can be identified using this protocol); or • (Bits 41 and 42 “01”) a 15-bit aircraft operator designator‡ in bits 43 to 57, and a 9-bit serial number (1 to 511) assigned by the operator in bits 58 to 66; or • (Bits 41 and 42 “10”) a 10-bit Cospas-Sarsat type approval certificate number of the beacon (1 to 1,023) in bits 43 to 52, and a 14-bit serial number (1 to 16,383) in bits 53 to 66; or • (Bits 41 and 42 “11”) reserved for future use and shall not be used for beacon coding. or ELT(DT) Location Test protocol when bits 43 to 66 are encoded with either all ”0”s, or all “1”s;

This coding is compliant with the mandatory data elements defined in ICAO document 10150, "Manual on the Functional Specifications for the Location of an Aircraft in Distress Repository (LADR)" where bits 41 and 42 are set to “00” and the aircraft 24-bit address is provided in PDF-1, and the 3LD designator of the aircraft operator is provided in the rotating PDF-2 field (when bits 113 and 114 are set to “00” and bits 115 to 117 are set to “000” at the intervals described in section 2.2.1 of this document). The LADR is a facility, that will be used by Cospas-Sarsat, to support ICAO requirements for autonomous location of an aircraft in distress contained in Annex 6, Part I, section 6.18 to the Convention on International Civil Aviation. † WARNING: These coding options are NOT compliant with the mandatory data elements defined in ICAO document 10150 (no aircraft identifier is available) and the associated data cannot be stored in the LADR. Manufacturers wishing to comply with ICAO GADSS requirements and use these coding options should first consult the relevant Administration’s aviation authorities for guidance, prior to encoding beacons with these protocols. ‡ The aircraft operator designator (3 letters) can be encoded in 15 bits using a shortened form of the modified-Baudot code (i.e.: since all letters in the modified-Baudot code are coded in 6 bits, with the most significant bit = "1", this first (most significant) bit can be deleted to form a 5-bit code per letter).

A-37

bits 67 to 85: 19 bits of position data to 30 minute resolution; b) PDF-2: bits 107 & 108: means of activation bits 109 to 112: encoded altitude bits 113 & 114 encoded location freshness or PDF-2 rotating field indicator bits 115 to 132: 18-bit position offset ( latitude,  longitude) to 4 second resolution or aircraft operator 3LD. A3.3.8.2 The 19 bits of position data in PDF-1 are encoded as follows: a) bits 67 to 75: latitude data (9 bits) with 30 minute resolution, including: • bit 67: N/S flag (N=0, S=1) • bits 68 to 75: degrees (0 to 90) in 1/2 degree increments (default value of bits 67 to 75 = 0 11111111); and b) bits 76 to 85: longitude data (10 bits) with 30 minute resolution, including: • bit 76: E/W flag (E=0, W=1) • bits 77 to 85: degrees (0 to 180) in 1/2 degree increments (default value of bits 76 to 85 = 0 111111111). A3.3.8.3 The 26 bits available in PDF-2 are defined as follows: a) bits 107 and 108: means of activation “00”: manual activation by the user “01”: automatic activation by the beacon “10”: automatic activation by external means “11”: spare If the beacon receives more than one triggering command, then the most recent triggering event is indicated in the bits 107-108. b) bits 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)

A-38

“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 c) bits 113 & 114: encoded location freshness or PDF-2 rotating field indicator: • “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 than or equal to 2 seconds); d) bits 115 to 123:  latitude with 4 second resolution: • bit 115:  sign (0 = minus, 1 = plus) • bit 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); e) bits 124 to 132:  longitude with 4 second resolution: • bit 124:  sign (0 = minus, 1 = plus) • bits 125 to 128: minutes (0 to 15) in 1 minute increments*

Section A3.3.8 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.

A-39

• bits 129 to 132: seconds (0 to 56) in 4 second increments (default value of bits 124 to 132 = 1 0000 1111) OR when bits 113 and 114 are set to “00”; f) bits 115 to 117: PDF-2 rotating field type • 000: aircraft operator 3LD • other combinations: spare; g) bits 118 to 132: when PDF-2 rotating field type is 000, then bits 118 to 132 indicate aircraft operator 3LD*, coded using the Modified Baudot Code in Table A3 (3 letters, each using 5 bits, omitting the most significant bit in Table A3; 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). A3.3.8.4 Users should utilize the ELT(DT) Location Test protocol identified with bits 43-66 described in section A3.3.8.1 when testing an ELT(DT). A3.3.8.5 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. *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.

A-40

Figure A11: ELT(DT) Location Protocol 1 24→

27 36→ 37 40→|41 85→ | 86 106→

115 132→ 133 144→ ----------- 61 BITS ------------→ PDF-1 BCH-1 ------- 26 BITS --------→ PDF-2 BCH-2 BIT & FRAME SYNCHRONIZ. PATTERNS

F O R M A T & P R O T O C O L F L A G C O U N T R Y C O D E PC 26 BITS IDENTIFICATION DATA 19 BITS LATITUDE LONGITUDE S U P P L E M E N T A R Y D D A T A  LATITUDE  LONGITUDE

type of beacon identity 24-bit aircraft address or TAC & serial number or 15-bit aircraft operator designator or ELT(DT) Location Test protocol N S D E G R E E S 0 - 90 (1/2 deg) E W D E G R E E S 0 - 180 (1/2 deg) 21-BIT BCH ERROR CORRECTING CODE

M I N U T E S 0 - 15 (1min) S E C O N D S 0-56 (4s)

M I N U T E S 0-15 (1min) S E C O N D S 0-56 (4s) 12-BIT BCH ERROR CORRECTING CODE + or rotating field data (e.g., 3LD)  Bits 41 and 42 = indication of type of ELT(DT) beacon identity  107-108 = means of activation F=1  109-112 = altitude P=0  113-114 = encoded location freshness or PDF-2 rotating field indicator  CANCELLATION MESSAGE  26 BITS IDENTIFICATION DATA FIXED SEQUENCE BCH-1 F I X E D FIXED SEQUENCE BCH-2   67 - 75 = “1 1111 1010”  107 - 114 = “0011 1100” F=1  76 - 85 = “1 1111 1101 0”  115 - 123 = “0 1111 0000” P=0  124 - 132 = “0 1111 0000”

A-41

END OF ANNEX A -

B-1

ANNEX B BCH AND CRC CALCULATIONS SAMPLE BOSE-CHAUDHURI-HOCQUENGHEM ERROR-CORRECTING CODE CALCULATION B1 SAMPLE 21-BIT BCH CODE CALCULATION The error-correcting code used in the first protected field of all 406 MHz messages is a shortened form of a (127,106) Bose-Chaudhuri-Hocquenghem (BCH) code. The shortened form (82,61) consists of 61 bits of data followed by a 21-bit triple error-correcting code. The code is used to detect and correct up to three errors in the entire 82-bit pattern (bits 25 through 106 of the 406-MHz message). Note: For the purpose of error correction, all calculations shall be performed with the full length code. Therefore, 45 zeros are placed before the 61 data bits to form the 106 bit pattern of the (127,106) BCH code. These padding zeros do not affect the generation of the BCH code as described below. For the (82,61) BCH code, a generator polynomial g(X) (the same as for (127,106) BCH code) is defined as follows: g(X) = LCM (m1 (X) , m3 (X) , m5 (X)) where LCM = Least Common Multiple. In the above case: m1 (X) = X7 + X3 + 1 m3 (X) = X7 + X3 + X2 + X + 1 m5 (X) = X7 + X4 + X3 + X2 + 1 from which, g(X) = m1 (X) m3 (X) m5 (X) = X21 + X18 + X17 + X15 + X14 + X12 + X11+ X8 + X7 + X6 + X5 + X + 1 a determination of g(X) results in the following 22-bit binary number: g(X) = 1001101101100111100011 To generate the BCH code, an information polynomial, m(x) is formed from the 61 data bits as follows: m(X) = b1 X 60 + b 2 X 59 + .... + b60 X + b61 where b1 is the first bit (i.e. format flag), and b61 is the last bit of PDF-1.

B-2

m (X) is then extended to 82 bits by filling the least significant bits with 21 "0". The resulting 82-bit binary string is then divided by g(X) and the remainder, r(X), becomes the BCH code (the quotient portion of the result of the module-2 binary division is discarded). The above process may be clarified by the following example: Message Format Short Message Protocol Flag User Protocol Country Code 366 (USA) User Protocol Type Serial Beacon Type Float free EPIRB Manufacturer's ID

Sequence Number

Beacon Model Number

Production Run Number

National Use Bits

Homing 121.500 MHz Emergency/National Use Not Used Beacon Activation Automatic or Manual for which: Beacon 15 Hex ID: ADCD0 08004 40401 (bits 26-85) Short Message: 56E68 04002 20200 96552 50 (bits 25-112) Bits 25-112: 0101 0110 1110 0110 1000 0000 0100 0000 0000 0010 0010 0000 0010 0000 0000 1001 0110 0101 0101 0010 0101

The division* described above is shown in Figure B1 and results in a remainder of:

The most significant bit position of the remainder will always be a "0" and is deleted to obtain the 21-bit BCH code: BCH Error-Correcting Code: 001011001010101001001 REFERENCE An Introduction to Error Correcting Codes, Shu Lin, Prentice-Hall 1970

Modulo 2 division prohibits a "borrow" in the subtraction portion of the long division

B-3

| | | ---->|<------------- Bits 25 - 85 ------------------------------>|<---Bits 86-106---->| 45’0’| (Data bits) | (21 "0"s) | m(X)=0101011011100110100000000100000000000010001000000010000000001000000000000000000000 g(X)= 1001101101100111100011

B-4

B2 SAMPLE 12-BIT BCH CODE CALCULATION The BCH error correcting code (bits 133-144) used in the second protected field of the long message is capable of detecting and correcting up to two bit errors in the bits 107-144. The generator polynomial used as a basis for this code is: g(x) = (1 + x + x6) (1 + x + x2 + x4+ x6)

(1 + x3 + x4 + x5 + x8 + x10 + x12) An example of the 12-bit BCH code which protects the 38-bit second protected field (i.e., bits 107 through 144) is shown below for the user-location protocol. The position in this example is as follows: actual latitude: 4333.63' N actual longitude: 001 28.85' E latitude rounded to nearest 4' increment: 4332' N longitude rounded to nearest 4' increment: 00128' E binary message:

Encoded Position Data Source is Internal bit 107:
North latitude bit 108:
Latitude 43 bits 109-115:
Latitude 32' bits 116-119:
East longitude bit 120:
Longitude 1 bits 121-128:
Longitude 28' bits 129-132:
BCH code bits 133-144: (see Figure B2) Placing the binary bits 107-132 in order gives: 10 0101 0111 0000 0000 0001 0111 and the BCH code is calculated as shown in Figure B2. The resultant 12-bit BCH code is: 0001 0101 0001

B-5

| | | ---->|<---Bits 107-132------->|<-133-144->| 25’0’| (Data bits) | (12 "0"s) | m(X)=10010101110000000000010111000000000000 g(X)=1010100111001

B-6

B3 SAMPLE Moffset CALCULATIONS AND CRC-CODE FIGURE B3: SAMPLE MOFFSET CALCULATION

END OF ANNEX B - 15 Hex ID: 193BFCE031BFDFF CRC-polynomial : x 16+x 15+x 2+1 CRC-16(193BFCE031BFDFF) = 0xB380 and Moffset=BIN2DEC(CRC-16(193BFCE031BFDFF)) mod 60 = 52

C-1

ANNEX C EXAMPLES OF RLS GNSS RECEIVER TIMING The operation of the RLS GNSS Receiver is defined in section 4.5.7.2 of this document in. A set of examples of RLS operation are provided in Table C1, which cover a range of conditions to clarify the interpretation of the Moffset timing, and are summarized below:

UTC + Moffset of 59 minutes - No RLM received;
No UTC + Moffset of 1 minute - UTC acquired at 2:34 - RLM received at 4:07;
UTC + Moffset of 17 minutes - No RLM received;
UTC + Moffset of 20 minutes - RLM received at 2:29; and
UTC + Moffset of 11 minutes - RLM received at 0:45. These examples are provided to ensure a common understanding of the expected functioning of the Moffset capability and are intended to be used as the basis for the development test scenarios. The above five examples are believed to cover all of the timing scenarios that can exist, between the activation of the RLS GNSS Receiver and various values of Moffset, and specifically cover the following situations: • UTC acquired soon after beacon activated; • UTC not acquired until sometime after the beacon is activated; • no RLM received within the 6-hour RLS operational timeframe; • GNSS timing changes between the Moffset timing and the regular GNSS receiver timing; • correct occurrence of the first Moffset GNSS Receiver timing versus beacon activation time; and • ideal functioning of the RLS system.

C-2

Table C1: Example Scenarios for RLS GNSS Timing Description of GNSS and Beacon Operation Beacon RLM Attempt Example 1 Example 2 UTC + Moffset 59 minutes, No RLM received No UTC + Moffset 1 minutes, UTC acquired at 2:34, RLM received at 4:07 Time at which Beacon is Activated 0:00 0:17 Time of first RLM Request transmission

0:01 0:18 GNSS Receiver first 30 minute on period 0:30 0:47* GNSS Receiver next turns on at

0:59 1:02 GNSS Receiver next turns off at 1:14 1:05 GNSS Receiver next turns on at

1:59 1:17 GNSS Receiver next turns off at 2:14 1:20 GNSS Receiver next turns on at

2:59 1:32 GNSS Receiver next turns off at 3:14 1:35 GNSS Receiver next turns on at

3:59 1:47 GNSS Receiver next turns off at 4:14 2:02 GNSS Receiver next turns on at

4:59 2:32 GNSS Receiver next turns off at 5:14 2:34† GNSS Receiver next turns on at

5:59 3:01 GNSS Receiver next turns off at 6:00‡ 3:16 GNSS Receiver next turns on at

4:01 GNSS Receiver next turns off at 4:07§ GNSS Receiver reverts to non- RLS operation 6:00 4:07 Note that interleaved with the GNSS Receiver timings, the GNSS receiver also turns on in accordance with section 4.5.5.4, as well in Examples 1, 3 and 4, but these GNSS 'on' periods are omitted for clarity in the tables.

Timing reverts to schedule per document C/S T.001, section 4.5.5.4. † UTC acquired, back to RLS schedule ‡ Last ‘on’ period, 1-minute duration, as 6 hours have elapsed from beacon turn-on. § With no UTC reference, receiver reverts to document C/S T.001, section 4.5.5.4 timing, until UTC is obtained.

C-3

Table C1 (Continued): Example Scenarios for RLS GNSS Timing Description of GNSS and Beacon Operation Beacon RLM Attempt Example 3 Example 4 Example 5 UTC + Moffset 17 minutes, No RLM received UTC + Moffset 20 minutes, RLM received at 2:29 UTC + Moffset 11 minutes, RLM received at 0:45 Time at which Beacon is Activated 0:58 0:14 0:40 Time of first RLM Request transmission

0:59 0:15 0:41 GNSS Receiver first 30 minute on period 1:28 0:44 0:45* GNSS Receiver next turns on at

2:17 1:20 GNSS Receiver next turns off at 2:32 1:35 GNSS Receiver next turns on at

3:17 2:20 GNSS Receiver next turns off at 3:32 2:29† GNSS Receiver next turns on at

4:17 GNSS Receiver next turns off at 4:32 GNSS Receiver next turns on at

5:17 GNSS Receiver next turns off at 5:32 GNSS Receiver next turns on at

6:17 GNSS Receiver next turns off at 6:32 GNSS Receiver next turns on at

‡ GNSS Receiver next turns off at GNSS Receiver reverts to non-RLS operation 6:32 2:29 0:45

END OF ANNEX C-

GNSS only ‘on’ for 4 min until RLM received, Moffset never needed. † GNSS only ‘on’ for 9 min, until RLM received. ‡ 6 hours up at 6:58, so no seventh attempt is initiated for this case.

D-1

ANNEX D RLS INFORMATION Example of Information to be Included in the User Manual of an RLS-Capable Beacon This beacon has the Return Link Service (RLS) feature. The RLS feature is an indication on the beacon that confirms to the beacon user that the distress signal from an activated beacon has been localised by the Cospas-Sarsat system and is being sent to the responsible search-and-rescue (SAR) authorities. It does NOT mean that a search and rescue has yet been organized/launched, but only confirms that the distress alert has been received by the Cospas-Sarsat System and is being routed to the appropriate SAR agencies. The RLS is designed to send an acknowledgment to the beacon user in less than 30 minutes from beacon activation (actual acknowledgement times are typically much quicker). Alerting of the distress to SAR authorities is independent of (and may occur before) the RLS acknowledgment indication on the beacon. The RLS specification is described in the Galileo SAR Service Definition Document: (https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-SAR-SDD.pdf). RLS is an optional function and may not be permitted in all countries or for all beacon types. You may visit the web page Where Can I Buy an RLS-Enabled Beacon? (https://cospas-sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase) to learn the most recent information about national support for RLS. Cospas-Sarsat strongly recommends that you appropriately register your beacon. It only is possible to register a beacon in the registry operated by the country matching the “country code” electronically programmed into the beacon (or the International Beacon Registration Database (IBRD) (https://www.406registration.com/) if the country uses the IBRD for their registrations). For example, it only is possible to register a beacon with a French country code in France’s national registry. However, owners of Belgian-coded beacons must register in the IBRD. The country code is encoded in the beacon’s unique identification number (UIN, also called Hex ID), which is used to register the beacon. Visit the web page Beacon Registration Contacts (https://www.406registration.com/countriessupported.aspx) to see where you can register your beacon.

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 7999 Fax: +1 514 500 7996 Email: mail@406.org Website: http://www.406.org

196 KiB Raw Blame History Unescape Escape

A1.3 Protocol Codes Each coding protocol is identified by a unique protocol code defined as follows:

3-bit code in bits 37 to 39 for user and user-location protocols;

As Defined in C/S T.018 (46 bits) Notes: RL

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

indicates an aircraft operator designator and a serial number are encoded in bits 44-61 and 62-73, respectively. Bit 43 is a flag bit to indicate that the Cospas-Sarsat type approval certificate number is encoded. If bit 43 is set to 1:

bits 64-73 should either be set to all 0s or allocated for national use and control (and will be made public when assigned by the responsible administration) or used as defined for coding the aircraft 24-bit address or aircraft operator designator;

AIRCRAFT 24 BIT ADDRESS N DEG E DEG 21-BIT BCH ERROR CORRECTING CODE N T A R

N U T E C O N D

N A BIT & FRAME SYNCHRONIZ. PATTERNS & P R O T O C O L F L A G U N T R Y C O D E O T O C O L C O D E NATIONAL ID NUMBER N S D E G R E E S 0 - 90 (1 deg) M I N U T E S 0 - 58 (2 m) E W D E G R E E S 0 - 180 (1 deg) M I N U T E S 0 - 58 (2m) 21-BIT BCH ERROR CORRECTING CODE E M E N T A R Y D A T A

M I N U T E S 0 - 3 (1m) S E C O N D S 0 - 56 (4 s.)

U N T R Y C O D E O T O C O L C O D E B E A C O N T Y P E RLS TAC or NRN or RLS ID S N E U R M I B A E L R or N S D E G R E E S 0 - 90 (1/2 deg) E W D E G R E E S 0 - 180 (1/2 deg) 21-BIT BCH ERROR CORRECTING CODE

M I N U T E S 0 - 15 (1m) S E C O N D S 0 - 56 (4 s.)

type of beacon identity 24-bit aircraft address or TAC & serial number or 15-bit aircraft operator designator or ELT(DT) Location Test protocol N S D E G R E E S 0 - 90 (1/2 deg) E W D E G R E E S 0 - 180 (1/2 deg) 21-BIT BCH ERROR CORRECTING CODE

M I N U T E S 0 - 15 (1min) S E C O N D S 0-56 (4s)

196 KiB

Raw Blame History