SPECIFICATION FOR COSPAS-SARSAT 406 MHz DISTRESS … · C/S T.001 Issue 4 – Revision 6 May 2020 -...

SPECIFICATION FOR COSPAS-SARSAT

406 MHz DISTRESS BEACONS

C/S T.001 Issue 4 – Revision 6 May 2020

- i - C/S T.001 – Issue 4 – Rev. 6

May 2020

SPECIFICATION FOR COSPAS-SARSAT

406 MHz DISTRESS BEACONS

History

Issue Revision Date Comments

1 - April 1986 Approved by the Cospas-Sarsat Steering Committee

(CSSC-15)

2 - November 1988 Approved by the Cospas-Sarsat Council (CSC-1)

3 - November 1995 Approved by the Cospas-Sarsat Council (CSC-15)

3 1 January 1998 Approved by the Cospas-Sarsat Council (CSC-19)

3 2 October 1998 Approved by the Cospas-Sarsat Council (CSC-21)


3 3 October 2000 Editorial changes, approved by the Cospas-Sarsat Council

(CSC-25) as Corrigendum to C/S T.001 Issue 3 - Rev.3




3 7 November 2005 Approved by the Cospas-Sarsat Council (CSC-35)









3 16 December 2015 Approved by the Cospas-Sarsat Council (CSC-55)

4 - December 2016 Approved by the Cospas-Sarsat Council (CSC-57)

4 1 May 2017 Approved by the Cospas-Sarsat Council (CSC-58)

4 2 February 2018 Approved by the Cospas-Sarsat Council (CSC-59)

4 3 June 2018 Approved by the Cospas-Sarsat Council (CSC-60)

4 4 February 2019 Approved by the Cospas-Sarsat Council (CSC-61)


4 6 May 2020 Approved by the Cospas-Sarsat Council (CSC-63)

- ii - C/S T.001 – Issue 4 – Rev. 6

May 2020

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-3 Unmodulated Carrier ..................................................................................... 2-3 Digital Message ............................................................................................. 2-3

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-6 Spurious Emissions ........................................................................................ 2-7 Data Encoding................................................................................................ 2-7 Modulation ..................................................................................................... 2-8 Voltage Standing-Wave Ratio ....................................................................... 2-8 Maximum Continuous Transmission ............................................................. 2-8

3. DIGITAL MESSAGE CONTENT ........................................................................ 3-1

3.1 Basic Structure ............................................................................................................ 3-1

3.2 Beacon Coding ........................................................................................................... 3-2

3.3 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

- iii - C/S T.001 – Issue 4 – Rev. 6

May 2020

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-6

4.5.5.1 General .......................................................................................................................4-6 4.5.5.2 Message Content and Timing .....................................................................................4-6 4.5.5.3 Internal Navigation Device Performance ...................................................................4-7 4.5.5.4 Internal Navigation Device Timing ............................................................................4-8 4.5.5.5 External Navigation Device Input ..............................................................................4-9 4.5.5.6 ELT(DT) Navigation Device Requirements ...............................................................4-9

Beacon Activation ........................................................................................ 4-11 4.5.6.1 ELT(DT) Modes of Operation .................................................................................. 4-11

RLS Beacon Requirements .......................................................................... 4-13 4.5.7.1 GNSS Receiver......................................................................................................... 4-13 4.5.7.2 RLS GNSS Receiver Operation ............................................................................... 4-13 4.5.7.2.1 Operation Cycle ........................................................................................................ 4-13 4.5.7.2.2 Derivation of Moffset ............................................................................................... 4-15 4.5.7.3 RLS Indicator ........................................................................................................... 4-15 4.5.7.4 Confirmation of a Return-Link Message Receipt ..................................................... 4-16 4.5.7.5 RLS Beacon Documentation .................................................................................... 4-16

Beacon Labelling and Marking .................................................................... 4-16 Operator Controlled Voice Transceivers ..................................................... 4-17

ELT(DT)s Specifically Designed to Withstand a Crash Impact .................. 4-18 4.5.10.1 Introduction .............................................................................................................. 4-18 4.5.10.2 Beacon Hex ID ......................................................................................................... 4-18 4.5.10.3 Burst Repetition Period (with Crash Detection) ....................................................... 4-18 4.5.10.4 GNSS Update Rate (after Crash Detection) ............................................................. 4-18 4.5.10.5 Duration of Continuous Operation ........................................................................... 4-19 4.5.10.6 Homing and Locating Signals .................................................................................. 4-19

ELT(DT)s Combined with Automatic ELTs ............................................... 4-19 4.5.11.1 Introduction .............................................................................................................. 4-19 4.5.11.2 Beacon Coding and Beacon Hex ID ......................................................................... 4-19 4.5.11.3 Burst Repetition Period ............................................................................................ 4-19 4.5.11.4 System Requirements ............................................................................................... 4-20 4.5.11.5 Cancellation Message ............................................................................................... 4-20 4.5.11.6 Encoded Position Data and Navigation Device Performance................................... 4-20 4.5.11.7 Duration of Continuous Operation ........................................................................... 4-20 4.5.11.8 Class of Operation .................................................................................................... 4-20 4.5.11.9 Homing and Locating Signals .................................................................................. 4-21

External Power Source for ELT(DT)s ......................................................... 4-21

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

- iv - C/S T.001 – Issue 4 – Rev. 6

May 2020

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-8 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-12

A2.6 Test User Protocol ...................................................................................... A-12 A2.7 Orbitography Protocol ................................................................................ A-13 A2.8 National User Protocol ................................................................................ A-13 A2.9 Non-Protected Data Field ........................................................................... A-14

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 IOC NOTICE ................................................................................................ D-1

- v - C/S T.001 – Issue 4 – Rev. 6

May 2020

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-4 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 G.004,

“Cospas-Sarsat Glossary”.

- END OF SECTION 1 -

2-1 C/S T.001 – Issue 4 – Rev. 6

May 2020

2. 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 period shall be randomised around a mean value of 50 seconds, so

that time intervals between transmissions are randomly distributed on the interval 47.5 to 52.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:

5 seconds + 0.0 / - 0.2 seconds during the first 120 seconds after beacon activation;

10 seconds + 0.0 / - 0.2 seconds between 120 seconds and 300 seconds after beacon

activation; and

after the first 300 seconds after beacon activation until the beacon is deactivated

the period shall be randomised around a mean value of 28.5 seconds, so that time

intervals between transmissions are randomly distributed on the interval 27.0 to

30.0 seconds.

For ELT(DT)s transmitting the 3LD aircraft operator designator in PDF-2, the transmission

scheme shall be as provided in Figure 2.1.

* 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

Figure 2.1: Burst Transmission Scheme for ELT(DT)s transmitting the 3LD aircraft operator designator in PDF-2

2-3 C/S T.001 – Issue 4 – Rev. 6

May 2020

From beacon activation and up to 120 seconds after beacon activation, the time interval between

the beginning of two successive bursts shall be 5 seconds + 0.0 / - 0.2 and 1 burst out of 4, starting

with the second burst transmitted shall transmit the aircraft operator 3LD in PDF-2 (instead of an

encoded location in PDF-2 for the other 3 out of 4 bursts) as per Figure 2.1.

From 120 seconds and up to 300 seconds after beacon activation, the time interval between the

beginning of two successive bursts transmitting an encoded location in PDF-2 shall be 10 seconds

+ 0.0 / - 0.2 . In addition, an extra burst with the aircraft operator 3LD in PDF-2 shall be transmitted

after the first burst, and then after every sixth burst with an encoded location in PDF-2 (3 burst in

total for this period) as per Figure 2.1. These additional bursts with 3LD in PDF-2 shall be

transmitted with a time interval between the beginning of the previous burst and the beginning of

these bursts of 5 seconds ± 0.5 seconds.

300 seconds after activation and thereafter, the time interval between the beginning of two

successive bursts containing an encoded location in PDF-2 shall be randomised around a mean

value of 28.5 seconds, so that time intervals between transmissions are randomly distributed on

the interval 27.0 to 30.0 seconds, except for 25 additional bursts containing the aircraft operator

3LD in PDF-2 that shall be transmitted after the 16th burst and then after every 30th burst with an

encoded location in PDF-2, as per Figure 2.1. The additional bursts with an aircraft operator 3LD

in PDF-2 shall be transmitted with a time interval between the beginning of the previous burst and

the beginning of these bursts of 15 seconds ± 0.5 seconds.

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.

Digital Message

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;

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.

2-4 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.3.

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

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

87 BITS (SEE SECTION 3) 160 ms CARRIER

9 BITS

15 BITS

(2) (1) NOTE: (3)

119 BITS (SEE SECTION 3) 160 ms CARRIER

9 BITS

15 BITS

(2) (1) NOTE: (3)

2-5 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

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:

* 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.

2-6 C/S T.001 – Issue 4 – Rev. 6

May 2020

• 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

Organisations, or as declared by the beacon manufacturer, if it is different from 370 minutes), 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

2-7 C/S T.001 – Issue 4 – Rev. 6

May 2020

- 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

Data Encoding

The data shall be encoded biphase L, as shown in Figure 2.5.

Pc

(POWER OUTPUT OF UNMODULATED CARRIER)

0 dBc

- 20 dBc

- 20 dBc

- 30 dBc

- 30 dBc

- 35 dBc - 35 dBc

- 40 dBc

- 40 dBc

- 3 kHz

- 7 kHz

7 kHz

3 kHz

fc 12 kHz

- 12 kHz

24 kHz - 24 kHz

406.1 MHz 406.0 MHz

FREQUENCY (fc = BEACON CARRIER FREQUENCY)

2-8 C/S T.001 – Issue 4 – Rev. 6

May 2020

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:

05.021

21

+

−

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

Modulated Signal

Time

Figure 2.6*: Definition of Modulation Rise and Fall Times

Time

Modulated Signal

Figure 2.7†: Definition of Modulation Symmetry


* Figure not to scale. † Figure not to scale.

3-1 C/S T.001 – Issue 4 – Rev. 6

May 2020

3. DIGITAL MESSAGE CONTENT

3.1 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-Hocquenhem 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-

Hocquenhem 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

3.2 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.

3.3 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.


4-1 C/S T.001 – Issue 4 – Rev. 6

May 2020

4. 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

NOTES: Tmax = + 70°C (Class 0 beacon)

Tmax = + 55°C (Class 1 & 2 beacons)

Tmin = - 55°C (Class 0 beacon)



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 this time is reduced on the down-ramp test to

one (1) hour.

SLO

PE =

+A

* °C/h

SLOPE = -A *

°C/h

TIMEtmeas

2h 2h 1h

2hα

TEM

PER

ATU

RE

(°C

)

ton

Twarm-up = 15 min

Figure 4.1: Temperature Gradient

4.3 Mechanical Environment

Beacons shall be submitted to vibration and shock tests consistent with their intended use.

Internationally-recognized standards such as RTCA/DO-183 for ELTs could be used by the

national authorities.

4-3 C/S T.001 – Issue 4 – Rev. 6

May 2020

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†.

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.

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.

* 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

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. If a 440 ms

transmission is used for beacons encoded with the long format messages, it is recommended that

the message be truncated without changing the format flag bit.

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 emittedat 406 MHz and at 121.5 MHz, if applicable;

the internal check has passed successfully, or has failed; and

the beacon battery may not have sufficient energy to support beacon operation for

the manufacturer-declared minimum operating lifetime.*†

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.

* 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.

4-5 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

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;

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 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;

* The primary battery is the battery which is powering the 406 MHz function.

4-6 C/S T.001 – Issue 4 – Rev. 6

May 2020

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; 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.

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.

Three levels of position resolution can be encoded in the beacon message:

• 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 either 15 minutes or 2 minutes;

• position data with resolution of 4 minutes in PDF-2, together with any of the user

protocol identification methods used in PDF-1; and

• position data in the short message with a resolution of either 15 minutes or

2 minutes, together with a subset of the beacon identification methods

(i.e., with shortened identification data).

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 protects the data of the first protected field (PDF-1 and BCH-

1) and a 12-bit BCH code protects the data of the second protected field (PDF-2 and BCH-2). The

BCH codes shall always match the message content. The beacon shall recompute these codes each

time the message content is changed.

* 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-7 C/S T.001 – Issue 4 – Rev. 6

May 2020

The beacon shall commence transmissions upon activation even if no valid position data are

available. Until valid 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 data is available. All beacons with internal navigation

devices shall provide updated position data, 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 min) after the last valid position data input. After 4

hours the encoded position shall be set to the default values specified in Annex A.

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 when transmitting an optional GNSS self-test when the beacon shall

radiate 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, or 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.

* 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-8 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.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 least every 15 minutes and no more

frequently than every 4 minutes and 25 seconds, from the end of the last update attempt, for the

remainder of the manufacturer declared minimum operating lifetime of the beacon†. Whenever 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 location) shall be transmitted

until either a location is available or 4 hours have elapsed.

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

* * 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 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. † 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.

4-9 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

The first ELT(DT) transmission shall occur within 5 seconds of the beacon activation. If, after the

ELT(DT) activation, navigation data is not available, then the ELT(DT) shall transmit its first and

subsequent 406-MHz messages with the default position values specified in Annex A until such

time, as navigation data becomes available 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 that was calculated within the 2 seconds immediately prior to a 406-MHz

transmission.

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

* 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-10 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 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.

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

4-11 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 the activation of any control other than the ‘Off’ or ‘Reset’ controls

shall not stop the beacon from transmitting or result in inverted frame sync (self-test) mode.

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 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. ELT(DT)s shall also have

means of deactivation by the same means of activation which shall be followed by a cancellation

message sequence.

* This requirement is mandatory to new beacon models submitted for type-approval testing at accepted test facilities

after 1 January 2018.

4-12 C/S T.001 – Issue 4 – Rev. 6

May 2020

Consequently:

• If the ELT(DT) has been automatically activated by the triggering system*, it shall

only be de-activated by the same means.

• 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.

* For example, triggered in compliance with EUROCAE ED-237 † For example, triggered by G-switch / deformation. ‡ For example, triggered in compliance with EUROCAE ED-237 or by G-switch / deformation.

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

May 2020

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.

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:

* Until FOC of Galileo RLS is declared by the Cospas-Sarsat Programme, beacon manufacturers shall ensure that the

RLS Location Protocol in an RLS beacon can only be encoded with the beacon types and country codes of those

countries participating in the RLS IOC phase, as identified on the Cospas-Sarsat website at https://www.cospas-

sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase. † 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.

https://www.cospas-sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase

https://www.cospas-sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase

4-14 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

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 ofMoffset 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

* 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-15 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

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 RLS Indicator

The beacon shall be provided with an RLS indicator designed to advise the user when a Type 1 RLS

or RLS Test has been received by the RLSP and the beacon has received a Type 1 Return Link

Message (RLM) or Test Return Link Message (Test RLM) respectively. The RLS Indicator 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 a 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 of the beacon transmitting an initial RLS request through the RLS

Location Protocol or RLS Location Test Protocol, commence indication of an RLS

request until either a valid RLM Type 1 or Test RLM message respectively is

received, or the beacon is deactivated, or the beacon battery is expired;

within 5 seconds of the beacon receiving a valid RLM Type 1 or Test RLM

message acknowledgement, commence a distinct indication until either the beacon

is deactivated or the beacon battery is expired; and

only provide the indication of receipt of an RLS request acknowledgment when

the received RLM Type 1 or Test RLM message contains the unique 15 Hex ID

4-16 C/S T.001 – Issue 4 – Rev. 6

May 2020

programmed into that beacon and the beacon has validated that this matches its

own 15 Hex ID.

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

its message as defined in the RLS Location Protocol, as described in section A.3.3.7.3. 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 any

limitations of the overall RLS system†.

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 (TAC),

* 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. † Until FOC of Galileo RLS is declared by the Cospas-Sarsat Programme, the user manual shall include the wording

in Annex D. In addition to English, this text may also be provided in an appropriate language for the intended place

of sale. This same text shall be included in a notice that is placed prominently in the product packaging with every

Galileo RLS capable beacon.

4-17 C/S T.001 – Issue 4 – Rev. 6

May 2020

beacon 15-Hex ID,

beacon operating temperature range,

minimum operating lifetime,

for RLS-capable beacons, wording on the Beacon Identity label (TAC / Hex ID

Label) indicating whether the RLS function is enabled or disabled,

labelling of the RLS indicator (if applicable).

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.

4-18 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

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

Adminsitrations 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.

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

restart the transmission schedule for an ELT(DT) as if the ELT(DT) had just been activated

and maintain this transmission schedule for the 30 minutes after the crash detection. Beyond 30

minutes, the ELT(DT) shall transmit bursts with a repetition period randomized around a mean value

of 120 seconds, so that time intervals between transmissions are randomly distributed over the interval

of 115 to 125 seconds.

For an ELT(DT) transmitting the 3LD in PDF-2, beyond 30 minutes after the crash detection, the

3LD is no longer required to be transmitted.

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.

4-19 C/S T.001 – Issue 4 – Rev. 6

May 2020

4.5.10.5 Duration of Continuous Operation

The minimum duration of continuous operation 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 and post-crash.

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.

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.

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.

4-20 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

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.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 and 4.5.5.4. 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 it shall comply with the requirements of sections 4.5.5.3 and 4.5.5.4.

4.5.11.7 Duration of Continuous Operation

The minimum duration of continuous operation for this type of combined ELT shall be a

combination of the minimum duration of continuous operation for an ELT(DT) and the minimum

duration of continuous operation for a non-ELT(DT) 406 MHz beacon (i.e. at least 30 hours and

10 minutes).

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

4-21 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

External Power Source for ELT(DT)s

The ELT(DT) shall have its own integral or internal power source. However, when available, the

ELT(DT) 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 –

C/S T.001 – Issue 4 – Rev. 6

May 2020

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

A-1 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 1. Bit synchronization bit 1 through bit 15 2. Frame synchronization bit 16 through bit 24 3. First protected data field (PDF-1) bit 25 through bit 85 4. First BCH error correcting field (BCH-1) bit 86 through bit 106 5. Non-protected data field bit 107 through bit 112 Long Message Format (see Figure A2) Bit Field Name Bit Field Location 1. Bit synchronization bit 1 through bit 15 2. Frame synchronization bit 16 through bit 24 3. First protected data field (PDF-1) bit 25 through bit 85 4. First BCH error correcting field (BCH-1) bit 86 through bit 106 5. Second protected data field (PDF-2) bit 107 through bit 132 6. 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

25 format flag (F)

26 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) country code 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.

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.

http://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/mid.aspx

http://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/mid.aspx

A-3 C/S T.001 – Issue 4 – Rev. 6

May 2020

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)

0

(short)

1

(long)

0

(protocol code: bits 37-40)

Not Used

Standard Location Protocols

National Location Protocol

RLS Location Protocols

ELT(DT) Location Protocol

1

(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 25 26 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

Data

21-Bit

BCH

Code

Supplementary and

Position or National

Use Data

12-Bit

BCH

Code

Bit No. 1-15 16-24 25 26 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

A-4 C/S T.001 – Issue 4 – Rev. 6

May 2020

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)

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

(radio call sign, 6 characters) 010

2. EPIRB - Radio Call Sign User Protocol 110

3. ELT - Aviation User Protocol (aircraft registration markings) 001

4. Serial User Protocol: 011

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 111

6. Orbitography Protocol 000

7. National User Protocol* 100

8. Not to be used (allocated to Second Generation Beacons) 101

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

Protocol Codes

(Bits 37 - 40)

Standard Location Protocols

1. EPIRB - MMSI/Location Protocol 0010

2. ELT - 24-bit Address/Location Protocol 0011

3. Serial Location Protocols a) ELT - serial 0100

b) ELT - aircraft operator designator 0101

c) EPIRB-serial 0110

d) PLB-serial 0111

4. Ship Security 1100

5. National Location Protocol

a) ELT 1000

b) EPIRB 1010

c) PLB 1011

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

A-5 C/S T.001 – Issue 4 – Rev. 6

May 2020

6. Test location Protocols

a) Standard Test Location Protocol 1110

b) National Test Location Protocol 1111

7. RLS Location Protocol 1101

8. ELT(DT) Location Protocol 1001

9. 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

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

26 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

00 no auxiliary radio-locating device

01 121.5 MHz

10 maritime 9 GHz Search and Rescue Radar Transponder (SART)

11 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

1. MARITIME USER PROTOCOL Bits 25 26 27 36 37 39 40 81 82 83 84 85

..... 0 1 Country Code 0 1 0 MMSI or Radio Call Sign (42 bits) 0 0 R L

2. RADIO CALL SIGN USER PROTOCOL

Bits 25 26 27 36 37 39 40 81 82 83 84 85

..... 0 1 Country Code 1 1 0 Radio Call Sign (42 bits) 0 0 R L

3. SERIAL USER PROTOCOL

Bits 25 26 27 36 37 39 40 42 43 44 73 74 83 84 85

..... 0 1 Country Code 0 1 1 T T T C Serial Number and other Data C/S Cert. No or

National Use

R L

4. AVIATION USER PROTOCOL

Bits 25 26 27 36 37 39 40 81 82 83 84 85

..... 0 1 Country Code 0 0 1 Aircraft Registration Marking (42 bits) E N 1 R L

5. NATIONAL USER PROTOCOL

Bits 25 26 27 36 37 39 40 85

...... F 1 Country Code 1 0 0 National Use (46 bits)

6. TEST USER PROTOCOL

Bits 25 26 27 36 37 39 40 85

..... F 1 Country Code 1 1 1 Test Beacon Data (46 bits)

7. ORBITOGRAPHY PROTOCOL

Bits 25 26 27 36 37 39 40 85

...... F 1 Country Code 0 0 0 Orbitography Data (46 bits)

8. SGB PROTOCOL (Reserved for SGB – but not transmitted)

Bits 25 26 27 36 37 39 40 85

...... … 1 Country Code 1 0 1 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

111000

110011

101110

110010

110000

110110

101011

100101

101100

111010

111110

101001

100111

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

100110

100011

101101

111101

101010

110100

100001

111100

101111

111001

110111

110101

110001

( )*

( - )**

/

0

1

2

3

4

5

6

7

8

9

100100

011000

010111

001101

011101

011001

010000

001010

000001

010101

011100

001100

000011

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

25 format flag (=0)


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)


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 (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.

A-8 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

25 format flag (=0)


27-36 country code


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)


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

A2.4 Aviation User Protocol

The aviation user protocol has the following structure:

Bits Usage

25 format flag (=0)


27-36 country code


40-81 aircraft registration marking

A-9 C/S T.001 – Issue 4 – Rev. 6

May 2020

82-83 specific ELT number


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

011 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

001 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;


A-10 C/S T.001 – Issue 4 – Rev. 6

May 2020

- 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

25 format flag (= 0)


27-36 country code


40-42 beacon type (=000, 010, 100 or 110)

43 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


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.

This serial number encoded in the beacon message is not necessarily the same as the production

serial number of the beacon.

A-11 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

25 format flag (= 0)


27-36 country code


40-42 beacon type (=011)


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



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.

A-12 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

25 format flag (=0)

27-36 country code


40-42 beacon type (=001)


44-61 aircraft operator designator

62-73 serial number assigned by operator



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

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


27-36 country code

37-39 test user protocol code (=111)

40-85 national use

* 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

25 format flag (short message =0, long message =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.

A-14 C/S T.001 – Issue 4 – Rev. 6

May 2020

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.

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

Table A4: Maritime Emergency Codes in Accordance with

the Modified (1) IMO Nature of Distress Indication

IMO

Indication(2

)

Binary

Code

Usage

1

2

3

4

5

6

7

8

9

0001

0010

0011

0100

0101

0110

0111

0000

1000

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)

109

110

111

112

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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)


A-17 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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

26

bits

27-39

bits 40-83 bits

84-85

bits 86-106 bit 107 bits 108-132 bits

133-144

1 ....... 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

26

bits

27-40

bits 41-64 bits 65-85 bits 86-106 bits 107-112 bits 113-132 bits

133-144

0 ....... Identification Data

(24 bits)



21-Bit

BCH code

Supplementary

Data

Position Data to 4 sec


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

26

bits

27-40

bits 41-58 bits 59-85 bits 86-106 bits 107-112 bits 113-126 bits

127-132

bits

133-144


(18 bits)



21-Bit

BCH code

Supplementary

Data



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

26

bits

27-40

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


(26 bits)



21-Bit

BCH code

Supplementary

Data (8 bits)



12-Bit

BCH code

A-19 C/S T.001 – Issue 4 – Rev. 6

May 2020

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° 30W. 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 with the

following interpretation:

“00”: manual activation by 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.

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 with the


“0000”: altitude is less than 400 m (1312 ft)

“0001”: altitude is between 400 m (1312 ft) and 800 m (2625 ft)





A-21 C/S T.001 – Issue 4 – Rev. 6

May 2020









“1110” altitude is greater than 10000 m (32808 ft)

“1111”: default value if altitude information is not available.

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


• “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).

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

Figure A6: General Format of Long Message for Location Protocols

1

24→

25

26 27

36→

37

39 →

40 41

83→

84

85 86

106→

107

112 →

113

132→

133

144→

----------- 61 BITS ----------→

PDF-1

BCH-1 ------ 26 BITS ------→

PDF-2

BCH-2

P

R

E

A

M

B

L

E

2 10 4 45 21 6 20 12

F

O

R

M

A

T

&

C

O

U

N

T

R

Y

C

O

D

E

3

010

110

001

011

111

USER-LOCATION PROTOCOLS

(P=1)

Identification Data

(same as User Protocols)

See Figure A7

2

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

4

0010

0011

0100

0101

0110

0111

1100

1110

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

4

1000

1010

1011

1111

NATIONAL LOCATION PROTOCOLS

(P=0)



See Figure A9

NATIONAL LOCATION PROTOCOLS




See Figure A9

4

1101

RLS LOCATION PROTOCOLS

(P=0)



See Figure A10

RLS LOCATION PROTOCOLS




See Figure A10

4

1001

ELT-DT LOCATION PROTOCOL

(P=0)



See Figure A11

ELT-DT LOCATION PROTOCOL




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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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


"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 4 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)



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

A-24 C/S T.001 – Issue 4 – Rev. 6

May 2020

Figure A7: User-Location Protocol

1

24→

25

26

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

P

R

E

A

M

B

L

E

2 10 3 44 2 21 1 12 13 12

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

1

LATITUDE

LONGITUDE

12-BIT BCH

ERROR

CORRECTING

CODE

O

T

O

C

E

(PC)

RADIO CALL SIGN USER PROTOCOL

(PC=110)

1 7 4 1 8 4

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)

84,85 = Homing 107 = Encoded Position Data source: 1= Internal, 0 = external

F=1 See See Figure A3 for details

P=1 Table A2 of identification data

A-25 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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)


(default value of bits 75 to 85 = 0 1111111111).


a) bits 107 to 109: ="110" (fixed);

b) bit 110: ="1" (fixed);

c) bit 111: encoded position data source



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


f) bits 123 to 132: longitude with 4 second resolution:


• bits 124 to 128: Minutes (0 to 30) in 1 minute increments**********

• bits 129 to 132: Seconds (0 to 56) in 4 second increments


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 C/S T.001 – Issue 4 – Rev. 6

May 2020

Figure A8: Standard Location Protocols

1

24→

25

26

27

36→

37

40→|41 85→

|

86

106→

107

112

113

132→

133

144→

----------- 61 BITS ------------→

PDF-1

BCH-1 ------- 26 BITS --------→

PDF-2

BCH-2

2 10 4 45 21 6 20 12

F

O

R

PC 24 BITS

IDENTIFICATION DATA

21 BITS

LATITUDE

LONGITUDE

S

U

P

LATITUDE

LONGITUDE

M

A

C

O

20 4 1 9 1 10 P

L

1 5 4 1 5 4

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

00

11

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

15 9 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

00

10 14 (1/4 d.) (1/4 d.) T

A

(1min) (4s) (1min) (4s)

F

L

A

G

01 10

11

C/S TA No

1 – 1023

SERIAL No

1 - 16383

20 4

11 00 MMSI

(last 6 digits, binary)

Fixed

0000

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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


a) bits 59 to 71: latitude data (13 bits) with 2 minute resolution:

• bit 59: N/S flag (N=0, S=1)




b) bits 72 to 85: longitude data (14 bits) with 2 minute resolution:

• bit 72: E/W flag (E=0, W=1)




A-29 C/S T.001 – Issue 4 – Rev. 6

May 2020


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



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:


• 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:





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 C/S T.001 – Issue 4 – Rev. 6

May 2020

Figure A9: National Location Protocol

1

24→

25

26

27

36→

37

40→|41 85→

|

86

106→

107

112

113

132→

133

144→

------ 61 BITS -----→

PDF-1

BCH-1 ------ 26 BITS -----→

PDF-2

BCH-2

P

R

E

A

M

B

L

E

2 10 4 45 21 6 7 7 6 12

F

O

R

M

18 BITS

IDENTI-

FICATION

27 BITS

LATITUDE

LONGITUDE

S

U

P

LATITUDE

LONGITUDE

A

T

C

O

P

R

18 1 7 5 1 8 5 P

L

1 2 4 1 2 4 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 949. The RLS beacon TAC number or National RLS number series are

assigned as follows:

1000 series is reserved for EPIRBs (i.e. 1001 to 1949),

2000 series is reserved for ELTs (i.e. 2001 to 2949), and

3000 series is reserved for PLBs (i.e. 3001 to 3949).

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 949 (i.e., National RLS Numbers 920 to 949) are set aside for National Use by

Competent Authorities. That is full National RLS Numbers 1920 to 1949 for EPIRBs, 2920 to 2949 for ELTs,

and 3920 to 3949 for PLBs.

A-32 C/S T.001 – Issue 4 – Rev. 6

May 2020

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‡


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)



b) bits 76 to 85: longitude data (10 bits) with 30 minute resolution, including:

• bit 76: E/W flag (E=0, W=1)



* TAC numbers 950 to 959 are currently unallocated. † The RLS MMSI protocol option is not approved for use in beacons prior to [CSC-64 in November 2020 pending

Council approval]. ‡ 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.

A-33 C/S T.001 – Issue 4 – Rev. 6

May 2020


a) bits 107 and 108 Supplementary Data

(1) bits 107: encoded position data source



(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:

"01": GALILEO Return Link Service Provider

* 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

"10": GLONASS Return Link Service Provider

"00" and "11": Spares (for other RLS providers)

c) bits 115 to 123: latitude with 4 second resolution:


• bit 116 to 119: minutes (0 to 15) in 1 minute increments*



d) bits 124 to 132: longitude with 4 second resolution:


• bits 125 to 128: minutes (0 to 15) in 1 minute 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.

* 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

Figure A10: RLS Location Protocol

1

24→

25

26

27

36→

37

40→|41 85→

|

86

106→

107

114

115

132→

133

144→

------ 61 BITS -----→

PDF-1

BCH-1 ------ 26 BITS -----→

PDF-2

BCH-2

P

R

E

A

M

B

L

E

2 10 4 45 21 8 9 9 12

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

2 10 14 1 8 1 9

1 4 4 1 4 4

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” Fisrt 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 C/S T.001 – Issue 4 – Rev.6

May 2020

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, or ELT(DT) Location Test protocol when

bits 43 to 66 are encoded with either all ”0”s, or all “1”s;


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.


a) bits 67 to 75: latitude data (9 bits) with 30 minute resolution, including:

• bit 67: N/S flag (N=0, S=1)



b) bits 76 to 85: longitude data (10 bits) with 30 minute resolution, including:

• bit 76: E/W flag (E=0, W=1)



A-37 C/S T.001 – Issue 4 – Rev.6

May 2020


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

b) bits 109 to 112: encoded altitude

“0000”: altitude is less than 400 m (1312 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).

A-38 C/S T.001 – Issue 4 – Rev.6

May 2020

d) bits 115 to 123: latitude with 4 second resolution:


• bit 116 to 119: minutes (0 to 15) in 1 minute increments*



e) bits 124 to 132: longitude with 4 second resolution:




(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 “ZLR”, i.e, bits 115 to 132 are set to 000 10001 01001 01010).

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

* 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.

†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-39 C/S T.001 – Issue 4 – Rev.6

May 2020

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.

A-40 C/S T.001 – Issue 4 – Rev.6

May 2020

Figure A11: ELT(DT) Location Protocol

- END OF ANNEX A -

1

24→

25

26

27

36→

37

40→|41 85→

|

86

106→

107

114

115

132→

133

144→

----------- 61 BITS ------------→

PDF-1

BCH-1 ------- 26 BITS --------→

PDF-2

BCH-2

BIT & FRAME

SYNCHRONIZ.

PATTERNS

2 10 4 45 21 8 18 12

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

2 24 1 8 1 9

1 4

4

1 4

4

10

01

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”

B-1 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 002

Sequence Number 1

Beacon Model Number 1

Production Run Number 1

National Use Bits 00000000

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

0000

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

0001011001010101001001

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

| | |

---->|<------------- Bits 25 - 85 ------------------------------>|<---Bits 86-106---->|

45’0’| (Data bits) | (21 "0"s) |

m(X)=0101011011100110100000000100000000000010001000000010000000001000000000000000000000

g(X)= 1001101101100111100011

001101101010101010001100

1001101101100111100011

0100000111001101101111

1001101101100111100011

0001100011111100111100000

1001101101100111100011

01011100100000000000110

1001101101100111100011

001000100110011110010100

1001101101100111100011

0001001011111001110111000

1001101101100111100011

00001100101010010110110001

1001101101100111100011

01010001111100010100100

1001101101100111100011

001110001000010100011100

1001101101100111100011

01111001011100111111111

1001101101100111100011

01101001100000000111000

1001101101100111100011

01001000011001110110110

1001101101100111100011

00001011101010010101010000

1001101101100111100011

001000011111001011001101

1001101101100111100011

0001110010101100101110000

1001101101100111100011

01111110000000100100110

1001101101100111100011

01100111011000110001010

1001101101100111100011

01010101101000011010010

1001101101100111100011

001100000010010011000100

1001101101100111100011

01011011111101001001110

1001101101100111100011

001011001000111010110110

1001101101100111100011

001010010101110101010100

1001101101100111100011

001111100001001011011100

1001101101100111100011

01100011001011001111110

1001101101100111100011

01011101001111100111010

1001101101100111100011

001000010001101101100100

1001101101100111100011

0001111100001010000111000

1001101101100111100011

01100011001101110110110

1001101101100111100011

01011101000010010101010

1001101101100111100011

001000010111010100100100

1001101101100111100011

0001111010110011000111000

1001101101100111100011

01101110111111110110110

1001101101100111100011

01000110100110010101010

1001101101100111100011

22-bit remainder = 0001011001010101001001 | |

|<------ BCH ------>|

| (last 21 bits) |

Figure B1: Sample 21-Bit BCH Error-Correcting Code Calculation

B-4 C/S T.001 – Issue 4 – Rev. 6

May 2020

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: 4333.63' N

actual longitude: 001 28.85' E

latitude rounded to nearest 4' increment: 4332' N

longitude rounded to nearest 4' increment: 00128' E

binary message:

- Encoded Position Data Source is Internal bit 107: 1

- North latitude bit 108: 0

- Latitude 43 bits 109-115: 0101011

- Latitude 32' bits 116-119: 1000

- East longitude bit 120: 0

- Longitude 1 bits 121-128: 00000001

- Longitude 28' bits 129-132: 0111

- 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

| | |

---->|<---Bits 107-132------->|<-133-144->|

25’0’| (Data bits) | (12 "0"s) |

m(X)=10010101110000000000010111000000000000

g(X)=1010100111001

1111000000100

1010100111001

1011001111010

1010100111001

1101000011000

1010100111001

1111001000010

1010100111001

1011011110110

1010100111001

1111001111101

1010100111001

1011010001001

1010100111001

1110110000100

1010100111001

1000101111010

1010100111001

1000100001100

1010100111001

1000011010100

1010100111001

1011110110100

1010100111001

1010001101000

1010100111001

13-bit remainder = 0000101010001

| |

|<---BCH-->|

| (12 bits)|

Figure B2: Sample 12-Bit BCH Error-Correcting Code Calculation

B-6 C/S T.001 – Issue 4 – Rev. 6

May 2020

B3 SAMPLE Moffset CALCULATIONS AND CRC-CODE

FIGURE B3: SAMPLE MOFFSET CALCULATION

- END OF ANNEX B -

15 Hex ID: 193BFCE031BFDFF

CRC-polynomial : x16

+x15

+x2+1

CRC-16(193BFCE031BFDFF) = 0xB380

and Moffset=BIN2DEC(CRC-16(193BFCE031BFDFF)) mod 60 = 52

C-1 C/S T.001 – Issue 4 – Rev. 6

May 2020

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:

1) UTC + Moffset of 59 minutes - No RLM received;

2) No UTC + Moffset of 1 minute - UTC acquired at 2:34 - RLM received at 4:07;

3) UTC + Moffset of 17 minutes - No RLM received;

4) UTC + Moffset of 20 minutes - RLM received at 2:29; and

5) 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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 1

0:01 0:18

GNSS Receiver first

30 minute on period 0:30 0:47*

GNSS Receiver next turns on at 2

0:59 1:02

GNSS Receiver next turns off at 1:14 1:05


1:59 1:17



2:59 1:32



3:59 1:47



4:59 2:32

GNSS Receiver next turns off at 5:14 2:34†


5:59 3:01

GNSS Receiver next turns off at 6:00‡ 3:16


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 C/S T.001 – Issue 4 – Rev. 6

May 2020

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 1 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 2:17 1:20


GNSS Receiver next turns on at 3 3:17 2:20

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

GNSS Receiver next turns on at 4 4:17

GNSS Receiver next turns off at 4:32





GNSS Receiver next turns on at 7 ‡

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 C/S T.001 – Issue 4 – Rev. 6

May 2020

ANNEX D RLS IOC NOTICE

Information to be Included in the User Manual and to be Prominently Displayed as a

New Beacon Owner Opens the Packaging of an RLS-Capable Beacon

This beacon has the Return Link Service (RLS) feature. The RLS feature is an

indication on the beacon (see beacon user’s manual) 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, only the fact that the distress alert has been received 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. Because this RLS performance still is under

development, prior to around 2021 the acknowledgment to the beacon user may

take somewhat longer than 30 minutes in certain parts of the world. Alerting of the

distress to SAR authorities is independent of (and likely will occur before) the RLS

acknowledgment indication on the beacon. This 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).

You may visit the web page Countries Allowing RLS Beacons (https://cospas-

sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase) to learn the most

recent information about regional/global support for RLS.

Cospas-Sarsat strongly recommends that you register your beacon. It only is

possible to register a beacon in the registry operated by the country matching the

“country code” (generally matching the country of point of sale) electronically

programmed into the beacon (or the International Beacon Registration Database

(IBRD) (https://www.406registration.com/)) if the country uses it 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 Where to Register My Beacon

(https://www.406registration.com/countriessupported.aspx) to see where you can

register your beacon.

- END OF DOCUMENT-

https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-SAR-SDD.pdf

https://cospas-sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase

https://www.406registration.com/

https://www.406registration.com/

https://www.406registration.com/countriessupported.aspx

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: [email protected]

Website: http://www.406.org

mailto:[email protected]

http://www.406.org/

SPECIFICATION FOR COSPAS-SARSAT 406 MHz DISTRESS … · C/S T.001 Issue 4 – Revision 6 May 2020 -...

Documents

Transcript of SPECIFICATION FOR COSPAS-SARSAT 406 MHz DISTRESS … · C/S T.001 Issue 4 – Revision 6 May 2020 -...