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

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

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

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

205 KiB

Raw Blame History

title

description

sidebar

documentId

series

seriesName

documentType

isLatest

issue

revision

documentDate

originalTitle

T018: C/S T.018 - Issue 1 Rev.13

Official Cospas-Sarsat T-series document T018

badge

text	variant
T	note

T018

Technical

specification

true

October 2025

C/S T.018 - Issue 1 Rev.13

📋 Document Information

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

SPECIFICATION FOR SECOND-GENERATION COSPAS-SARSAT 406-MHz DISTRESS BEACONS C/S T.018 Issue 1 – Revision 13

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

Approved by CSC-57

Approved by CSC-58

Approved by CSC-59

Approved by CSC-60

Approved by CSC-61

Approved by CSC-62

Approved by CSC-63

Approved by CSC-64

Approved by CSC-65

Approved by CSC-66

Approved by CSC-67

Approved by CSC-69

Approved by CSC-71

Approved by CSC-73

TABLE OF CONTENTS Page History ....................................................................................................................................................... i Table of Contents ...................................................................................................................................... ii List of Figures ..................................................................................................................................... iv List of Tables ..................................................................................................................................... iv 1. Introduction ............................................................................................................1-1 1.1 Purpose ....................................................................................................................... 1-1 1.2 Scope .......................................................................................................................... 1-1 1.3 Type of Beacon .......................................................................................................... 1-2 1.4 Optional Features ....................................................................................................... 1-3 1.5 Additional Features .................................................................................................... 1-4 2. Technical Requirements ........................................................................................2-1 2.1 Beacon Functional Elements ...................................................................................... 2-1 2.1.1 Transmitter Notional Functional Block Diagram ..........................................2-1 2.2 Digital Message Generator ......................................................................................... 2-2 2.2.1 Burst Transmission Interval ...........................................................................2-2 2.2.2 Total Transmission Time ...............................................................................2-4 2.2.3 Direct Sequence Spread Spectrum .................................................................2-4 2.2.4 Preamble ........................................................................................................2-6 2.2.5 Digital Message .............................................................................................2-6 2.2.6 Message Content ............................................................................................2-6 2.2.7 In-Phase (I) and Quadrature-Phase (Q) Components ....................................2-7 2.3 Modulator and 406 MHz Transmitter ........................................................................ 2-9 2.3.1 Transmitted Frequency ..................................................................................2-9 2.3.2 Spurious Emissions ......................................................................................2-10 2.3.3 Modulation and Waveform ..........................................................................2-10 2.3.4 Voltage Standing-Wave Ratio .....................................................................2-11 2.3.5 Maximum Continuous Transmission ...........................................................2-11 2.4 Transmitter Power Output ........................................................................................ 2-11 2.4.1 Transmitter Rise Time .................................................................................2-11 2.4.2 Effective Isotropic Radiated Power (EIRP) .................................................2-11 2.4.3 Antenna Characteristics ...............................................................................2-12 2.5 406 MHz Homing Transmitter ................................................................................. 2-14 3. DIGITAL MESSAGE CONTENT .......................................................................3-1 3.1 Basic Structure ............................................................................................................ 3-1 3.2 Beacon Message Content – Main Field ...................................................................... 3-1 3.3 Beacon Message Content – Rotating Fields ............................................................... 3-7

3.4 Beacon Transmission Scheduling of Rotating Fields ............................................... 3-16 3.5 Beacon Message Content – Error Correcting Field .................................................. 3-17 3.6 Beacon Coding and Hex ID ...................................................................................... 3-18 3.7 Programming Adapters............................................................................................. 3-19 4. ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS ...................4-1 4.1 General ....................................................................................................................... 4-1 4.2 Thermal Environment................................................................................................. 4-1 4.2.1 Operating Temperature Range .......................................................................4-1 4.2.2 Temperature Gradient ....................................................................................4-1 4.2.3 Thermal Shock ...............................................................................................4-1 4.3 Mechanical Environment ........................................................................................... 4-2 4.4 Other Environmental Requirements ........................................................................... 4-3 4.5 Operational Requirements .......................................................................................... 4-3 4.5.1 Duration of Continuous Operation ................................................................4-3 4.5.2 Other Operational Requirements ...................................................................4-3 4.5.3 Radio-Locating Signal (for Homing and on-Scene Locating) .......................4-3 4.5.4 Beacon Self-Test Mode .................................................................................4-4 4.5.5 Encoded Position Data ...................................................................................4-6 4.5.6 Beacon Activation........................................................................................4-12 4.5.7 Beacon Activation Cancellation Function ...................................................4-14 4.5.8 Verification of Registration .........................................................................4-15 4.5.9 RLS Functions .............................................................................................4-15 4.5.10 Battery Status Indication ..............................................................................4-18 4.5.11 Beacon Labelling .........................................................................................4-19 4.5.12 Beacon Instruction Manual ..........................................................................4-19 4.5.13 Beacon Data Requirements ..........................................................................4-19 4.5.14 External Power Source for ELT(DT)s .........................................................4-19 4.5.15 ELT(DT)s Specifically Designed to Withstand a Crash Impact ..................4-20 4.5.16 ELT(DT)s Combined with Automatic ELTs ...............................................4-22 4.5.17 RLS Type 3 TWC (message) Functionality ................................................4-24 APPENDIX A - LIST OF ACRONYMS........................................................................................ A-1 APPENDIX B - SAMPLE BOSE-CHAUDHURI-HOCQUENGHEM ERROR- CORRECTING CODE AND 23 HEX ID CALCULATIONs ........................... B-1 B.1 Sample 48-Bit BCH Code Calculation ...................................................................... B-1 B.2 Sample 23 Hex ID Calculation .................................................................................. B-6 APPENDIX C - BEACON ENCODED LOCATION CODING ................................................... C-1 C.1 ENCODED LOCATION PROTOCOL .................................................................... C-1 C.2 Summary ................................................................................................................... C-1 C.3 Default Values in Position Data ................................................................................ C-1 C.4 Definition of Location Data Fields ............................................................................ C-2

C.4.1 Encoded Location field ................................................................................. C-2 C.4.2 Encoded Location Data (1) ............................................................................ C-2 C.5 Instructions for converting Latitudes and Longitudes to a Binary Number .............. C-3 APPENDIX D - EXAMPLE OF LINEAR FEEDBACK SHIFT REGISTER (LFSR) IMPLEMENTATION ........................................................................................... D-1 APPENDIX E - BIT ASSIGNMENT NUMBERS ........................................................................ E-1 APPENDIX F - MOFFSET CALCULATIONS AND CRC CODE SAMPLE ................................ F-1 APPENDIX G - EXAMPLES OF RLS GNSS RECEIVER TIMING ....................................... G-1 APPENDIX H - RLS INFORMATION ........................................................................................ H-1 APPENDIX I - BASIC BEACON PROGRAMMING GUIDANCE ............................................ I-1 LIST OF FIGURES Figure 2-1: Notional DSSS-OQPKS Transmitter Functional Block Diagram .....................................2-2 Figure 2-2: Linear Feedback Shift Register ..........................................................................................2-5 Figure 2-3: Burst general structure .......................................................................................................2-7 Figure 2-4: I and Q Component Message Structure .............................................................................2-8 Figure 2-5: Spurious emission mask ...................................................................................................2-10 Figure 2-6: OQPSK modulation illustration .......................................................................................2-11 Figure 2-7: Ideal Antenna Pattern .......................................................................................................2-12 Figure 3-1: Message content bits ..........................................................................................................3-1 Figure 4-1: Temperature Gradient ........................................................................................................4-2 Figure 4-2: RF#4 bit assignment representation with the FLAM in the case where the bit 14 (Answer Format Flag) is 0 (Short) ............................................................................................4-29 Figure 4-3: RF#4 bit assignment representation with the FLAM in the case where the bit 14 (Answer Format Flag) is 1 (Long) ............................................................................................4-29 Figure B-1: Sample 48-Bit BCH Error-Correcting Code Calculation ................................................. B-5 Figure D-1: Example of LSFR with the generation of the 64 first chips of the normal I-component . D-2 Figure F-1: Example of calculation of Moffset ....................................................................................... F-1

LIST OF TABLES Table 2.1: Transmission Schedule ........................................................................................................2-4 Table 2.2: PRN Sequence Initialization Values ....................................................................................2-6 Table 2.3: Logic to Signal Level Assignment .......................................................................................2-6 Table 2.4: Bit to PRN Sequence Assignment .......................................................................................2-9 Table 2.5: Required EIRP ...................................................................................................................2-12 Table 3.1: Minimum Requirement main field in the beacon message (transmitted in every burst) ....3-2 Table 3.2: Modified Baudot Code.........................................................................................................3-7 Table 3.3: C/S G.008 Objective Requirements Rotating Field (#0) .....................................................3-8 Table 3.4: ELT(DT) In-Flight Emergency Rotating Field (#1) ..........................................................3-10 Table 3.5: RLS Type 1 Automatic and Type 2 Manual Acknowledgment Rotating Field (#2) .........3-11 Table 3.6: National Use Rotating Field (#3) .......................................................................................3-12 Table 3.7: RLS Type 3 TWC (Message) Rotating Field (#4) .............................................................3-13 Table 3.8: Spare Rotating Fields (for future use) (#5 - #14) ...............................................................3-15 Table 3.9: Cancellation Message Rotating Field (#15) .......................................................................3-15 Table 3.10: Rotating Field Transmission Conditions .........................................................................3-16 Table 3.11: Hex ID Contents ..............................................................................................................3-18 Table 4.1: Expected Stand-alone ELT(DT) Behaviour ......................................................................4-12 Table 4.2: Expected Crash Survivable ELT(DT) Behaviour ..............................................................4-20 Table 4.3: Expected ELT(DT) Combined with Automatic ELT Behaviour .......................................4-22

1-1

INTRODUCTION 1.1 Purpose The purpose of this document is to define the minimum requirements to be used for the development and manufacture of Second Generation 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. 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: a) Section 2 gives the technical 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. b) Section 3 deals with the beacon message content. Basic message structure as well as the assignment and meaning of the available data bits are defined in this section. c) 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. d) Appendix A provides a list of acronyms used in this document. e) Appendix B provides a sample Bose-Chaudhuri-Hocquenghem error-correcting code calculation. f) Appendix C provides an example of beacon encoded location coding. g) Appendix D provides an example of the first 64 bits of a Linear Feedback Shift Register (LFSR) Implementation. h) Appendix E provides a map of the BIT assignment numbers. i) Appendix F provides an Moffset calculation and CRC code sample.

1-2

1.3 Type of Beacon There are four different types of Cospas-Sarsat 406 MHz beacons; Emergency Locator Transmitters (ELTs), Emergency Position Indicating Radio Beacons (EPIRBs), Personal Locator Beacons (PLBs) and Ship Security Alert System (SSAS) Beacons. This standard does not address requirements for Second Generation SSAS Beacons. In addition to the four different types of beacon there are up to three Classes of operating temperature range for 406 MHz beacons as follows: Class 0: -55°C to +70°C Class 1: -40°C to +55°C Class 2: -20°C to +55°C Any type of beacon can be supplied with a Class 0, Class 1 or Class 2 operating temperature range. Unless otherwise stated herein this specification applies to all types and classes of 406 MHz beacons identified in this section apart from SSAS beacons. Emergency Locator Transmitters (ELTs) Are designed for aviation distress purposes and are available as the following types; Automatic Fixed (ELT (AF)), Automatic Portable (ELT (AP)), Survival (ELT (S)), Automatic Deployable (ELT (AD)), and Distress Tracking ELT (ELT (DT)). Automatic Fixed (ELT (AF)) This type of ELT is intended to be permanently attached to the aircraft before and after a crash and is designed to aid SAR teams in locating a crash site. Automatic Portable (ELT (AP)) This type of ELT is intended to be rigidly attached to the aircraft before a crash, but readily removable from the aircraft after a crash. It functions as an ELT (AF) during the crash sequence. If the ELT does not employ an integral antenna, the aircraft-mounted antenna may be disconnected and an auxiliary antenna connected in its place. This type of ELT is intended to aid SAR teams in locating the crash site or survivor(s). Survival (ELT (S)) This type of ELT is intended to survive the crash forces, and then to be generally manually activated by survivors. There are two sub categories of ELT(S) Category A which is buoyant and designed to operate when floating in water and Category B which is non buoyant and may be manually or automatically activated. This type of ELT is intended to aid SAR teams in locating survivor(s).

1-3

Automatic Deployable (ELT(AD)) This type of ELT is intended to be rigidly attached to the aircraft before a crash and automatically deployed after the crash sensor has determined that a crash has occurred. This type of ELT should float in water and is intended to aid SAR teams in locating the crash site. Distress Tracking (ELT (DT)) This is 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. It may be activated automatically upon detection of a distress condition while in-flight or it may also be activated manually. Emergency Position Indicating Radio Beacons (EPIRBs) Are designed for maritime distress purposes and are available as Float free and Non Float Free types of EPIRB. Float Free EPIRB This type of EPIRB is intended to float free of the vessel on which it is fitted if the vessel sinks, in which case it will automatically activate, it can also be manually activated. Non Float Free EPIRB This type of EPIRB is intended to be manually released from its mounting bracket and then either manually activated or dropped in the water so that it will then activate automatically. Some national administrations permit the use of manually activated EPIRBs only without the automatic activation in water feature. Personal Locator Beacons (PLBs) Are designed for use by persons in distress who may be on land, in the air or at sea. 1.4 Optional Features Beacons may contain optional features that are defined in this specification. Encoded location capability is optional, however in the case of ELT (DT) devices intended for in-flight automatic activation the inclusion of a GNSS capability is mandatory. All types of beacons (except current ELT(DT)s) may also be provided with the Return Link Service capabilities (e.g., RLS Type 1 automatic acknowledgement and/or RLS Type 3 two-way communication (message) service capability). All types of beacons may be provided with one or more additional radio-locating transmitters for Homing and On-scene Locating purposes.

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

1-4

1.5 Additional Features Beacons may contain additional functionality that may change the transmitted 406 MHz satellite signal or affect other beacon parameters such as operating lifetime. For example, a beacon may contain a flashing strobe light that while it probably has no effect on the transmitted signal, would reduce the battery life. Any additional functionality that is not defined in this specification shall not adversely degrade the performance of the beacon to the extent that it no longer complies with this specification.

END OF SECTION 1 -

2-1

TECHNICAL REQUIREMENTS 2.1 Beacon Functional Elements This section defines requirements for the functional elements of spread-spectrum 406 MHz distress beacons. 2.1.1 Transmitter Notional Functional Block Diagram This section contains a notional functional diagram which describes the features which are described in greater detail by later sections of this document. Figure 2-1 illustrates a notional Direct Sequence Spread Spectrum - Offset QPSK (DSSS-OQPSK) high level transmitter functional block diagram which may be used to better understand one possible implementation of the beacon signal design. In this figure: • D(t) is the linear bit stream for each beacon burst running at 300 bits/second. • D(t) is split into parallel bit streams Ib(t) and Qb(t) made up of odd and even bits from D(t) running at 150 bps each • A Linear Feedback Shift Register (LFSR) function produces the two different chipping segments Ci(t) and Cq(t) using the common generator polynomial G(X). Each chipping segment runs at 38,400 chips/second. Each of Ci(t) and Cq(t) is produced by the LFSR function using the specified unique I or Q channel LFSR initialization, and is reproduced identically for each beacon burst for a given beacon mode of operation. • Ib(t) and Qb(t) are separately mixed with their respective different chipping segments. The resultant on each channel can change state every chip period. • The resultant of the mixing on the Q component is then delayed by ½ chip period. • Both I and Q channels may then be low pass filtered (if necessary) and modulated onto cosine and sine sinusoids. • The two modulated sinusoids are then summed. • The summation resultant is amplified, band pass filtered (if necessary), and then transmitted as the outgoing beacon burst signal S(t). Because the I and Q resultants are offset by ½ chip period from each other, when summed, the resulting signal S(t) is bounded to a maximum phase shift of 90 degrees to help minimize amplitude envelope variation.

2-2

Figure 2-1: Notional DSSS-OQPKS Transmitter Functional Block Diagram 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. This section describes the structure of the proposed signal. 2.2.1 Burst Transmission Interval From beacon activation a total of 6 initial transmissions shall be made separated by fixed* 5s +0 /-0.2s intervals. The first transmission shall commence within 5 seconds of beacon activation†, except for EPIRBs, where it shall commence within 8 seconds of beacon activation. The beacon shall then transmit 59 bursts at nominally 30 second intervals. The time between the start of two successive transmissions (TR) shall be randomized with uniform (flat) distribution around the stated nominal value, so that intervals between the start of two successive transmissions are randomly distributed over ± 5 seconds. The standard deviation over the 59 successive bursts of TR shall be greater than 2.5 seconds. The minimum value of TR observed over the 59 successive bursts shall be

In this context, “fixed” refers to a repetition period which may vary within the tolerances allocated, and that no deliberate randomization within this range is required. † Beacon activation is defined as the point in time at which the initiation of the activation event of the beacon occurs. E.g., the activation events include pressing of the “ON” button, water sensor immersion, the start of a shock, or deformation.

2-3

between 25.0 and 25.2 seconds, the maximum value of TR observed over the 59 successive bursts shall be between 34.8 and 35.0 seconds. Transmissions shall then occur at nominally 120 second intervals. The time between the start of two successive transmissions (TR) shall be randomized with uniform (flat) distribution around the stated nominal value, so that intervals between the start of two successive transmissions are randomly distributed over ± 5 seconds. The standard deviation over the first 50 successive bursts of TR shall be greater than 2.5 seconds. The minimum value of TR observed over the 50 successive bursts shall be between 115.0 and 115.2 seconds, the maximum value of TR observed over the 50 successive bursts shall be between 124.8 and 125.0 seconds. For ELT DT transmission the first transmission shall commence within 5 seconds of beacon activation. From beacon activation a total of 24 initial transmissions shall be made separated by fixed* 5 seconds + 0.0 / - 0.2 intervals. These transmissions shall be followed by 18 transmissions separated by fixed 10 seconds + 0.0 / - 0.2. After the first 42 transmissions, ELT (DT) transmissions shall continue at nominal intervals of 28.5 seconds until the end of the ELT (DT) operating lifetime. The time between the start of two successive transmissions (TR) shall be randomized with uniform (flat) distribution around the stated nominal value, so that intervals between the start of two successive transmissions are randomly distributed over ± 1.5 seconds. The standard deviation over the first 73 successive bursts of TR shall be greater than 0.8 seconds. The minimum value of TR observed over the 73 successive bursts shall be between 27.0 and 27.2 seconds, the maximum value of TR observed over the 73 successive bursts shall be between 29.8 and 30.0 seconds. For RLS Type 3 two-way communication (TWC) (message) capable beacons, from beacon activation a total of 6 initial transmissions shall be made separated by fixed 5s +0 /-0.2s intervals. The first transmission shall commence within 5 seconds of beacon activation, except for EPIRBs, where it shall commence within 8 seconds of beacon activation. The beacons with RLS Type 3 TWC functionality shall then transmit 119 bursts at nominally 30 second intervals. The time between the start of two successive transmissions shall be randomized with uniform distribution around the stated nominal value, so that intervals between the start of two successive transmissions are randomly distributed over ± 5 seconds. Transmissions shall then occur at nominally 120 second intervals. The time between the start of two successive transmissions (TR) shall be randomized with uniform (flat) distribution around the stated nominal value, so that intervals between the start of two successive transmissions are randomly distributed over ± 5 seconds. The transmission schedule is summarized in Table 2.1.

In this context, “fixed” refers to a repetition period which may vary within the tolerances allocated, and that no deliberate randomization within this range is required.

2-4

Table 2.1: Transmission Schedule IAMSAR Stage Nominal Time from Activation Transmission Nominal Repetition Interval Randomization Initial 0 to 30* Seconds 5 Seconds

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

120 to 300 Seconds 10 Seconds

300 Seconds + 28.5 Seconds ± 1.5 Seconds RLS Type 3 Two- Way Communication (Message) service 0 to 30* Seconds 5 Seconds

30* Seconds to 60 minutes 30 Seconds ± 5 Seconds 60 minutes + 120 Seconds ± 5 Seconds 2.2.2 Total Transmission Time The total transmission time of each burst, measured at the 90 percent power points, shall be 1000 ms ±1 ms. 2.2.3 Direct Sequence Spread Spectrum The digital message shall be spread using two truncated segments of a common PRN (Pseudo- Random Noise) maximum length sequence (m-sequence) producing symbols known as "chips". These sequence segments shall be deterministic and must be known by the receiver. The two truncated spreading PRN segments shall: a) be applied separately to the full duration of each beacon burst transmission with one segment applied to the in-phase (I) component and the other applied to the quadrature (Q) component of the signal; b) be transmitted as separate odd and even bits, starting with 1 as the first bit. Odd bits are transmitted through the I channel and even bits the Q channel. For each bit, 256 chips are taken from the PRN sequence such that a 0 bit is represented by the non-inverted sequence and a 1 by the inverted sequence, equivalent to an exclusive-OR operation (XOR). The I and Q signal components are spread separately, each by a factor of 256 (with half-chip offset as shown in section 2.3.3). Then when the I and Q channels are combined the overall spreading factor is 128 chips/bit. c) be generated by a method equivalent to a Linear Feedback Shift Register (LFSR) using the same generator polynomial G(x) = X23 + X18 +1 (see Figure 2-2); d) be generated in matched pairs for the I and Q components defined in Table 2.2 for each beacon mode;

For EPIRBs this value is 33 seconds.

2-5

e) be truncated to the first 38,400 chips of the m-sequence generated using the prescribed initialization values for each of the I and Q components with a 1/2 chip period delay imposed on the Q component relative to the I component (refer to section 2.3.3); f) be applied to both I and Q components for the full one second duration of each beacon burst transmission including preamble, information bits, and error correction bits, to give a chipping rate of 38,400 chips/second for each component (see 2.3.1.2 for further details); and g) be identical for each beacon burst transmission for any given burst mode. Note that this spreading scheme method in fact allows for multiple possible non-overlapping matched I and Q component chipping segment pairs, with each segment in each pair truncated to 38,400 chips. The number of possible segments, 218, is determined by dividing the full m-sequence length for the generator polynomial, by the truncated segment length, ((223)-1)/38,400 = 218 segments. Non-overlapping pairs of segments can be selected from this set of 218 segments. X22 X21 X17 X20 X19 X18 X16 ... X1 X0 + + Data in Linear Feedback Shift Register for X23+X18+1: (1) X0 Ꚛ data output (2) X0 Ꚛ X18→ temp (3) Shift Xn→ Xn-1 Ɐ n (4) temp→ X22 Figure 2-2: Linear Feedback Shift Register The beacon shall be able to generate multiple PRN sequences segments, such as normal mode and self-test mode, according to Table 2.2. In order to generate these PRN sequences segments, the beacon may use a LFSR with multiple initialization values for PRN sequence segment generation. Table 2.2 provides the generator polynomial initialization LFSR values for I and Q components for beacon normal mode operation and for beacon self-test mode operation. In this table, registers are labelled from 0 to 22. The registers shift from left to right the output from register 0. For clarity, the feedback taps to be XOR’d are indicated in the table and match with the characteristic polynomial. The output chip is taken from register 0. The table also provides the first 64 chips in the order of generation from the LFSR. The 64 chip binary sequence has been displayed in hexadecimal format as demonstrated in the example below the table with the leftmost chip in sequence being the first output. The LFSR implementation (with associated initialization) leads to the correct generation of the whole 38 400 chips sequence, which can be verified to a high degree of confidence by confirming a perfect match of the first 64 chips given in Table 2.2.

2-6

Table 2.2: PRN Sequence Initialization Values Register 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 XOR

1 Output chip sequence Register Initial Setting 1st 64th Normal I

0 0 0 0 0 0 0 0 0 0 1 → 8000

4212 84A1 Normal Q

0 0 1 1 1 1 1 1 1 0 0 → 3F83 58BA D030 F231 Self Test I

0 0 1 1 1 1 1 0 0 0 0 → 0F93 4A4D 4CF3 028D Self Test Q

0 0 1 0 0 1 0 1 0 0 0 → 1497 3DC7 16CD E124 An example of the generation of the 64 first chips of the normal I-component is given in Appendix D. The correspondence between the logic level of the chips used to modulate the signal and the signal level is given in Table 2.3: Table 2.3: Logic to Signal Level Assignment Logic Level Signal Level

-1.0

+1.0 2.2.4 Preamble The initial 166.7 ms of the transmitted signal shall consist of the combination of the first 6400 chips of the two PRN code segments (each segment 38,400 chips long for the entire burst) used to spread the I and Q message components as illustrated in Figure 2-3. There will be no useful information encoded on either the I or Q components during the preamble. I and Q component information bits shall all be set to ‘0’ during the preamble. 2.2.5 Digital Message The remaining 833.3 ms of the transmitted signal shall contain a 250-bit message and will be at a nominal bit rate of 300 bps. 2.2.6 Message Content The content of the 250 bit message is defined in section 3. The 250 bit message is composed of two parts: a) the useful message: 202 bits containing the information transmitted by the beacon. b) the error correction bits: 48 bits BCH(250,202) containing bits used for error correction at reception.

2-7

Preamble Correcting bits Useful message 166.7 ms 673.3 ms 160 ms 1s Figure 2-3: Burst general structure 2.2.7 In-Phase (I) and Quadrature-Phase (Q) Components The odd bits of the 250-bit message are used to generate the in-phase (I) component of the message, while the even bits are used to generate the quadrature-phase (Q) component of the message. The bit rate for each channel will nominally be 150 bits/sec. Each component starts with a 6400 chip preamble described in section 2.2.4 and is spread with the PRN code segment described in section 2.2.3 as shown in Figure 2-4.

2-8

Figure 2-4: I and Q Component Message Structure*

The 50 bits included in the preamble contain no data and are set to “0”

2-9

The preamble and any bits allocated as ‘0’ are represented by the PRN sequence, and bits allocated as ‘1’ are sent as the PRN sequence inverted for the duration of the bit as shown in Table 2.4. This is the method of modulating data onto the PRN sequence. Table 2.4: Bit to PRN Sequence Assignment Bit PRN Sequence

Inverted

Normal 2.3 Modulator and 406 MHz Transmitter 2.3.1 Transmitted Frequency The following sections define the frequency stability requirements for the Carrier Frequency and the Chip Rate. The specifications for the carrier frequency and the chip rate may be decoupled by using separate oscillators. 2.3.1.1 Carrier Frequency Offset/Drift over aging, thermal, shock and vibration a) Long Term Stability Requirement The carrier frequency tolerance shall be 406.05 MHz ±1200 Hz over 5 years or the manufacturers’ declared beacon maintenance period*, whichever is greater; and b) Short Term Stability Requirement This requirement applies throughout the operating temperature range and during situations of temperature shock. The maximum allowable carrier frequency variation shall be 7.4 ppb when measured over 166.7 msec within the burst. 2.3.1.2 Chip Rate Accuracy and Variation The average chip rate shall be 38 400 ± 0.6 chips/s. The variation of the chip rate shall be ± 0.6 chips/s². These values shall be met both when measuring over the preamble and on the entire burst.

The beacon maintenance should include validation of the frequency stability of the beacon.

2-10

2.3.2 Spurious Emissions The in-band spurious emissions shall not exceed the levels specified by the signal mask in Figure 2-5, when measured in a 100 Hz resolution bandwidth. Figure 2-5: Spurious emission mask Furthermore, out of band emissions must be limited to less than 1% of the total transmitted power*. 2.3.3 Modulation and Waveform The RF modulation is Offset Quadrature Phase Shift Keying (OQPSK). The PRN sequences for the in-phase (I) and quadrature (Q) components of the signal are defined in section 2.2.3. The chips of the I and Q components shall have an average offset of half a chip period ± 1% of the chip period over the entire burst with I leading Q by one-half a chip period. In the constellation diagram shown below, it can be seen that this will limit the phase-change to no more than 90° at a time. The peak to peak amplitude of the I and Q components shall be on average within 15% of each other over the entire burst. The Error Vector Magnitude (EVM) of the constellation points away from ideal, measured at symbol level, shall be less than 2.5 % when measured over the entire burst. Acceptable types of filters that may be used to produce an output waveform include half-sine (i.e., IEEE 802.15.4, Section 12.2.6), or root-raised cosine ([0.8 +/- TBD] roll-off factor may be used). If other output filters are being considered for use, the Cospas-Sarsat Secretariat must be consulted in advance so that they can consult with the Parties regarding the filter’s acceptability. The figure below illustrates the OQPSK modulation mid-burst including the one-half chip delay on the Q channel. In this figure, T represents the chip period.

The 1% out of band emission is extracted from the recommendation ITU-R SM.1541-4, article 1.153

2-11

In-Phase Component (I) Quadrature Component (Q) T T/2 Figure 2-6: OQPSK modulation illustration 2.3.4 Voltage Standing-Wave Ratio The modulator and 406 MHz transmitter shall be able to meet all requirements within this standard at any VSWR between 1:1 and 3:1, and shall not be damaged by any load from open circuit to short circuit. 2.3.5 Maximum Continuous Transmission The distress beacon shall be designed to limit any inadvertent continuous 406 MHz transmission to a maximum of 45 seconds. 2.4 Transmitter Power Output 2.4.1 Transmitter Rise Time The transmitter RF output power shall not exceed -10 dBm prior to 25 ms before the commencement of, or 25 ms after the end of, any 406 MHz burst. Power output rise time shall be less than 0.5 ms measured between the 10% and 90% power points. Preamble content shall be transmitted during the power rise time. Power output fall time shall be less than 0.5 ms between the 90% and the 10% power points. Between 25 ms after the end of any 406 MHz burst until 25 ms before the commencement of the next 406 MHz burst the power level in the 406.0 to 406.1 MHz frequency band shall not exceed -10 dBm. 2.4.2 Effective Isotropic Radiated Power (EIRP) Power output is defined in terms of EIRP, not power into a 50-ohm load. Required EIRP varies with elevation angle according to the table below. Greater than 65% of measured EIRP values shall meet the limits shown. In addition, 90% of the measured EIRP values shall meet the limits shown at

2-12

elevation angles below 55 degrees, except for ELT(DT)s, or ELTs used in combination with automatic deployable flight recorders. Table 2.5: Required EIRP Elevation (°)

Max dBm 45

Min dBm

The horizontal (azimuth) antenna pattern should be substantially omnidirectional and shall remain within the minimum and maximum values of EIRP provided in the above table. Power output shall be maintained within the above limits throughout the minimum operating lifetime of the beacon at any temperature throughout the operating temperature range. Changes in beacon output power due to for example temperature and operation over the beacons minimum lifetime when operating into a 50-ohm test load shall be taken into account during determination of compliance with the minimum and maximum EIRP limits. 2.4.3 Antenna Characteristics Antenna polarization shall be either circular (RHCP) or linear. Antenna pattern should be hemispherical and should include coverage at high elevation angles, subject to the EIRP limits given in section 2.4.2 (effective isotropic radiated power). An ideal antenna pattern is shown below for illustration purposes. Remote antennas or detachable antennas shall always be approved with a beacon. The following different types of antenna may be specified for use with a 406 MHz beacon: External Antenna An antenna that is external to the casing of the beacon and that is permanently attached to the beacon and that cannot be removed by the user.

Example antenna min max Figure 2-7: Ideal Antenna Pattern

2-13

Detachable Antenna An antenna that is external to the casing of the beacon and that is attached directly to the beacon by such means as an RF connector without any intermediate cable which can be removed and replaced by the user. Detachable antennas when measured directly at the antenna feed point shall achieve a VSWR not greater than 1.5:1 referred to 50Ω. Internal Antenna An antenna that is contained within the case of the beacon where the user has no access to the antenna. Remote Antenna An antenna that is external to the casing of the beacon and which is remote from the beacon, being attached to it by means of an RF cable. The antenna and the RF cable may be permanently attached to the beacon (in this case the type and length of the antenna cable is fixed and is as supplied by the beacon manufacturer) or one or both parts (antenna or cable) may be varied by the user or the installer (in this case the type and length of the antenna cable may vary). In either case, remote antennas, when measured directly at the antenna feed point, shall achieve a VSWR not greater than 1.5:1 referred to 50Ω. Remote Antenna without an Integrated Cable In this configuration (e.g., an ELT installed in an aircraft) there may be more than one type of approved antenna and the length and type of cable between the antenna and beacon may vary. The characteristic impedance and minimum and maximum loss of the antenna feed cable shall be specified by the beacon manufacturer. The combined beacon, antenna and cable shall meet the EIRP requirements in section 2.4.2 (effective isotropic radiated power) when operating with the minimum and maximum stated cable loss between the antenna and the beacon. Remote Antenna with an Integrated Cable In this configuration (e.g., a military PLB with a body worn antenna) the antenna and cable combination is fixed and supplied by the beacon manufacturer (although there maybe more than one approved combination for different applications) and the length and type of cable between the antenna and beacon cannot be changed. This combination utilising a specific manufacturer supplied integrated antenna cable shall be tested with that cable. All antennas and cabling arrangements to be approved with a beacon shall be specified by the manufacturer and shall meet all the requirements of section 2.4.

2-14

2.5 406 MHz Homing Transmitter The distress beacon may transmit a 406 MHz Homing signal as defined in this section*. However ELT (DT)s are not required to provide a 406-MHz homing signal.

END OF SECTION 2 -

A CW unmodulated 406-MHz homing and on-scene locating signal is under development with details to be provided in a future update to T.018 and will be centered at 406.050 MHz, ± 2 kHz, at a power level, repetition rate, and pulse width to be determined.

3-1

DIGITAL MESSAGE CONTENT 3.1 Basic Structure The digital message which is transmitted by the 406 MHz beacon consists of: a) 202 information bits; and b) 48 bits for BCH (250,202) error correction. The 202 information bits are further divided into: • 154 bits within the main data field (transmitted in every burst), • 48 bits within a rotating data field (may be 1 of 16 different content types). Message content structure is shown in Figure 3-1 below. Data transmission starts with bit 1, the left-hand (most significant) bit of the 154 bit main field. 202 information bits 48 error correction bits 154 bit main field 48 bit rotating field 48 bit BCH field Main Message Spare

…

….……

…………….

Figure 3-1: Message content bits 3.2 Beacon Message Content – Main Field The main field provides for the minimum requirements of document C/S G.008 using sub-fields as shown in Table 3.1 below. Note: additional coding guidance is included in Appendix I. Unless stated otherwise all sub-fields are separately binary encoded, with the Least Significant Bit to the right (i.e., the highest numbered bit in that particular message field).

3-2

Table 3.1: Minimum Requirement main field in the beacon message (transmitted in every burst) C/S G.008 reqmt Para. Description Number of bits Bit numbers in message Content 3.7.1a TAC Number

1-16 (MSB=1) 16-bit TAC # (0 to 65,535)*† 3.7.1a Serial Number

17-30 14-bit serial number (0 to 16,383)* 3.7.1a Country code

31-40 (MSB= 31) A three-digit decimal country code number (0 to 999). Allowable Country codes are those provided in the International Telecommunication Union (ITU) Maritime Identification Digit (MID) country code list available on the ITU website: (https://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/mid .aspx). 3.7.1d Status of homing device

On beacon activation a ‘1’ indicates that the beacon is equipped with at least one homing signal and a ‘0’ indicates that the beacon is not equipped with any homing signals or that they have been deliberately disabled. Once the homing signal in the beacon has been activated, a ‘1’ indicates that at least one homing device is functional and transmitting. A ‘0’ indicates that no homing device is functional, or it has been deliberately disabled. RLS function(s)

A ‘0’ indicates a beacon without RLS capability or with this capability disabled. A ‘1’ indicates a beacon with RLS capability enabled (e.g., RLS Type-1 automatic acknowledgement, RLS Type-2 manual acknowledgement, or RLS Type 3 two- way communication (message) service). N/A Test Protocol

A ‘0’ indicates normal beacon operation. A ‘1’ indicates a Test Protocol message for non-operational use. Selection of test protocol is not an end-user capability.

The TAC and serial number combination shall be unique (see section 3.6). † TAC value range 65,521 - 65,535 is reserved for System beacons (e.g., reference and QMS beacons, calibration beacon, simulators, etc.) – See document C/S T.022.

3-3

C/S G.008 reqmt Para. Description Number of bits Bit numbers in message Content 3.7.1g Encoded GNSS location

(MSB= 45, 52, 68, 76)

45-51 52-66

68-75 76-90 Location* is provided to 3.4 m resolution max in the following order: N/S flag (N=0, S=1); Degrees (0 to 90) in 1-degree increments; Decimal parts of a degree (0.5 to 0.00003); (Default value of bits = 0 1111111 000001111100000). If the beacon does not have encoded location capability†, then these bits shall be set to the following default value: Bits = 1 1111111 000001111100000. E/W flag (E=0, W=1); Degrees (0 to 180) in 1-degree increments; Decimal parts of a degree (0.5 to 0.00003); (Default value of bits = 0 11111111 111110000011111). If the beacon does not have encoded location capability†, then these bits shall be set to the following default value: Bits = 1 11111111 111110000011111. 3.7.1h Vessel ID

91-93 A three-digit binary field identifier is first transmitted to identify the following message content: 000 - No aircraft or maritime identity (may be defined for national use‡; default content for bits 94-137 is all 0’s); 001 – Maritime MMSI and/or AIS Identity; 010 – Radio call sign; 011 – Aircraft Registration Marking (Tail Number); 100 – Aircraft aviation 24 Bit Address; 101 – Aircraft operator and serial number; 110 – Spare; 111 – Reserved for System Testing (may contain

All position information is encoded as degrees and decimal parts of a degree, or as fractions of these units to be as close as possible to the actual position. 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. † If a beacon model has an external navigation input capability but is installed in a configuration in which a navigation signal will never be supplied to the interface (i.e., an ELT in a GA aircraft which cannot supply the navigation signal to the beacon), then this (no capability) is the preferred default that should be used under those circumstances. However, if the external navigation connection in the installed configuration is uncertain, then the alternate default (no position available at this time) should be used. ‡ The information contained in this field shall be static even when defined for national use, otherwise the 23-Hex ID will be affected, and such a beacon would need to be considered under of letter of compatibility (LoC).

3-4

C/S G.008 reqmt Para. Description Number of bits Bit numbers in message Content Vessel ID (continued)

94-123 124-137 94-137 additional information; default content for bits 94-137 is all 0’s)*. This is followed by the vessel or aircraft identity. The following coding schemes are permitted: 1 - Maritime Mobile Service Identity: A unique ship station identity in the format M1I2D3X4X5X6X7X8X9 where MID indicates the flag state of the vessel and XXXXXX is the unique vessel number in accordance with ITU-R M.585 Annex 1 Section 1 encoded as a 9-digit number in binary format or for Craft Associated with a Parent Ship a unique identification in the format 98MIDXXXX where MID represents the administration having jurisdiction over the identity for the craft associated with a parent ship and XXXX represents a unique number assigned by the administration for that craft in accordance with ITU-R M.585 Annex 1 Section 5 encoded as a 9-digit number in binary format. If no MMSI is available, then insert the default decimal number 000111111. AIS Identity: If the beacon includes an AIS transmitter, then its identity is inserted in the message here (Note that depending on the type of beacon and national coding regulations the MMSI preceding this identity may contain default data). The Freeform Maritime Identity for the AIS transmitter has the format 9172A3X4X5Y6Y7Y8Y9† in accordance with ITU-R M.585 Annex 2 Section 2 where only the last 4 digits (Y6Y7Y8Y9) are encoded here as a number in binary format. If there is no AIS device, then insert the default binary number 10101010101010 (10922). 2 - Radio call sign: Is encoded using the modified-Baudot code shown in Table 3.2. This code enables 7 characters to be encoded using 42 bits (6x7=42), 94 to 135 (1 to 42 within the field). Two bits (136 and 137 (43 and 44 within the field)) are spare and shall be coded as 00. The modified-

This value is invalid when the test protocol flag, bit-43, is set to ‘0’. † The “A” represents the device type (e.g., 0 = AIS SART, 2 = MOB, and 4 = EPIRB) and “XX” represents the manufacturers ID, and “YYYY” is a manufacturer assigned serial number associated with the device.

3-5

C/S G.008 reqmt Para. Description Number of bits Bit numbers in message Content Vessel ID (continued)

94-137 94-137 Baudot characters will be left justified with a modified- Baudot space (100100) being used where no character exists. If no Radio call sign is available, then insert a series of 7 spaces (100100). 3 - Aircraft Registration Marking*: Is encoded using the modified-Baudot code shown in Table 3.2. This code enables 7 characters to be encoded using 42 bits (6x7=42), 94 to 135 (1 to 42 within the field). Two bits (136 and 137 (43 and 44 within the field)) are spare and shall be coded as 00. The modified- Baudot characters will be right justified with a modified- Baudot space (100100) being used where no character exists. If no Aircraft Registration Mark is available, then insert a series of 7 spaces (100100). 4 – Aviation 24 Bit Address†: Shall either be encoded as a 24-Bit Binary Number, followed by 20 spare bits all of which are coded as 0 or shall be encoded as a 24-Bit Binary Number, followed by the 3-letter aircraft operator designator‡. The 3 letters are encoded using the modified-Baudot code shown in Table 3.2‡ (3x5 = 15 Bits) followed by 5 spare bits all of which are coded as 0. If there is no 24-Bit Address, then bits 94-117 shall all be coded as 0. If there is no 3LD for the aircraft operator, then the 3LD is coded as “ZGA”, i.e., bits 118 to 137 are set to 10001 01011 11000 00000.

WARNING: These coding schemes when used in an ELT(DT) (i.e., bits 138-140 are '011’), are NOT compliant with the mandatory data elements defined in ICAO document 10150 (either no 3LD aircraft operator (for 3 - Aircraft Registration Marking) or no aircraft identifier is available (for 5 - Aircraft operator and serial number)) and the associated data cannot be stored in the LADR. Manufacturers wishing to comply with ICAO GADSS requirements and use these coding options should consult the relevant Administration’s aviation authorities for guidance prior to coding a beacon with these coding options. † This coding (when the aircraft 24-bit address and the 3LD designator of the aircraft operator are provided in the "Vessel ID" field) is compliant with the mandatory data elements defined in ICAO document 10150, "Manual on the Functional Specifications for the Location of an Aircraft in Distress Repository (LADR)". The LADR is a facility, that will be used by Cospas-Sarsat, to support ICAO requirements for autonomous location of an aircraft in distress contained in Annex 6, Part I, section 6.18 to the Convention on International Civil Aviation. ‡ A 3-letter aircraft operator designator (3LD) from the list of "Designators for Aircraft Operating Agencies, Aeronautical Authorities and Services" published by the International Civil Aviation Organization (ICAO) as document 8585.

3-6

C/S G.008 reqmt Para. Description Number of bits Bit numbers in message Content

94-137 5 - Aircraft operator and serial number*: A 3-letter aircraft operator designator†. The 3 letters are encoded using the modified-Baudot code shown in Table 3.2* (3x5 = 15 Bits). If there is no Aircraft operator specified then the 3LD is coded as “ZGA”, i.e., bits 94 to 108 are set to 10001 01011 11000. Followed by a serial number (in the range of 1 up to 4095) as designated by the aircraft operator, encoded in binary, with the least significant bit on the right (12 Bits). If there is no serial number then bits 109 to 120 shall all be coded as 0. The remaining 17 Bits are spare and shall follow the above 27 Bits and be encoded all as 1’s. Beacon Type†

138-140 “000” ELT (excludes ELT(DT)); “001” EPIRB; “010” PLB; “011” ELT(DT); “111” System beacon; and “100”, “101”, “110” spare. Spare bits

141-154 These bits are all set to binary 1. For a cancellation message, these bits are all set to 0. TOTAL BITS IN EACH BURST

To be transmitted in each burst.

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). † These bits always indicate the type of beacon (ELT, EPIRB, PLB, ELT(DT)), as certified, or a System beacon, regardless of the vessel ID coded into the beacon.

3-7

Table 3.2: Modified Baudot Code Letter Code* MSB LSB Letter Code MSB LSB Letter Code MSB LSB A

( )†

(-)‡

3.3 Beacon Message Content – Rotating Fields The objective requirements of document C/S G.008 are provided in rotating fields as detailed below. During every transmission burst the beacon shall transmit 1 of the 16 types of rotating field content. The type of field content selected for transmission shall be in accordance with the rotating field scheduling requirements – see section 3.4. The 16 types of rotating field content are listed below. 0. C/S G.008 Objective Requirements (except national use and spares)

ELT(DT) In-flight Emergency (to allow more accurate time parameters)
RLS Type 1 Automatic and Type 2 Manual Acknowledgment (for RLS messages)
National Use (to allow national administrations to define for their use)
RLS Type 3 Two-way Communication (to support TWC messages)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Spare (for future use)
Cancellation Message

MSB: most significant bit, LSB: least significant bit † Space ‡ Hyphen

3-8

Detailed content of rotating fields #0 through #4, and #15 are shown in the tables below. Unless stated otherwise all sub-fields of every rotating field are separately binary encoded, with the Least Significant Bit to the right (i.e., the highest numbered bit in that particular message field). Table 3.3: C/S G.008 Objective Requirements Rotating Field (#0) C/S G.008 Section Sub-field Description Number of bits Bit numbers in message Content Rotating field Identifier

155-158 in message (1- 4 in rotating field) 0000 – G.008 Objective Requirements. 4.3.1a Elapsed Time since activation

159-164 in message (5- 10 in rotating field) 0 to 63 hours in one-hour steps (actual time since activation shall be truncated, not rounded e.g., between 1 hour and 2 hours after activation shall be encoded as 1 hour). If the beacon is turned off and on again (even quickly) this field shall be reset to zero. If the time is greater than 63 hours, the value shall be set to 63. 4.3.1b Time from last encoded location

165-175 in message (11-21 in rotating field) 0 to 2046 minutes (34 hours and 6 minutes) in one-minute steps (actual time since last location shall be truncated, not rounded e.g., between 34 minutes and 35 minutes after activation shall be encoded as 34 minutes). Every time that a new / updated encoded location is obtained this field shall be reset to zero. Time is calculated from when the location was obtained not when it was transmitted. If the time is greater than 2046 minutes, the value shall be set to 2046. If the beacon has not yet obtained a location from the GNSS receiver or is not equipped with encoded location capability, then this field should be set to 2047 as a default value. 4.3.1c Altitude of Encoded location

176-185 in message (22-31 in rotating field) Altitudes of ≤-400 metres to 15952 metres in steps of 16 metres (where altitudes ≤-400m are encoded as all zeros, -384 metres is encoded as 0000000001 and sea level would be encoded as 0000011001). Heights shall be rounded to the nearest 16 metre step, not truncated. If the height is greater than 15952 metres, the height shall be considered as 15952 metres and encoded as 1111111110. If altitude is not available (e.g., there is no location data or only a 2D fix is available) then this field shall be encoded as all 1’s.

3-9

C/S G.008 Section Sub-field Description Number of bits Bit numbers in message Content 4.3.1d Dilution of Precision

186-193 in message (32-39 in rotating field) The value of HDOP of the encoded location shall be reported (first 4 bits) followed by the value of VDOP on the following basis: 0000 = DOP <= 1; 0001 = DOP > 1 and <= 2; 0010 = DOP > 2 and <= 3; 0011 = DOP > 3 and <= 4; 0100 = DOP > 4 and <= 5; 0101 = DOP > 5 and <= 6; 0110 = DOP > 6 and <= 7; 0111 = DOP > 7 and <= 8; 1000 = DOP > 8 and <= 10; 1001 = DOP > 10 and <= 12; 1010 = DOP > 12 and <= 15; 1011 = DOP > 15 and <= 20; 1100 = DOP > 20 and <= 30; 1101 = DOP > 30 and <= 50; 1110 = DOP > 50; 1111 = DOP Not Available. 4.3.1f Automated/Man ual Activation notification

194-195 in message (40-41 in rotating field) Report the activation method of the beacon as follows:

Manual Activation by user;

Automatic Activation by the beacon;

Automatic Activation by external means; and

Spare. 4.3.1g Remaining battery capacity

196-198 in message (42-44 in rotating field) The remaining battery capacity in the beacon compared to its initial capacity shall be reported as follows:

<= 5% remaining;

5% and <= 10% remaining;

10% and <= 25% remaining;

25% and <= 50% remaining;

50% and <= 75% remaining;

75% and <= 100% remaining;

Reserved for future use; and

Battery Capacity Not Available or Not Provided. Not in C/S G.008 GNSS status

199-200 in message (45-46 in rotating field) This field reports the status of the GNSS receiver used to provide the encoded location as follows:

No Fix, or not available;

2D location only;

3D location; and

Reserved for future use. Spare

201-202 in message (47-48 in rotating field) 00. TOTAL Bits in Rotating Field

3-10

Table 3.4: ELT(DT) In-Flight Emergency Rotating Field (#1) C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content Rotating field Identifier

155-158 in message (1-4 in rotating field) 0001 In-Flight Emergency. 4.3.1b Time of last encoded location

159-175 in message (5-21 in rotating field) Time rounded to nearest second (17 bits): Time ‘sssss’ where ‘00001’ indicates a time of 00:00:01 UTC and ‘86399’ indicates a time of 23:59:59 UTC). If UTC time is not available or the time is more than 24 hours old, then this field shall be encoded as all ones. Altitude of Encoded Location

176-185 in message (22-31 in rotating field) Altitudes of ≤-400 metres to 15952 metres in steps of 16 metres (where altitudes ≤-400m are encoded as all zeros, -384 metres is encoded as 0000000001 and sea level would be encoded as 0000011001). Heights shall be rounded to the nearest 16 metre step, not truncated. If the height is greater than 15952 metres, the height shall be considered as 15952 metres and encoded as 1111111110. If altitude is not available, e.g., there is no location data or only a 2D fix is available, then this field shall be encoded as all ones. Triggering event

186-189 in message (32-35 in rotating field) 0001 – Manual activation by the crew; 0100 – G-switch/Deformation Activation; 1000 – Automatic Activation from Avionics or Triggering System*. If multiple triggers occur these bits shall always indicate the latest event. All other bit combinations – spare. GNSS Status

190-191 in message (36-37 in rotating field) This field reports the status of the GNSS receiver used to provide the encoded location as follows: 00 Not Fix; 01 2D location only; 10 3D location; and 11 Spare. Remaining battery capacity

192-193 in message (38-39 in rotating field) The remaining battery capacity in the beacon compared to its initial capacity shall be reported as follows: 00 ≤ 33% remaining; 01 > 33% and ≤ 66% remaining; 10 > 66% remaining; and 11 Battery capacity not available or Not Provided Spare

194-202 in message (40-48 in rotating field) All 0’s. TOTAL

Trigger in compliance with EUROCAE document ED-237.

3-11

Table 3.5: RLS Type 1 Automatic and Type 2 Manual Acknowledgment Rotating Field (#2) C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content Rotating field identifier

155-158 in message (1-4 in rotating field) bit 1-4: “0010”. Unassigned

159-160 in message (5-6 in rotating field) bit 5-6: All 0’s. Beacon RLS Capability

161-166 in message (7-12 in rotating field) bit 7 - Capability to process automatically generated Acknowledgement RLM Type-1: "1": Acknowledgement Type-1 (automatic acknowledgement) accepted by this beacon; and "0": Acknowledgement Type-1 not requested and not accepted by this beacon. bit 8 - Capability to process manually generated RLM (e.g., Acknowledgment Type-2): "1": Manually generated RLM (such as Acknowledgement Type-2) accepted by this beacon; and "0": Manually generated RLM (such as Acknowledgement Type-2) not requested and not accepted by this beacon. Note: The condition bit 7 = “0” and bit 8 = “0” is an invalid condition; at least one of these two bits must always be a “1”. bit 9-12 – Reserved for future use and to be set to all “0’s”. RLS Provider Identification

167-169 in message (13-15 in rotating field) bit 13-15: "001": GALILEO Return Link Service Provider; "010": GLONASS* Return Link Service Provider; and “011”: BDS* Return Link Service Provider. Other combinations: Spares (for other possible RLS providers) Beacon Feedback (acknowledgement of RLM reception)

170-191 in message (16-37 in rotating field) If RLS Provider Identification = 001 (bit 13-15) bit 16 – RLM Type I Feedback: "0": Type 1 not (yet) received; and "1": Type 1 received. bit 17 – RLM Type 2 Feedback: “0”: Type 2 not (yet) received; and “1”: Type 2 received.

Beacons shall not be coded with these coding options (except for the RLS test coded beacons) until the GLONASS or BDS RLS services are declared by the Cospas-Sarsat Council as operational within the Cospas-Sarsat Programme. Type approval certificates allowing these versions of the RLS coding will not be issued until the RLS provider has been approved for operational use in the System.

3-12

C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content bit 18-37 – RLM: if (bit 16 = 1 and bit 17=0): Copy of bits 61-80 of the short RLM in the Open Service Signal in Space (section 5.2 of OS SIS ICD* and section 3.2.1 of Galileo SAR SDD†). if (bit 16 = 0 and bit 17=1): Reserved for future use, currently an invalid condition. if (bit 16 = 0 and bit 17 = 0): Then bits 18-37 all = “0”. if (bit 16 = 1 and bit 17 = 1): Reserved for future use, currently an invalid condition. If RLS Provider Identification is not 001: Reserved and bits 16-37 shall all be set to “0”. Unassigned

192-202 in message (38-48 in rotating field) All 0’s TOTAL

Table 3.6: National Use Rotating Field (#3) C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content Rotating field identifier

155-158 in message (1-4 in rotating field) 0011. 4.3.1.i National use

159-202 in message (5-48 in rotating field) As defined by national administrations Default content all 0’s. TOTAL

European GNSS (Galileo) Open Service Signal In Space Interface Control Document (OS SIS ICD v1.3), December 2016. † European GNSS (Galileo) SAR/GALILEO Service Definition Document (GALILEO SAR SDD Issue 2.0), January

3-13

Table 3.7: RLS Type 3 TWC (Message) Rotating Field (#4) C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content Rotating field identifier

155-158 in message (1-4 in rotating field) bit 1-4: “0100”. TWC Provider Identification

159-161 in the message (5-7 in rotating field) bits 5-7: "001": GALILEO* Return Link Service Provider; "010": GLONASS† Return Link Service Provider; and “011”: BDS* Return Link Service Provider. Other combinations: Spares (for other possible RLS providers) Dataset Version ID

162-166 in the message (8-12 in rotating field) bits 8-12: TWC Message Dataset versioning‡ Default value 00000 The dataset version inserted here shall correspond to the dataset version number that is being used by the beacon at that time. If the Database is subsequently updated then this field shall also be updated to reflect the version number of the updated dataset now being used by the beacon. RLM Type 3 TWC Acknowledgement

167 in the message (13 in rotating field) bit 13: “0”: RLM Type3 TWC Acknowledgement not (yet) received; and “1”: RLM Type-3 TWC Acknowledgement received. Note: Once the first RLM Type-3 TWC acknowledgement is received by the beacon, this bit should remain set to “1” for the remaining period of activation. Answer Format Flag

168 in the message (14 in rotating field) bit 14: This bit defines the answer format (i.e., Short or Long) of TWC Messages in bits 16 to 48. “0”: is the short answer format in which there are three 11-bit slots which each contain a 7-bit Question/Instruction ID and 4-bit Answer ID

Galileo L1 navigation message is described in European GNSS (Galileo) Open Service Signal In Space Interface Control Document (OS SIS ICD version TBC). † Beacons shall not be coded with these coding options (except for the RLS test coded beacons) until the GLONASS or BDS RLS services are declared by the Cospas-Sarsat Council as operational within the Cospas-Sarsat Programme. Type approval certificates allowing these versions of the RLS coding will not be issued until the RLS provider has been approved for operational use in the System. ‡ TWC message database versions are available at [document C/S TBD].

3-14

C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content “1”: is the long answer format in which a 22-bit slot contains a 7-bit Question ID and 15-bit Answer(s) ID, followed by a single 11-bit slot which contain a 7-bit Question/Instruction ID and 4-bit Answer ID Spare

169 in the message (15 in rotating field) bit 15: Spare bit. Default content 0 TWC Messages

170-202 in the message (16-48 in rotating field) If bit 14 in the rotating field = 0 (short format): bits 16-22: 7 bits dedicated to question or instruction 1 Default value 0000000. bits 23-26: 4 bits allocated to answer. Default value (0000) is for the acknowledgement to question or instruction 1. bits 27-33: 7 bits dedicated to question or instruction 2 Default value 0000000. bits 34-37: 4 bits allocated to answer. Default value (0000) is for the acknowledgement to question or instruction 2. If bit 14 in rotating field = 1 (long format): bits 16-22: 7 bits dedicated to question 1 Default value 0000000 bits 23-37: 15 bits allocated to answer(s). Default value (00000 00000 00000) is for the acknowledgement to the long format question or instruction 1. Independently of bit 14’s value: bits 38-44: 7 bits dedicated to question or instruction 3 for the short format or question or instruction 2 for the long format. Default value 0000000. bits 45-48: 4 bits allocated to answer. Default value (0000) is for the acknowledgement to question or instruction 3

3-15

C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content for the short format or question or instruction 2 for the long format. [The dataset is defined in document C/S TBD] TOTAL

Table 3.8: Spare Rotating Fields (for future use) (#5 - #14) C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content Rotating field identifier

155-158 in message (1-4 in rotating field) 0101 to 1110 inclusive. 4.3.1.h Spares

159-202 in message (5-48 in rotating field) Default content all 0’s. TOTAL

Table 3.9: Cancellation Message Rotating Field (#15) C/S G.008 section Sub-field Description

Bits

Bit numbers in message Content Rotating field Identifier

155-158 in message (1-4 in rotating field) 1111. Fixed

159-200 in message (5-46 in rotating field) Set to all 1’s. Method of deactivation

201-202 in message (47- 48 in rotating field) 00 Spare; 10 Manual De-Activation by user; 01 Automatic De-Activation by external means; and 11 Spare. TOTAL

3-16

3.4 Beacon Transmission Scheduling of Rotating Fields Unless dictated otherwise by national or international regulations beacons shall transmit the rotating fields indicated below when making the following transmissions: Table 3.10: Rotating Field Transmission Conditions Type of Beacon Self-Test Transmission Normal Transmission Cancellation Message All Beacons except ELT(DT)s, Beacons with RLS Functionality (Type 1, 2 and/or 3) and National Use Beacons G.008 Objective Requirements Field #0 G.008 Objective Requirements Field #0 Cancellation Message Field #15 ELT(DT)s (see Note 2) In-Flight Emergency Field #1 In-Flight Emergency Field #1 Cancellation Message Field #15 Beacons with RLS Type 1 Automatic Acknowledgement Functionality (see Note 3) RLS Field #2 RLS Field #2 alternating with G.008 Field #0 Cancellation Message Field #15 National Use Beacons (see Note 4) National Use Field #3 Field #3 and Field #0 on a schedule set by the relevant national authority Cancellation Message Field #15 Beacons with RLS Type-3 TWC (message) Functionality (see Note 5) TWC Field #4 TWC Field #4 alternating with G.008 Field #0 Cancellation Message Field #15 [Beacons with combined RLS Functionality (see Note 6)] [RLS Field #2 and/or TWC Field #4] [TWC Fields #2 and/or #4 alternating with G.008 Field #0 TWC Field #4 to have priority in TWC mode] [Cancellation Message Field #15] Notes

All beacons always transmit the Main 154 Bit Message Field in every burst before transmitting a Rotating Field as defined above.
ELT(DT)s cannot include RLS (e.g., Type 1, Type 2, Type 3, etc.) functionality and therefore always transmit Rotating Field #1
Beacons with RLS Type 1 automatic acknowledgement functionality always transmit Field #2 in the first and subsequent odd numbered bursts and Field #0 in the second and subsequent even numbered bursts

3-17

National Use ELT(DT) Beacons shall transmit Field #3 and Field #1 on a schedule set by the relevant national authority. National Use Beacons with RLS Functionality shall transmit the selected fields, Field #4, Field #3, Field #2 and Field #0 on a schedule set by the relevant national authority. During a self-test all types of National Use beacons always transmit Field #3.
Beacons with RLS Type 3 TWC (message) functionality will transmit Field #4 in the first and subsequent odd numbered bursts and Field #0 in the second and subsequent even numbered bursts.
Beacons with combined RLS functionality which may be specified in the future. 3.5 Beacon Message Content – Error Correcting Field A sample of the BCH Error-correcting Code Calculation is provided in Appendix B.

3-18

3.6 Beacon Coding and Hex ID The manufacturer shall program a unique combination of TAC Number and Serial Number into every beacon before it leaves their factory. The TAC Number and Serial Number shall not be capable of being deleted from that beacon. Only approved devices shall be allowed to temporarily modify the Country Code, TAC, Serial Number and Vessel ID in the transmitted message (e.g., a programming adapter (see section 3.7)). If a unit is destroyed or recycled at the end of its life, the unique combination of TAC Number and Serial Number used in that beacon shall not be used in another beacon. Beacon coding methods are defined in section 3.1 of this specification. Specific operational requirements that impact beacon coding, such as the encoding of position data, are defined in section 4 of this specification. The 23 hexadecimal characters that uniquely identify each 406 MHz beacon are called the beacon 23 Hex ID. This is never transmitted by the beacon as such, rather it is generated locally by the SAR ground segment hardware and generated during beacon manufacture in order to apply identity labels to the beacon by extracting the bits shown below from the beacon data. The 23 Hex ID is composed as follows: Table 3.11: Hex ID Contents 23 Hex ID Bit No Bits Reference to Bits in Message Data Content

n/a Fixed Binary ‘1’ 2 to 11

31-40 C/S Country Code

n/a Fixed Binary ‘1’

n/a Fixed Binary ‘0’

n/a Fixed Binary ‘1’ 15 to 30

1-16 C/S TAC No 31 to 44

17-30 Beacon Serial Number

Test Protocol Flag 46 to 48

91-93 Aircraft / Vessel ID Type 49 to 92

94-137 Aircraft / Vessel ID Total

23 Hex Notes

Fixing bits 1, 12, 13 and 14 of the 23 Hex ID to ‘1101’ ensures that the 23 Hex ID cannot duplicate a First Generation Beacon 15 Hex ID.
The first 60 bits of the 23 Hex ID comprising the C/S Country Code, C/S TAC Number, Beacon Serial Number, Test Protocol Flag, Fixed Bits 1, 12, 13 and 14 and the first part of the Aircraft / Vessel ID together form a unique subset of the 23 Hex ID which form an SGB 15 Hex ID which is required for certain services, such as the Return Link Service. That is a unique SGB 15 Hex ID which may be obtained by simply truncating the 23 Hex ID and ignoring the last 8 Hex characters.

3-19

3.7 Programming Adapters If a manufacturer chooses to offer an optional Programming Adapter with a particular Beacon Model (as defined in C/S T.021 section 1.3) then it shall comply with the requirements in this section. A Programming Adapter shall only be capable of functioning with one particular Beacon Model; separate Beacon Models shall require the use of a different Programming Adapter. The mechanism used to prevent the use of a Programming Adapter with a model for which it was not designed shall be defined by the beacon manufacturer and may include physically keying of the adaptors, use of model recognition functionality, or other suitable design features. Each Programming Adapter shall be given its own unique Serial Number by the beacon manufacturer. The manufacturer shall program a unique combination of TAC Number and Serial Number into every Programming Adapter before it leaves their factory. The TAC Number and Serial Number shall not be capable of being deleted from that Programming Adapter or being overwritten by any means. If a unit is destroyed or recycled at the end of its life, the unique combination of TAC Number and Serial Number used in that Programming Adapter shall not be used in another Programming Adapter. All data stored in a Programming Adapter shall be in non-volatile memory. A Programming Adapter shall be capable of having a Country Code and Vessel ID programmed into it, which may be capable of being changed and overwritten. Every Programming Adapter shall be labelled in accordance with Section 4.5.11. When a beacon connected to a Programming Adapter is activated, it shall continue to transmit in its message the ID supplied from the Programming Adapter for the duration of the beacon activation, even if the adapter subsequently becomes disconnected/disassociated from the beacon. When next activated (unless the Programming Adapter or another Programming Adapter has been reconnected / connected to the beacon in the meantime), it shall transmit the beacon’s own unique TAC Number and Serial Number and the Country Code and Vessel ID. If a Programming Adapter is connected to an activated beacon, then the beacon shall ignore the Programming Adapter and continue to transmit the beacons own identity, until the beacon is deactivated and subsequently reactivated with the Programming Adapter connected, at which time it will then transmit the identity in the Programming Adapter.

END OF SECTION 3 –

4-1

ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS 4.1 General SGBs shall function with the MEOSAR system such that 406 MHz transmissions from a beacon can be correctly detected, located, and decoded by a MEOLUT when the beacon is operated in nominal beacon configuration(s) and under nominal System conditions. An ELT(DT) shall also provide valid 2D and altitude data. 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 4.2.1 Operating Temperature Range Three standard classes of operating temperature range are defined, inside which all of the requirements within this specification shall be met: Class 0: -55°C to +70°C Class 1: -40°C to +55°C Class 2: -20°C to +55°C 4.2.2 Temperature Gradient All of the requirements within this specification, shall be met when the beacon is subjected to the temperature gradient shown in Figure 4.1. 4.2.3 Thermal Shock All of the requirements within this specification shall be met, for measurements beginning 5 seconds after simultaneously activating the beacon and applying a rapid thermal shock of 50 °C within the specified operating temperature range of the beacon within 1 minute. Subsequently, all requirements shall continue to be met for a minimum period of two hours.

4-2

NOTES: Tmax = + 70°C (Class 0 beacon) Tmax = + 55°C (Class 1 & 2 beacons) Tmin = - 55°C (Class 0 beacon) Tmin = - 40°C (Class 1 beacon) Tmin = - 20°C (Class 2 beacon) tstart = test start time tstop = test stop time ton = beacon turn-on time after 2 hour “cold soak” tmeas = start time of frequency stability measurement (ton + 0 min) A* = 7°C/hour for Class 0 (45°C/hour for ELT(DT)) A* = 5°C/hour for Class 1 and Class 2 (33°C/hour for ELT(DT)) α = For ELT(DT)s this time is reduced on the down-ramp test to one (1) hour. SLOPE = +A* °C/h SLOPE = -A* °C/h TIME tmeas 2hα 2h 2h 1h Tmin TEMPERATURE (°C) ton Twarm-up = 0 min Tmax tstart tstop Figure 4-1: Temperature Gradient 4.3 Mechanical Environment Beacons should be submitted to vibration and shock tests consistent with their intended use. These requirements should be defined by national authorities, preferably using internationally-recognized standards such as RTCA/DO-204 for ELTs.

4-3

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 4.5.1 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. For ELT(DT)s, at the end of the 370-minute period, the ELT(DT) shall continue transmitting on the same schedule as before the 370-minute limit was reached until the ELT(DT) is either deactivated, or runs out of battery life. Minimum duration of continuous operation requirements for Crash Survivable ELT(DT)s can be found in section 4.5.15.5 and for Combined ELT(DT)s in section 4.5.16.7. 4.5.1.1 Battery Replacement Interval The beacon battery replacement interval shall be declared by the beacon manufacturer. At the end of the battery replacement interval the beacon shall continue to meet the required duration of continuous operation as defined in 4.5.1 after accounting for all losses in battery capacity over the declared battery replacement interval at ambient temperatures plus a safety factor of 65% applied to all losses, except the loss due to self-discharge. 4.5.2 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. 4.5.3 Radio-Locating Signal (for Homing and on-Scene Locating) The distress beacon may transmit a 406 MHz Radio-Locating signal as defined in section 2.5. ELT(DT)s are not required to provide a Radio-Locating signal. 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.

For installations meeting IMO GMDSS requirements, a minimum operating lifetime of 48 hours (EPIRB) and 168 hours (for Float Free VDR capsules) at any temperature throughout the specified operating temperature range is necessary. The minimum operating lifetime for an ELT (DT) to meet the ICAO GADSS requirement at any temperature throughout the specified operating temperature range shall be 370 Minutes. This duration is based on the ICAO standards for Extended Diversion Time Operations (EDTO) and the maximum diversion time capability of existing aircraft types, as of April 2018.

4-4

The distress beacon may transmit other 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. The status of the radio-locating transmissions (e.g., operational or non-operational) shall be monitored before each beacon satellite transmission and shall be encoded in the beacon message as indicated in section 3.2. Any such radio-locating device must satisfy all the national performance standards applicable to radio-locating devices at the selected frequency. Radio-Locating Signals shall not begin transmissions for at least 30 seconds (in order for the as equipped status to be transmitted) but shall begin transmission within 5 minutes maximum after beacon activation, except (if applicable) AIS signals which shall not be delayed for longer than 1 minute after beacon activation. 4.5.4 Beacon Self-Test Mode In the self-test mode beacons shall transmit a 406-MHz signal with digital message encoded in accordance with section 3. The content of the self-test message shall always provide the beacon ID as defined in section 3.6, except when a Programming Adapter is attached to the beacon, in which case it shall comply with section 3.7. The transmitted message shall be spread by a specific sequence defined in section 2.2.3. The self-test mode or GNSS self-test mode shall not be used for the purposes of repetitive automated interrogation of the beacon status. A beacon (e.g., ELT(DT)) may contain a different test mode that can be used for repetitive automated interrogation of its status, but operation of the beacon in this different test mode shall not result in the transmission of a 406-MHz signal or other radio locating signals (if applicable) nor interfere with the normal operation of the beacon. 4.5.4.1 Nominal Beacon Self-Test Mode All beacons shall include a self-test mode of operation, which shall include a Verification of Registration function as detailed in section 4.5.8. The complete self-test transmission shall be limited to one 406 burst at full power and one burst of each radio-locating signal at full power with a maximum duration of 3 sec each regardless of the duration of activation of the self-test control. The radiolocating signals shall be transmitted first in order of ascending frequency followed lastly by the 406 MHz satellite signal. The self-test mode shall be activated by either a separate switch to that used to activate the beacon or cancel transmissions; or a separate switch position of the beacon activation switch. The duration of the self-test cycle shall not exceed 15 seconds. The self-test function shall perform an internal check and provide a distinct indication that: a) the self-test mode has been initiated within 2 seconds of activation;

4-5

b) RF power is being emitted at 406 MHz and the radio locating frequencies, if applicable; and c) the internal check has passed successfully within 15 seconds of activation; or d) any of the items a), b) or c) has failed the self-test within 15 seconds of activation; e) for RLS Type 1 automatic acknowledgment capable beacons an indication if the beacon has RLS functionality enabled; and f) for RLS Type 3 TWC (message) capable beacons an indication if the beacon has RLS Type 3 TWC (message) functionality enabled. The content of the encoded position data field of the self-test message shall be the default values specified in section 3. 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. 4.5.4.2 GNSS Beacon Self-Test Mode In addition to the mandatory regular self-test, beacons may optionally include a GNSS self-test mode. ELT(DT) beacons shall include a GNSS self-test mode resulting in a single burst transmission. Beacons which provide for the transmission of an encoded position in a GNSS self-test message shall: a) 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 GNSS self-test 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; b) 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; c) provide a distinct indication that the GNSS self-test is underway and to register successful completion or failure of the GNSS self-test; d) provide, for beacons with internal navigation devices powered by the primary beacon battery, a separate distinct indication that the limited number of GNSS self-test opportunities have been attained; e) 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

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

4-6

GNSS self-test failure and may transmit a single self-test burst with default location data (as described in Section 3),

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 (or before the time limit is reached), indicate a GNSS self-test pass and transmit a single self-test burst containing the valid location data; and f) for beacons that provide a GNSS self-test using both the internal navigation device and the external navigation interface:

if the location data from the external navigation interface is not available, the beacon shall wait to obtain location data from the internal navigation device for the maximum duration of the GNSS self-test, as declared by the beacon manufacturer. 4.5.5 Encoded Position Data* 4.5.5.1 General Beacon position data, obtained from a navigation device internal, integral† or external to the beacon, shall be encoded in the beacon message, if available. Beacons that do not provide encoded position data shall indicate this within the message and shall transmit default location data as defined in section 3. Beacons capable of encoding position data shall comply with all the appropriate parts of section 4.5.5. • Section 4.5.5.2 applies to all beacons with an internal navigation device except ELT(DT)s • Section 4.5.5.3 applies only to ELT(DT)s which must always include an internal navigation device • Section 4.5.5.4 applies to all beacons (including ELT(DT)s) which include an external navigation device input. Thus, for example if an EPIRB has an internal navigation device and an external navigation device input then it shall comply with both sections 4.5.5.2 and 4.5.5.4. All times are measured since beacon activation unless specified otherwise. Encoded position message content shall be as defined in section 3. ELT (DT)s shall incorporate an internal navigation device and may incorporate an interface to an external navigation device. The initial position transmitted in the first burst may be obtained

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

from either the internal navigation device or from the external navigation device input. Subsequently all future positions shall only be obtained from the internal navigation device. 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 1 second before the burst. If position data is available from both sources, within 1 second before the burst, then the location produced by the internal GNSS receiver has the priority over the external source of data*. Operation or failure of an internal or external navigation device providing position data to the beacon shall not degrade other aspects of beacon performance. 4.5.5.2 Internal Navigation Device An internal navigation device shall be capable of global operation and should 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, and sufficient quality of the signals. 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. With a clear view of the sky the distance between the static horizontal position provided by the navigation device, at the time of the position update, and the actual navigation device static position shall not exceed 30 m 95% of the time. The distance between the static vertical position (altitude) provided by the navigation device, at the time of the position update, and the actual navigation device static position shall not exceed 50 m 95% of the time. The objective should be to provide a position with low geometric dilution of precision, however if the only position available (whether this be 2D or 3D) has a high dilution of precision then this position should be provided rather than being discarded in favour of not providing a position at all. The encoded position data shall be provided in a format compatible with the International Terrestrial Reference System (ITRS) and its reference frames (ITRF) such as the WGS 84 or GTRF. The difference between the chosen format and the ITRF shall not exceed 10 cm.

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, but must be powered solely by the ELT(DT)’s internal power source immediately after activation of the ELT(DT). The ELT(DT) shall have its own integral or internal power source. However, when available, the ELT(DT) may use aircraft electrical power source during transmission after its activation. ELT(DT) system minimum duration of continuous operation shall however be demonstrated with the ELT(DT) own internal/integral power source.

4-8

The navigation device shall provide an indication of the potential error of each provided position in terms of Horizontal Dilution of Precision (HDOP) and Vertical Dilution of Precision (VDOP) and shall encode the respective DOP values in the message in accordance with section 3.3. The navigation device shall provide the following additional information for each provided position whether it has no Fix or was operating in 2D or 3D Mode and shall encode this data in the message in accordance with section 3.3. If a valid 3D location (including height) is available then this shall be transmitted, however if a 3D location is not available but a valid 2D location is then this shall be transmitted instead. In this instance when the location changes from 3D to 2D (or No Fix) the altitude shall be reset to the default value until such time as a 3D fix with altitude is available. First provision of encoded location within a transmitted message shall occur no later than the first burst after 2 minutes from beacon activation with a 95% probability, with a clear view of the sky. The Internal navigation device shall operate continuously during the initial 30 minutes period following beacon activation. During this period the beacon shall acquire fresh position information immediately prior to every transmission burst unless this becomes impractical due to navigation signal constraints. During the first 30 minutes after beacon activation the location transmitted by the beacon shall always be the latest information provided by the navigation device. This applies even if the quality of the location has become worse. The navigation device shall provide an updated location at least every 1 second and the update immediately prior to the next scheduled transmission burst shall be encoded and transmitted by the beacon within 1 second of receipt. After the first 30 minutes, the navigation device shall make subsequent attempts to obtain an initial location, or an updated location, as applicable, at least every 15 minutes 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. Whenever the beacon has fresh encoded location data at the start of a burst, this shall be indicated within the message by zeroing the “time from last encoded location” field as required by section 3.3. If no position is available, then the beacon shall transmit either default position data (if it has no position) or the last received position until such time as a fresh position is available. In addition, the beacon shall compute the elapsed time since the last position update (or since activation) to an accuracy of 10 seconds and provide this in the transmitted message to a resolution of the nearest minute as required by section 3.3. Each location update attempt shall require the navigation device to be operational for a period of at least 90 seconds or until a valid location has been obtained whichever is shortest.

For EPIRBs used as the float-free recording medium for VDRs, after at least 48 hours, 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

4.5.5.2.1 ELTs with an Internal Navigation Device Powered Externally Prior to Activation If an internal navigation device cold start is forced upon application of external power to the internal navigation device, and does not cold start upon beacon activation, then the requirements of this section apply. For ELTs with externally powered internal navigation devices, which are continuously operational prior to beacon activation, and are designed to obtain and update position data from an internal GNSS receiver and retain position data in the beacon memory, prior to the beacon activation, the internal navigation device cold start shall be forced on each initial power up of the internal navigation device. To facilitate the provision of position data prior to activation, the ELT shall attempt to update the position retained in memory from the internal navigation device at intervals of no longer than 1 second. If, after ELT activation, current navigation data is not available, then the ELT shall transmit its first and subsequent 406-MHz messages with the last position available prior to ELT activation (as retained in beacon memory for this purpose) until a new position is available. The ELT shall not use external power to power the internal navigation device once activated. After activation the beacon shall only be powered by the internal battery, apart from external interfaces to/from the beacon approved for use with the beacon (e.g., Remote Control Panel, ARINC interface, etc.). 4.5.5.3 Internal Navigation Device ELT(DT)s only An internal navigation device shall be capable of global operation and should 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, and sufficient quality of the signals. The ELT (DT) navigation system shall be cold-started on initial power-up (ELT(DT) in ARMED mode see section 4.5.6.1) but shall not be cold started 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 memory, which might affect the acquisition of the GNSS position. With a clear view of the sky the distance between the static horizontal position provided by the navigation device, at the time of the position update, and the actual navigation device static position shall not exceed 30 m 95% of the time. The distance between the static vertical position (altitude) provided by the navigation device, at the time of the position update, and the actual navigation device static position shall not exceed 50 m 95% of the time. The objective should be to provide a position with low geometric dilution of precision, however if the only position available (whether this be 2D or 3D) has a high dilution of precision then this position should be provided rather than being discarded in favour of not providing a position at all.

4-10

The encoded position data shall be provided in a format compatible with the International Terrestrial Reference System (ITRS) and its reference frames (ITRF) such as the WGS 84 or GTRF. The difference between the chosen format and the ITRF shall not exceed 10 cm. The navigation device shall provide the following additional information for each provided position whether it has no Fix or was operating in 2D or 3D Mode and shall encode this data in the message in accordance with section 3.3. If a valid 3D location (including height) is available then this shall be transmitted, however if a 3D location is not available but a valid 2D location is then this shall be transmitted instead. In this instance when the location changes from 3D to 2D (or No Fix) the altitude shall be reset to the default value until such time as a 3D fix with altitude is available. First provision of encoded location within a transmitted message shall occur within 5 seconds* after ELT(DT) activation with a 95% probability, with a clear view of the sky. If, after the ELT(DT) activation, current navigation data is not available, then the ELT(DT) shall transmit its first and subsequent 406-MHz messages with the last position available prior to the ELT(DT) activation (which shall be retained in beacon memory for this purpose). The position provided in the transmitted message shall also contain the UTC time that relates to when the position was obtained in accordance with Table 3.4 “Time of Last Encoded Location” (to an accuracy of 1 second), until either navigation data becomes available or 24 hours has elapsed. To facilitate the provision of position data prior to activation, the ELT(DT) shall attempt to update the position retained in memory from either the internal navigation device or the external navigation input at intervals of no longer than 2 seconds. If no position was available prior to the ELT(DT) activation, or if 24 hours have elapsed without an updated position becoming available, the ELT(DT) shall transmit the default position until such time, as navigation data becomes available from an internal GNSS receiver or, if applicable, from an external navigation device. The Internal navigation device shall operate continuously during the initial 30 minutes period following beacon activation, subsequently each location update attempt prior to every 406 MHz transmission shall require the navigation device to be operational for a period of at least 15 seconds or until a valid location has been obtained whichever is shortest. If the internal navigation device fails to provide a location during the two location update attempts immediately previous to the current location update attempt, then the current update attempt shall be extended to a minimum duration of 25 seconds scheduled immediately prior to the next planned location update. After the first hour following beacon activation, the internal navigation device shall also be operational for a period of at least 180 seconds once every hour thereafter, to ensure that the device can download any necessary navigation message updates. ELT(DT)s shall attempt to acquire fresh position information prior to every 406 MHz transmission (unless this becomes impractical due to navigation signal constraints) for the entire operating lifetime of the ELT (DT) and shall encode the latest position obtained within less than 1 second prior to each burst into that transmission. If an updated position is not available within 1 second 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 24 hours old, in which case it shall revert to transmitting the default position until such time as an updated position is available.

The ELT(DT)’s 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-11

ELT (DT)s shall provide the UTC time of the last encoded location to an accuracy and resolution of 1 second and provide this in the transmitted message as required by section 3.3, Table 3.4. If UTC is not available for an encoded location, or if the time of the last encoded location is over 24 hours old then the ELT(DT) shall transmit default data. 4.5.5.4 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) and that any difference between the ITRS and the datum employed by the receiver should be less than 10 cm. The input should be able to provide all relevant position data as required by sections 3.2 and 3.3, this includes horizontal position, vertical position (altitude), time of this position to an accuracy of 1 second, HDOP, VDOP and, No Fix or 2D or 3D operating. Examples of suitable Maritime IEC 61162-1 sentences to achieve this objective include GNS and GSA and Aviation ARINC 429 labels to achieve this objective include Label 101, 102, 310, 311 etc. The beacon user manual shall include details of the acceptable interfaces. In addition to providing horizontal position and altitude the external navigation input shall provide an indication of the potential error of each provided position in terms of Horizontal Dilution of Precision (HDOP) and Vertical Dilution of Precision (VDOP) and shall encode the respective DOP values in the message in accordance with section 3.3, except for ELT(DT)s transmitting Rotating Field #1 as this field does not include provision for HDOP or VDOP. The external navigation input shall indicate for each provided position whether it has no Fix or was operating in 2D or 3D Mode and the beacon shall encode this data in the message in accordance with section 3.3. If a valid 3D location (including height) is available then this shall be transmitted, however if a 3D location is not available but a valid 2D location is then this shall be transmitted instead. In static conditions the distance between the horizontal position provided by the external navigation input, at the time of the position update, and the position transmitted by the beacon shall not exceed 20 m. The distance between the vertical position (altitude) provided by the external navigation input, at the time of the position update, and the position transmitted by the beacon shall not exceed 40 m. First provision of encoded location within a transmitted message shall occur within 5 seconds with navigation data available at the external navigation device input. During the first 30 minutes after beacon activation the location transmitted by the beacon shall always be the latest information provided by the external navigation input. This applies even if the quality of the location has become worse. The external navigation input shall provide an updated location at least every 1 second and the update immediately prior to the next scheduled transmission burst shall be encoded and transmitted by the beacon within 1 second of receipt. After the first 30 minutes, the beacon shall access the external navigation input prior to every transmission and shall encode the position, if available, into the next transmitted burst. Whenever the beacon has fresh encoded location data at the start of a burst, this shall be indicated within the message by zeroing the “time from last encoded location” field (except for ELT(DT)s) as

4-12

required by section 3.3, Table 3.3. ELT(DT)s shall include the UTC time of the last encoded location as required by section 3.3, Table 3.4. If no position is available, then the beacon shall transmit either default position data (if it has no position) or the last received position until such time as a fresh position is available. In addition, the beacon shall compute (except for ELT(DT)s) the elapsed time since the last position update (or since activation) to an accuracy of 10 seconds and provide this in the transmitted message to a resolution of the nearest minute as required by section 3.3, Table 3.3. If a beacon designed to operate with an external position source is installed in a configuration which does not supply any or all of the expected GNSS data (e.g., position, status, etc.), then the beacon should transmit default data for all of the missing data items. Note: This could occur in the installation of an ELT in an aircraft which cannot provide any or all of the expected GNSS data due to limitations of the installation. 4.5.6 Beacon Activation Beacons shall have a means of manual activation and deactivation and may optionally also include means of automatic activation (for ELT (DT)s see section 4.5.6.1 below). The beacon shall be designed to prevent inadvertent activation. Within 1 second after activation, the beacon shall provide a visual indication that it has been activated. For beacons which can be remotely activated, there shall be an indicator on both the remote activation device and the beacon. The beacon (except ELT(DT)s) shall track time since activation to an accuracy of 10 minutes and provide this in appropriate transmitted messages to a resolution of the nearest one hour as required by section 3.3. After activation the beacon shall commence transmissions in accordance with section 2.2.1, thereafter the beacon shall not transmit more frequently than the minimum burst transmission interval (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’, ‘Reset’ or ‘Cancellation’ controls shall not stop the beacon from transmitting. 4.5.6.1 ELT(DT) Modes of Operation ELT(DT)s shall allow for automatic and manual means of activation. All ELT(DT)s shall include a means of receiving information from the aircraft to determine whether the ELT(DT) is on the ground or in the air and shall take this status into account when activated. ELT(DT)s shall also have means of deactivation by the same means of activation which shall be followed by a cancellation message sequence. Standalone ELT(DT)s (i.e., those that do not comply with either sections 4.5.15 or 4.5.16) should function as follows. National Administrations or Aviation Authorities may define additional functionality. Table 4.1: Expected Stand-alone ELT(DT) Behaviour

4-13

Activation Criteria Activation Means Manual Avionics On-Ground 406 Distress Tracking (DT) sequence and 121.5 optional if available Avionics Activation Disabled In-Air 406 DT sequence only preferred 121.5 optional if available 406 DT sequence only If the beacon is activated in one aircraft state (e.g., in-flight) and the aircraft transitions to another state (e.g., on-ground) while the beacon is still transmitting, the beacon transmission characteristics should behave as indicated for the new aircraft state as per the table above. Consequently: • If the ELT(DT) has been automatically activated by the triggering system*, it shall only be de-activated by the same means. • If the ELT(DT) has been automatically activated by the beacon sensors†, it shall only be deactivated by manually resetting the beacon. • If the ELT(DT) has been manually activated (i.e., from the cockpit), it shall only be manually de-activated. • If the ELT(DT) has been activated by any combination of activation means, it can only be de-activated once each activation means has been deactivated. • Bits 186 to 189 of the ELT(DT) message shall indicate the most recent means of activation. If one means of activation is removed but others remain then Bits 186 to 189 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 by an automatic triggering system‡ 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 by an automatic triggering system and/or has been manually activated and is transmitting 406 MHz signals in full compliance with the ELT(DT) requirements in this specification.

For example, triggered by an external source 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-14

RESET – The ELT(DT) is deactivated and ceases transmitting distress alerts and instead transmits a sequence of cancellation messages as defined by Section 4.5.7. 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. 4.5.7 Beacon Activation Cancellation Function The beacon shall include a beacon activation cancellation function. This shall be a separate function from the on/off capability of the beacon for all beacons except ELT(AD), ELT(AF), and ELT(DT). The cancellation function shall be protected from inadvertent activation and shall be triggered by two simple and independent actions that provide confidence in intentional cancellation action by the user. The beacon shall provide an indication of the transmission of cancellation messages. When the beacon is deactivated with the cancellation function, the beacon 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 beacon 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 (unless otherwise specified in this section). In the case of an RLS Type 3 TWC beacon, if the user selects and confirms to cancel the alert from the question/answer dataset, then the beacon activation cancellation function shall be automatically triggered. When the beacon activation cancellation function is initiated it shall comply with section 3.4, Table 3.1 and Table 3.9. 4.5.7.1 Additional Requirements for ELT(AD), ELT(AF) and ELT(DT) Beacons For ELT(AD), ELT(AF), and ELT(DT) beacons, the cancellation transmission sequence shall start when either: • the beacon is active (ON mode), and the user turns the beacon off (OFF mode) from the front panel on the beacon, or • the beacon is active (ON mode), and an automatic or manual RESET is initiated, provided no other activation sources are present. For ELT (DT)s the cancellation function shall include a means of automatic cancellation from the same source(s) as the aircraft automatic activation. 4.5.7.2 Additional Requirements for ELT(AP) Beacons For ELT(AP) beacons, when connected to the remote control and indicator panel (i.e., when mounted in the aircraft), the cancellation message sequence shall be initiated whenever a beacon is deliberately turned off or reset provided no other activation sources are present (thus overriding the cancellation function on the ELT unit itself). For ELT(AP) beacons, when not connected to the remote control and indicator panel (i.e., when external to the aircraft), the cancellation message sequence shall only be initiated when the cancellation function on the ELT unit is enabled.

4-15

4.5.7.3 Additional Requirements for all other Beacons For all other beacons, the cancellation function shall only be activated through a dedicated control. Manual operation of the cancellation function shall only result in the transmission of a set of cancellation messages when either the beacon is active and transmitting distress alerts or when the cancellation function is activated within 180 seconds of a previously activated beacon having been turned off, deactivated or reset. 4.5.8 Verification of Registration See footnote.* 4.5.9 RLS Functions If a beacon is equipped with a Return Link Service (RLS) functionality and is configured to transmit an RLS Rotating Field, it shall meet the following additional requirements. 4.5.9.1 RLS 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 RLM compliant sentence or an equivalent proprietary RLM 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 by Cospas-Sarsat to date: • RLM Type 1 Automatic Acknowledgement – An automated response that simply acknowledges receipt of the RLS request by the System. • RLM Type 3 Two-way Communication (message) – a return link message (RLM) that supports the exchange and acknowledgement of information between the beacon user and SAR Authorities using pre-defined questions, answers or instructions.

C/S G.008 Section 3.13 describes an operational beacon requirement to design the beacon such that the registration status of the beacon is displayed to the beacon user. The registration status shall remain valid for a period of two years and the beacon shall be designed such that the self-test function indicates by default that the beacon is not registered. National Administrations have a variety of registration renewal requirements and methods for registration verification. The lack of a common approach makes it difficult to identify a specific specification to achieve the requirement at this time. It's possible that in the future that a common approach would be identified, but until such time, compliance with this requirement is not met by SGBs in C/S T.018.

4-16

The definition of the Type 1 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. The definition of the Type 3 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 TBD. 4.5.9.2 RLS Type 1 GNSS Receiver Operation 4.5.9.2.1 Operation Cycle In addition to the beacons normal GNSS receiver operating cycle as defined in section 4.5.5.2 or as defined by the beacon manufacturer if the receiver is designed to be active more frequently than those requirements, the RLS Type 1 automatic acknowledgement beacon shall: a) when encoded with RLS functionality (i.e., transmitting an RLS Rotating Field) maintain the GNSS receiver in an active mode of operation such that it can continuously check for receipt of an RLM message and Coordinated Universal Time (UTC), for a minimum period of 30 minutes after beacon activation, or until a valid RLM message is acquired, or until the beacon is deactivated, whichever occurs first; b) 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); c) if an RLM message has not been received within the first 30-minute period, then at the end of this time, utilize UTC time to next activate the GNSS receiver* at the next occurrence of UTC Moffset† minutes 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); d) then during each subsequent hour reactivate the GNSS receiver 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; e) if UTC is not available after the first 30 minutes the beacon shall attempt to establish UTC using the timings detailed in sections 4.5.5.2. If UTC is then established the beacon shall continue as per c) and d) above from the next occurrence of UTC Moffset minutes; and

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

4-17

f) 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 sections 4.5.5.2. 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.2. If an RLM message is not acquired then it would reactivate at the next occurrence of Moffset past the hour and remain active until at least Moffset+15, or until an RLM message is acquired, or the beacon is deactivated and it would then reactivate again during the next hour at Moffset until Moffset+15, etc. The scheme continues as above until an RLM message is acquired, or 6 hours has elapsed since beacon activation, that is in this example until 09.17h UTC, at which time if an RLM wasn’t acquired earlier the GNSS Receiver reverts to the GNSS timings in section 4.5.5.2. 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. The RLS beacon may contain an internal GNSS receiver capable of receiving and decoding other types of acknowledgment RLM following the same operation cycle as the one described. 4.5.9.2.2 Derivation of Moffset The value of Moffset for each beacon is computed from the beacon 15 Hex ID subset of the 23 Hex ID (see section 3.6). 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. A sample of a Moffset calculation and CRC code is shown in Appendix F. 4.5.9.3 RLS Indicator The beacon shall be provided with an RLS indicator designed to advise the user when a Type 1 RLS message has been received by the RLSP and the beacon has received a Type 1 Return Link Message (RLM). The RLS Indicator shall: a) be readily visible to the user when the beacon is operated in all its normal operational configurations as declared by the manufacturer; b) be clearly visible to the user in direct sunlight; c) provide a distinct unique indication; d) remain inactive at all times when the beacon message is encoded with any message content other than the RLS Rotating Field RF#2;

4-18

e) within 5 seconds of the beacon transmitting an initial RLS request, commence indication of an RLS request until either a valid RLM Type 1 message is received, or the beacon is deactivated, or the beacon battery is expired; f) within 5 seconds of the beacon receiving a valid RLM Type 1 message acknowledgement, commence a distinct indication until either the beacon is deactivated or the beacon battery is expired; g) only provide the indication of receipt of an RLS request acknowledgment when the received RLM Type 1 message contains the unique 15 Hex ID subset of the 23 Hex ID programmed into that beacon and the beacon has validated that this matches its own 15 Hex ID subset of its 23 Hex ID; and h) provide an indication during a self-test if the RLS functionality is enabled in accordance with section 4.5.4.1 e). 4.5.9.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 4 minutes and 14 seconds, acknowledge the RLM receipt by changing the coding of its message as defined in the RLS rotating field, as described in section 3.3. Once changed, the RLM beacon feedback field shall no longer be changed until a different RLM message is received or 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.9.2.1 unless the beacon is coded as a "Type-1 only capable" RLS beacon as defined in Table 3.5. In this specific case only, the GNSS receiver may revert to operating as defined within sections 4.5.5.2 and 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, the navigation device shall attempt location update at least once every 15 minutes, for a period of at least 90 seconds, or until an updated location is obtained, if sooner. 4.5.9.5 RLS Beacon Documentation The operation of the RLS Type 1 automatic acknowledgement function shall be clearly explained in the User Manual including the performance characteristics of the overall RLS system. Suggested minimum text is provided in Annex H.1. 4.5.10 Battery Status Indication The battery status indication provides the user with an indication prior to beacon activation that the battery may be partially depleted and may not operate for the full specified operating lifetime. Beacons powered by a rechargeable battery shall automatically provide an indication when the battery requires recharging.

4-19

Beacons powered by a non-rechargeable battery shall provide an indication of battery status during self-tests. This shall be a separate indication to the self-test pass/fail indication and the battery status indicator shall provide a distinct indication of Potentially Insufficient Battery Energy (PIE). That is, that the remaining battery energy may not be sufficient to support the manufacturer declared minimum duration of continuous beacon operation. 4.5.11 Beacon Labelling All beacons shall have the following information durably marked on the exterior of the beacon: 1) Beacon 23 Hex ID (the 23 Hex ID shall be displayed as: NNNNNN NNNNNN NNNNNN NNNNN (i.e., a space after every 6 characters)) 2) The beacon operating temperature range 3) The minimum duration of continuous operation 4) For RLS-capable beacons, wording on the Beacon Identity label (TAC / Hex ID Label) indicating whether the RLS function is enabled or disabled 5) For RLS-capable beacons*, a label indicating which are the RLS and RLM indicator(s). If applicable, all Programming Adapters shall be durably marked with the Beacon Model that it relates to and its own unique TAC and Serial Number. In addition there shall be sufficient space to provide the Country Code and Vessel ID information that will be programmed into the adapter. 4.5.12 Beacon Instruction Manual An End User instruction manual shall be made available with all beacons, it shall include the information as outlined in the data item description (Annex H.1.10 of document C/S T.021). 4.5.13 Beacon Data Requirements The manufacturer shall make available for the purposes of supporting the type approval review the information as outlined in the data item description (Annex G-3 and Annex H.1 of document C/S T.021). 4.5.14 External Power Source for ELT(DT)s The ELT(DT) shall have its own integral or internal power source. However, when available, all ELT(DT)s (including those in compliance with sections 4.5.15 and 4.5.16) 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.

Labeling of the RLS and RLM indicator(s), is independent of the value of bit 42, and whether there is a rotating field #2.

4-20

4.5.15 ELT(DT)s Specifically Designed to Withstand a Crash Impact 4.5.15.1 Introduction Potentially there may be ELT(DT)s that have additional functionality, as defined by National Administrations and/or Aviation Authorities, which are designed to:

function both prior to a crash and after a crash, and withstand crash impact conditions;
be activated in-flight or by crash;
have homing and locating signals; and/or
have extended operating life. Crash Survivable ELT(DT)s should function as follows. Table 4.2: Expected Crash Survivable ELT(DT) Behaviour Activation Criteria Activation Means Manual Automatic Activation by the Beacon Avionics Trigger Unknown aircraft state 406 Distress Tracking (DT) sequence only preferred, homing permitted 406 Post Crash (PC) sequence and homing 406 DT sequence only On-Ground 406 Distress Tracking (DT) sequence and homing 406 PC sequence and homing Avionics Activation Disabled In-Flight 406 DT sequence only preferred homing permitted 406 PC sequence and homing 406 DT sequence only If the beacon is activated in one aircraft state (e.g., in-flight) and the aircraft transitions to another state (e.g., on-ground) while the beacon is still transmitting, the beacon transmission characteristics should behave as indicated for the new aircraft state as per the table above. If there is a conflict between the requirements of this section and any other section of this document, then this section takes precedence. 4.5.15.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-21

4.5.15.3 Burst Transmission Interval (with Crash Detection) If the ELT(DT) includes a crash detection function, within 5 seconds of a crash the ELT(DT) shall initiate or restart the transmission schedule for an ELT(DT) as if the ELT(DT) had just been activated as defined in section 2.2.1 and maintain this transmission schedule for the first 95 bursts (i.e., approximately 30 minutes) after the crash detection. After burst number 95 (after crash detection), transmissions shall then occur at nominally 120 second intervals. The time between the start of two successive transmissions (TR) shall be randomized with uniform (flat) distribution around the stated nominal value, so that the time intervals between the beginnings of two successive bursts (TR) are randomly distributed over ± 5 seconds. After burst number 95 (after crash detection), the standard deviation over the next 20 successive bursts of TR shall be greater than 2.5 seconds. The minimum value of TR observed over the 20 successive bursts shall be between 115.0 and 115.2 seconds, the maximum value of TR observed over the 20 successive bursts shall be between 124.8 and 125.0 seconds. Operation after 370 minutes without crash detection If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash mode or has not been deactivated, then it shall continue transmitting on the same schedule (with the GNSS encoded location updated before each transmitted burst) as before the 370- minute limit was reached until the ELT(DT) is either deactivated, gets a subsequent “crash” indication to transition to the “post-crash” mode, runs out of battery life, or reaches the minimum duration of continuous operation, whichever occurs first. 4.5.15.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 sections 4.5.5.1, 4.5.5.3 and 4.5.5.4 (if applicable). Beyond 30 minutes, the GNSS encoded location shall be updated in accordance with section 4.5.5.1, 4.5.5.2 and 4.5.5.4 (if applicable). 4.5.15.5 Duration of Continuous Operation The minimum duration of continuous operation under worst case conditions for this type of ELT(DT) shall be at least 24 hours at any temperature throughout the specified operating temperature range. This is to be understood to mean the total operating time which is a combination of the time prior to a crash (minimum of 10 minutes and maximum of 370 minutes) and post-crash. For the avoidance of doubt, if the ELT(DT) continues to operate after 370 minutes without crash detection then the 24-hour minimum duration of continuous operation does not apply, and might be reduced as a result of the extended operation in this pre-crash mode.

4-22

4.5.15.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. 4.5.16 ELT(DT)s Combined with Automatic ELTs 4.5.16.1 Introduction Potentially there may be ELT(DT)s that have combined functionality, that is they function as an ELT(DT) during a flight, but on detection of an incident perform as an Automatic ELT (either an ELT(AD), ELT(AF) or ELT(AP)), such a combined ELT would be required to meet the regulatory requirements set by National Administrations and/or Aviation Authorities, for both an ELT(DT) and the type of Automatic ELT that it is combined with. However, from a Cospas-Sarsat perspective there are certain key functions of such a combined ELT that need to be clearly defined related to its performance and operation and the transition from an ELT(DT) to either an ELT(AD), ELT(AF) or ELT(AP) as follows. ELT(DT)s combined with Automatic ELTs should function as follows. Table 4.3: Expected ELT(DT) Combined with Automatic ELT Behaviour Activation Means Activation Criteria Manual Automatic Activation by the Beacon Avionics Trigger Unknown aircraft state 406 Distress Tracking (DT) sequence only preferred, homing permitted 406 SGB sequence and homing 406 DT sequence only On-Ground 406 SGB sequence and homing 406 SGB sequence and homing Avionics Activation Disabled In-Flight 406 DT sequence only preferred, homing permitted 406 SGB sequence and homing 406 DT sequence only If the beacon is activated in one aircraft state (e.g., in-flight) and the aircraft transitions to another state (e.g., on-ground) while the beacon is still transmitting, the beacon transmission characteristics should behave as indicated for the new aircraft state as per the table above. If there is a conflict between the requirements of this section and any other section of this document, then this section takes precedence.

4-23

4.5.16.2 Beacon Coding and Beacon Hex ID The combined ELT(DT) and Automatic ELT shall transmit the ELT(DT) In-Flight Emergency Rotating Field #1 at all times and shall not change to transmitting the Objective Requirements Rotating Field #0 when the combined device transitions to or is activated as an Automatic ELT. The 23 Hex ID shall remain the same regardless of whether the device is operating as an ELT(DT) or as an automatic ELT. Bit 42 in the combined device message shall remain as “0” indicating that the device is not equipped with the RLS capability and shall not change to “1” when the combined device transitions to or is activated as an Automatic ELT. Bits 138 to 140 in the combined device message shall remain as “011” indicating that the device is an ELT(DT) and shall not change to “000” when the combined device transitions to or is activated as an Automatic ELT. 4.5.16.3 Burst Transmission Interval 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 (i.e., restart the Initial IAMSAR stage transmission schedule). Operation after 370 minutes without crash detection If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash mode or has not been deactivated, then it shall continue transmitting on the same schedule (with the GNSS encoded location updated before each transmitted burst) as before the 370-minute limit was reached until the ELT(DT) is either deactivated, gets a subsequent “crash” indication to transition to the “post-crash” (Automatic ELT) mode, runs out of battery life, or reaches the minimum duration of continuous operation, whichever occurs first. 4.5.16.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), specifically: a) the combined ELT(DT) and Automatic ELT does not have to meet the requirement for 90% of measured EIRP values to meet the limits shown at elevation angles below 55 degrees (but does have to meet the other requirements in section 2.4.2); b) the combined device shall comply with both the Temperature Gradient requirements for an ELT(DT) and the Temperature Gradient requirements for a regular 406 MHz beacon, based upon the declared temperature classes for each part of the device (section 4.2.2); c) the combined ELT(DT) shall not be required to track time since activation (since it will not be transmitting Rotating Field #0) (section 4.5.6); and

4-24

d) the combined ELT(DT) shall comply with the modes of operation for an ELT(DT) (section 4.5.6.1). 4.5.16.5 Cancellation Message The cancellation message shall function as defined in section 4.5.7 while operating as an Automatic ELT as well as while operating as an ELT(DT). 4.5.16.6 Encoded Position Data and Navigation Device Performance While operating as an ELT(DT) the navigation device shall comply with the requirements of sections 4.5.5.1, 4.5.5.3 and 4.5.5.4 (if applicable). When operating as an Automatic ELT, that is automatically activated, the navigation device shall comply with the requirements of sections 4.5.5.1, 4.5.5.2 and 4.5.5.4 (if applicable). When operating as an Automatic ELT, that is manually activated, the navigation device shall comply with the requirements of sections 4.5.5.1, 4.5.5.3 and 4.5.5.4 (if applicable), 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.1, 4.5.5.2 and 4.5.5.4 (if applicable). 4.5.16.7 Duration of Continuous Operation The minimum duration of continuous operation under worst case conditions for this type of combined ELT shall be a combination of the minimum duration of continuous operation for an ELT(DT) (370 minutes) and the minimum duration of continuous operation for a regular 406 MHz beacon (24 hours), thus resulting in a total of at least 30 hours and 10 minutes. For the avoidance of doubt, if the combined ELT continues to operate after 370 minutes without crash detection, then the 30 hours and 10 minutes minimum duration of continuous operation does not apply and might be reduced as a result of the extended operation in the ELT(DT) mode. 4.5.16.8 Class of Operation The combined device may, if required, function at different classes of temperature as an ELT(DT) or Automatic ELT (e.g., the ELT(DT) part of the device may be specified to operate as a Class 1 device, while the Automatic ELT part of the device may be specified to operate as a Class 2 device). 4.5.16.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. The status of the homing signals in the transmitted beacon message shall comply with Table 3.1. 4.5.17 RLS Type 3 TWC (message) Functionality If a beacon is equipped with an RLS Type 3 Two-Way Communication (TWC) (message) functionality and is configured to transmit the RLS Type 3 TWC Rotating Field RF#4, it shall meet the following additional requirements.

4-25

4.5.17.1 RLS Type 3 TWC General Requirements a) A TWC beacon shall be provided with a means to visually and legibly display Questions, Answers and Instructions (Q/A/I) to an end user (the TWC Beacon User Interface) either: i. integral to the beacon; or ii. separate to the beacon but provided with the beacon; or iii. on a third-party device not provided with the beacon but with which the beacon can communicate by means of software made available by the beacon manufacturer for the third-party device (e.g., an App). b) In addition to the visual display, the Q/A/Is may, at the discretion of the beacon manufacturer, also be audibly announced to the end user. c) If the Q/A/I can be displayed in more than one language then there shall be a means by which the beacon user can select their desired language and subsequently change it if desired. d) The beacon shall display the initial questions according to logic (e.g., decision tree) associated with the version of the dataset installed in the beacon/user interface. e) The provision of additional Q/A/I languages shall be at the discretion of the beacon manufacturer, unless mandated by national regulations. f) The beacon or the related device shall store the selected language in memory such that when the beacon is activated in a distress it is not necessary to reselect the language. g) The beacon or the related device shall contain an approved dataset version of all the Q/A/I in at least one language. h) The beacon or the related device shall convert the user selected answer(s) from the display into the predefined set of binary numbers for transmission in the 406 message in accordance with Table 3.7, Figure 4-2 and Figure 4-3. i) The beacon or the related device shall translate what it receives as a binary number in an RLM into text on the display. j) The Q/A/I dataset shall be capable of being updated to the latest version after delivery of the beacon to the beacon user. k) The beacon user manual shall contain instructions on how to update the dataset to the latest version. l) The beacon user shall be provided with a visual indication on the beacon when a new follow-on question or instruction is first received. An audible indication may also be provided in addition to the visual signal. m) The visual indication should be reset after the beacon user has accessed the device and the beacon has displayed the new follow-on question or instruction. n) The beacon or external device shall provide the beacon user with a means by which to answer questions and respond to instructions presented to them on the display, by either: i. A set of input keys or buttons; or ii. A touch sensitive screen

4-26

o) [The beacon or external device shall provide the beacon user with a means to backtrack on an answer to a question [prior to it being transmitted] in case of an incorrect choice and to choose an alternative answer to a question.] p) The entry method shall not be by vocal means (i.e., spoken responses). q) If the beacon user selects an option to cancel the alert, the display shall require confirmation by the user, and if confirmed the beacon will activate the normal beacon cancellation function. r) The display and controls shall meet the operational requirements related to the handling of messages described in section 4.5.17.6. 4.5.17.2 Integral TWC Display / Data Entry Additional Requirements If the visual display and means of data entry are integral to the beacon, then the following additional requirements apply: a) The display shall be visible and legible both at night and during the day (but not necessarily in direct sunlight). b) The display shall operate over the operating temperature range of either a Class 1 or Class 2 beacon as defined by the beacon manufacturer. c) The display may be turned off when not in use and may time out after 30 seconds of data entry inactivity*. d) There shall be a simple means of turning the display back on without inadvertently generating an answer for transmission by the beacon. e) The means of answering questions or responding to instructions shall be self-evident (e.g., up, down, left, right and enter keys) or shall be indicated to the user on the display or the body of the beacon near the display. f) There shall be a means of testing the display to ensure that it is functioning correctly (this may be part of the beacons normal Self-Test function) g) If the Q/A/I dataset is stored in the beacon the manufacturer shall ensure that the latest version of the dataset is encoded in the beacon prior to it leaving the place of manufacture. h) When activated, the beacon shall commence the display of the first question before the second 406 MHz transmission has been emitted. 4.5.17.3 Separate TWC Display / Data Entry Additional Requirements If the visual display and means of data entry are separate to the beacon but provided with the beacon, then the following additional requirements apply: a) The display shall be visible and legible both at night and during the day (but not necessarily in direct sunlight).

For the purposes of determining the beacon’s minimum duration of continuous operation during type approval testing, a cumulative total display on-time of [60] minutes minimum, or greater as declared by the beacon manufacturer, shall be assumed.

4-27

b) The operating temperature range of the separate device shall be as specified by the beacon manufacturer. If this is different to the operating temperature range of the beacon that it is associated with, then the device shall detail the temperature range that the display will work over and contain a warning to the effect that the display may not function at the operating temperature extremes of the beacon. c) The display may be turned off when not in use and may time out after 30 seconds of data entry inactivity* d) There shall be a simple means of turning the display back on without inadvertently generating an answer for transmission by the beacon. e) The means of answering questions or responding to instructions shall be self-evident (e.g. up, down, left, right and enter keys) or shall be indicated to the user on the display or on the body of the separate device near the display. f) There shall be a means of testing the display and the connection to the beacon to ensure that it is functioning correctly. g) If the Q/A/I dataset is stored in the separate device the manufacturer shall ensure that the latest version of the dataset is encoded in the device prior to leaving the place of manufacture. h) There shall be a means of enabling two-way communications between the beacon and the separate device (e.g., hardwired, Bluetooth, Wi-Fi etc.) over a range of distances declared by the beacon manufacturer. i) The means of communication between the beacon and the separate device may go into a ‘sleep’ mode when not required to transmit data between the devices*. j) The separate device may contain its own power supply or may draw power from the beacon that it is associated with. If the separate device does contain its own power supply this shall be capable of operating the device for a minimum of [12] hours over the operating temperature range of the separate device. If the separate device is powered by the beacon, it shall not degrade the duration of continuous operation of the beacon as defined in 4.5.1 k) When the external device is activated, the external device shall commence the display of the first question within 10 seconds. 4.5.17.4 Third-Party TWC Display / Data Entry Additional Requirements If the visual display and means of data entry are provided on a third-party device (e.g., a Smartphone) then the following additional requirements apply: a) The display of Q/A/Is on the third-party device shall be legible.

For the purposes of determining the beacon’s minimum duration of continuous operation during type approval testing, a cumulative total communications time between devices of [10] minutes minimum, or greater as declared by the beacon manufacturer, shall be assumed

4-28

b) A means of answering questions or responding to instructions shall be provided on the third-party device. c) There shall be a means of testing the TWC function on the third-party device and its connection to the beacon to ensure that it is functioning correctly. d) If the Q/A/I dataset is stored on the third-party device the beacon manufacturer shall ensure that it is provided as a part of the related software Application required for the TWC functionality to run on the device. e) There shall be a means of enabling two-way communications between the beacon and the third-party device (e.g., hardwired, Bluetooth, Wi-Fi etc.) over a range of distances declared by the beacon manufacturer. f) The means of communication between the beacon and the third-party device may go into a ‘sleep’ mode when not required to transmit data between the devices*. g) The third-party device shall not be able to draw power from the beacon’s primary battery. h) The beacon user manual shall provide adequate guidance on how to download install and operate any Application required on the third-party device to enable the TWC functionality. i) The beacon user manual shall contain any necessary warnings related to the use and/or limitations on the type of third-party device and applications that the beacon can function with. j) When beacon is activated and the third party device is active, it shall commence the display of the first question within 10 seconds of the display application being accessed. 4.5.17.5 RLS Type 3 TWC (message) Mode of Operation If the RLS Type 3 Two-Way Communication (TWC) (message) functionality is enabled on a beacon, after activation and start of transmissions in accordance with section 2.2.1, the TWC capable beacon shall display the initial automatic questions. Starting from beacon activation, RF#4 and RF#0 shall be transmitted. The initial questions shall be made available to the beacon user sequentially and the next one shall be made available only when the previous one is answered by the user. However, the beacon may provide an option to skip a particular question. If a follow-on question or instruction is received during the initial questions answering phase, it shall be prioritized over the remaining initial questions. The priority among follow-on questions or instructions shall be the order of reception by the beacon.

For the purposes of determining the beacon’s minimum duration of continuous operation during type approval testing, a cumulative total communications time between devices of [10] minutes minimum, or greater as declared by the beacon manufacturer, shall be assumed

4-29

If the RLS Type 3 Two-Way Communication (TWC) (message) functionality in the beacon is not enabled, then the user shall be advised of this. The bit assignment in the RF#4 defined in Table 3.11 is represented hereafter: Figure 4-2: RF#4 bit assignment representation with the FLAM in the case where the bit 14 (Answer Format Flag) is 0 (Short) Figure 4-3: RF#4 bit assignment representation with the FLAM in the case where the bit 14 (Answer Format Flag) is 1 (Long) This assignment enables having three separate slots of 11 bits each, or one slot of 22 bits followed by one slot of 11 bits, for Questions/Answers or Instructions/Reception Acknowledgements per burst. 4.5.17.6 RLS Type 3 Two-Way Communication (TWC) (message) Operation All the answers to initial or follow-on questions shall be transmitted [as soon as available in the next] RF#4 (i.e., the beacon shall not wait until all Q&A slots in the message have been filled). In the event that the number of answers to be sent exceeds the number of slots available in the RF#4 (i.e., 2 or 3 slots, depending on the answer format configuration), the questions and associated answers shall be stacked and sent in different successive RF#4 bursts without waiting for acknowledgements from the TWC-SP. The questions and associated answers sent in the RF#4s rotate, meaning that for example, if 6 answers to short answer format questions have to be sent, the first 3 in stack are transmitted, then the next 3 answers, then the first 3 answers again etc. Beacon user’s answers (Ax slot different from default values) shall be prioritized over beacon’s acknowledgements.

4-30

In the case where multiple selectable answers to a long format answer question have to be sent, the Answer Format Flag bit shall be set to 1 and the 22-bit slot in the long format shall be used to encode the question (in the 7 bits) and the long format answer(s) (15 bits). The beacon shall inform the user (e.g., “Select all that apply”) when displaying a question that allows multiple-selectable answers (i.e., the question has the corresponding flag with value of 1). The beacon shall be able to handle a decision tree, meaning that certain questions can lead to other questions. The questions and answers at every step in the decision tree shall be transmitted [as soon as possible]. [In the case where multiple answers triggering different subsequent questions are selected, the beacon shall display the subsequent questions one after the other, in the same order as the display order of the selected answers.] 4.5.17.6.1 Operation with Initial Q&As Upon activation the beacon transmits RF#4 (alternating with RF#0) with default Q&As using the short answer format until either an Initial Question is answered or a Follow-on Question or Instruction is received (see 4.5.17.6.2 below). a) Once the user answers the first question this is inserted in Slot 1 together with its Answer and is transmitted in the next RF#4 burst. This process is repeated for subsequent Initial Q&As using other slots in the message as available. If there are more questions than slots available then Q&As are stacked and alternated in subsequent RF#4s as outlined above. b) Once an Initial Q&A has been received by the TWC-SP, it will be acknowledged by sending an Acknowledgement for the specific question (or questions) back to the beacon in an RLM containing the beacon’s 15 Hex ID (truncated from the 23 Hex ID). c) [Upon receipt of the Acknowledgement to a specific question the beacon will continue to transmit the Question in the next RF#4 burst but will change the Answer to Default (this will advise the TWC-SP that it can now stop transmitting the Acknowledgement for that specific question)]. d) [The beacon shall transmit the Question with the Default Answer in [5] bursts (as a means to try and ensure that the TWC-SP receives this message), after this period of time the beacon reverts to transmitting default data in both the Q&A part of the Slot until such time as this Slot is required to send another Q&A]. e) The same strategy applies to any other Initial Q&As, which may be contained in the same burst as the first Q&A, or may be in later bursts depending on the speed at which the user answers the Initial Questions. f) Once all the Initial Questions and associated answers have been acknowledged by the TWC-SP, unless one or more Follow-on Questions or Instructions have been received, the beacon will revert to transmitting all default Q&As.

4-31

As noted above, the Initial Q&A session may be interrupted by the reception of a Follow-on Question or Instruction from an RCC or SPOC. In this case this Follow-on question shall take priority over any unanswered Initial Questions. Note that slots in the message are generic as each slot contains all necessary data, thus it does not matter if a specific Q&A is for example transmitted in Slot 2 in one RF#4 and is then subsequently transmitted in Slot 1 in a later RF#4. 4.5.17.6.2 Operation with Follow-on Q&As or Instructions The beacon will not have answered any of the Initial Questions, or still be answering Initial Questions, or will have finished with all of these and will thus have reverted to transmitting default Q&As. Regardless of when it receives one or more Follow-on Question(s) or Instruction(s) it handles them as follows. a) As soon as the beacon receives a Follow-on Question or Instruction in an RLM containing the beacon’s 15 Hex ID (truncated from the 23 Hex ID) it shall, transmit the Follow-on Question / Instruction Number with a Default answer in a free Slot in the next RF#4 (this informs the TWC-SP that the Question / Instruction has been received). b) If there is not a free Slot in which to transmit the follow-on Question / Instruction, then this shall replace the newest other Q&A in whichever Slot it occupies in RF#4. This other Q&A shall then be transmitted in the next RF#4. RF#4 transmissions then alternate between the sets of Q&As until one or more Slots can be freed up as the result of completing the handshake with the TWC-SP. At which time the beacon reverts to providing all outstanding Q&As in a single RF#4. c) If further Questions or Instructions are received, they shall be handled in the same manner as in (a) above in the order of reception by the beacon. d) If the user has not yet answered all of the Initial Questions then any Follow-on Questions or Instructions take priority over these in terms of being presented to the user for answering. Once the Follow-on Questions or Instructions have been answered the beacon shall revert to displaying any remaining unanswered Initial Questions to the user, or if there are no more Questions or Instructions then the user shall be advised of this. e) Once the user answers a Follow-on Question or Instruction, then the message containing the Question / Instruction Number shall be updated with the relevant Answer instead of the default which shall be transmitted in the next RF#4. f) The beacon shall continue to transmit the Follow-on Question or Instruction with its Answer until it receives an RLM Acknowledging receipt containing the beacon’s 15 Hex ID (truncated from the 23 Hex ID). Once the beacon receives the acknowledgment it shall cease transmitting the Follow-on Question or Instruction with its Answer. Once all the Initial Questions and Follow-on Questions or Instructions have been addressed, the beacon will revert to transmitting default Q&As using the short answer format.

4-32

Note that slots in the message are generic as each slot contains all necessary data, thus it does not matter if a specific Q&A is for example transmitted in Slot 2 in one RF#4 and is then subsequently transmitted in Slot 1 in a later RF#4. 4.5.17.7 GNSS Receiver The RLS Type-3 TWC GNSS receiver shall comply with the requirements in section 4.5.9.1. 4.5.17.7.1 RLS Type-3 TWC GNSS Receiver Operation In addition to the beacon’s normal GNSS receiver operating cycle as defined in section 4.5.5.2 or as defined by the beacon manufacturer if the receiver is designed to be active more frequently than those requirements, the TWC beacon shall when activated with TWC functionality: a) maintain the GNSS receiver in an active mode of operation such that it can continuously check for receipt of an RLM message and Coordinated Universal Time (UTC), for a minimum period of 3 hours after beacon activation, or until the beacon is deactivated, whichever occurs first; b) as soon as possible determine UTC from the GNSS receiver and maintain a clock for at least 12 hours from the time the beacon was first activated, to the 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); c) after the first 3 hours and each subsequent hour reactivate the GNSS receiver 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 12 hours has elapsed since the beacon was activated; d) if UTC is not available after the first 3 hours the beacon shall attempt to establish UTC using the timings detailed in sections 4.5.5.2. If UTC is then established the beacon shall continue as per c) above from the next occurrence of UTC Moffset minutes; and e) after 12 hours has elapsed since beacon activation the beacon shall revert to the GNSS timings in sections 4.5.5.2. For instance, if the beacon is activated at 03:17 UTC, then the GNSS receiver would remain active until at least 06:17 UTC or the beacon is deactivated if it is deactivated before that time. The beacon GNSS receiver shall reactivate at the next occurrence of Moffset past the hour and remain active until at least Moffset+15, or the beacon is deactivated and the GNSS receiver would then reactivate again during the next hour at Moffset until Moffset+15, etc. The scheme continues as above until 12 hours has elapsed since beacon activation, that is in this example until 15:17 UTC, at which time the GNSS Receiver reverts to the GNSS timings in section 4.5.5.2. If the beacon is deactivated, then the entire operation cycle commences again from the beginning when the beacon is next activated. The TWC beacon may contain an internal GNSS receiver capable of receiving and decoding other types of RLM following the same operation cycle as the one described.

4-33

4.5.17.7.2 RLS Type-3 TWC (message) Beacon Use of Moffset The derivation of Moffset is defined in section 4.5.9.2.2. 4.5.17.8 RLS Type 3 Two-Way Communication (TWC) (message) Indicator The beacon shall be provided with a TWC indicator designed to advise the user when the first TWC message has been received by the TWC-SP and the beacon has received the first Type-3 Return Link Message (RLM). The TWC Indicator shall: a) be readily visible to the user when the beacon is operated in all its normal operational configurations as declared by the manufacturer; b) be clearly visible to the user in direct sunlight; c) provide a distinct unique indication; d) remain inactive at all times when the beacon message is encoded with any message content other than the TWC Rotating Field; e) within 5 seconds of the beacon transmitting an initial Type-3 request, commence indication of the request until either the valid RLM Type-3 message is received, or the beacon is deactivated, or the beacon battery is expired; f) within 5 seconds of the beacon receiving the first valid Type-3 RLM message acknowledgement, commence a distinct indication until either the beacon is deactivated or the beacon battery is expired; g) only provide the indication of receipt of a Type-3 request acknowledgment when the received RLM Type-3 message contains the unique 15 Hex ID subset of the 23- Hex ID programmed into that beacon and the beacon has validated that this matches its own 15- Hex ID subset of its 23- Hex ID; h) provide an indication during a self-test if the TWC functionality is enabled in accordance with section 4.5.4.1; and i) be distinct from the RLS indicator described in Section 4.5.9.3. 4.5.17.9 RLS Type 3 TWC (message) Beacon Documentation The operation of the TWC function shall be clearly explained in the User Manual including the performance characteristics of the overall TWC system. Suggested minimum text is provided in Annex H.2.

END OF SECTION 4 -

A-1

APPENDIX A - LIST OF ACRONYMS A full list of all Acronyms can be found in document C/S S.011 – Glossary.

END OF APPENDIX A -

B-1

APPENDIX B - SAMPLE BOSE-CHAUDHURI-HOCQUENGHEM ERROR- CORRECTING CODE AND 23 HEX ID CALCULATIONS NOTE: The information in the Appendix is not aligned with the current text in the main body of this document and requires an update. B.1 Sample 48-Bit BCH Code Calculation The error-correcting code used in 406 MHz messages is a shortened form of a (255,207) Bose- Chaudhuri-Hocquenghem (BCH) code. The shortened form (250,202) consists of 202 bits of data followed by a 48-bit sextuple error-correcting code. The code is used to detect and correct up to six errors in the entire 250-bit pattern (bits 1 through 250 of the 406 MHz message). Note: For the purpose of error correction, all calculations shall be performed with the full 255 length code. Therefore, 5 zeros are placed before the 202 data bits to form the 207-bit pattern of the (255,207) BCH code. These padding zeros do not affect the generation of the BCH code as described below. For the (250,202) BCH code, a generator polynomial g(X) (the same as for (255,207) BCH code) is defined as follows: 𝑔(𝑋) = 𝐿𝐶𝑀(𝑚1(𝑋), 𝑚3(𝑋), 𝑚5(𝑋), 𝑚7(𝑋), 𝑚9(𝑋), 𝑚11(𝑋)) where LCM = Least Common Multiple. In the above case: 𝑚1(𝑋) = 𝑋8 + 𝑋4+𝑋3+𝑋2 + 1 𝑚3(𝑋) = 𝑋8 + 𝑋6 + 𝑋5 + 𝑋4 + 𝑋2 + 𝑋+ 1 𝑚5(𝑋) = 𝑋8 + 𝑋7 + 𝑋6 + 𝑋5 + 𝑋4 + 𝑋+ 1 𝑚7(𝑋) = 𝑋8 + 𝑋6 + 𝑋5 + 𝑋3 + 1 𝑚9(𝑋) = 𝑋8 + 𝑋7 + 𝑋5 + 𝑋4 + 𝑋3 + 𝑋2 + 1 𝑚11(𝑋) = 𝑋8 + 𝑋7 + 𝑋6 + 𝑋5 + 𝑋2 + 𝑋+ 1 from which 𝑔(𝑋) = 𝑚1(𝑋), 𝑚3(𝑋), 𝑚5(𝑋), 𝑚7(𝑋), 𝑚9(𝑋), 𝑚11(𝑋) = 𝑋48 + 𝑋47 + 𝑋46 + 𝑋42 + 𝑋41 + 𝑋40 + 𝑋39 + 𝑋38 + 𝑋37 + 𝑋35 + 𝑋33 + 𝑋32+𝑋31

𝑋26 + 𝑋24+𝑋23+𝑋22+𝑋20+𝑋19+𝑋18+𝑋17+𝑋16+𝑋13+𝑋12+𝑋11+𝑋10+𝑋7+𝑋4+𝑋2
𝑋+ 1

B-2

a determination of g(X) results in the following 49-bit binary number 𝑔(𝑋) = 1110001111110101110000101110111110011110010010111 To generate the BCH code, an information polynomial, m(x) is formed from the 202 data bits as follows: 𝑚(𝑋) = 𝑏1𝑋201 + 𝑏2𝑋200 + ⋯+ 𝑏201𝑋+ 𝑏202 where b1 - is the first bit and b202 - is the last bit of the digital message. m (X) is then extended to 250 bits by filling the least significant bits with 48 "0". The resulting 250-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. Suppose, that the digital message in the Minimum Requirement main field consists of the following data (decimal notation): Digital Message Decimal Data Binary Data Bits in Message TAC number

1 to 16 Serial Number

17 to 30 Country code

31 to 40 Status of homing device

RLS function

Test protocol

Encoded GNSS Location See below See below 44 to 90 Vessel ID

47 Bits all 0’s 91 to 137 Beacon Type

138 to 140 Spare bits 16383 (all 1’s)

141 to 154 Message also contains encoded GNSS location. This example uses the following values of position data: Current latitude 48,793153539336956 °N Current longitude 69,00875866413116 °E Encoded GNSS location in binary notation (converted in accordance with Appendix C): Current latitude 0 0110000 110010110000110 Current longitude 0 01000101 000000100011111

B-3

In this example Rotating Field 1 (C/S G.008 Objective Requirements) is used, containing the following data: Digital Message Decimal Data Binary Data Bits in Message Rotating Field Identifier

155 to 158 Elapsed Time since activation 1 hour 27 mins

159 to 164 Time from last encoded location 6 mins 24 sec

165 to 175 Altitude of encoded location 430,24 metres

176 to 185 Dilution of precision HDOP<1 VDOP <2

186 to 193 Activation notification Manual

194 to 195 Remaining battery capacity

75%

196 to 198 GNSS status 3D

199 to 200 Spare bits

200 to 202 Thus, digital message in binary and hexadecimal notation will be the following: Bits 1-202 0000 0000 1110 0110 0000 1000 1111 0100 1100 1001 1000 0110 0001 1001 0110 0001 1000 1000 1010 0000 0100 0111 1100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1100 0000 0001 0000 0000 1100 0001 1010 0000 0000 1001 0110 00 Hex Message From 202 bits 00E608F4C986196188A047C000000000000FFFC0100C1A00960 Cospas-Sarsat Ground Segment Representation* (MF #90 Ref. C/S A.002) 0039823D32618658622811F0000000000003FFF004030680258 (two leading 0 bits plus bits 1-202)

As the length of the message in bits is not divisible by 4, the message is augmented, for ground processing purposes, with two leading binary ‘0’s, which results in this revised hexadecimal message. The division * described above is shown in Figure A1, and results in a 49-bit remainder of:

The most significant bit position of the remainder will always be a "0" and is deleted to obtain the 48- bit BCH code. Thus BCH Error-Correcting Code:

REFERENCE

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

B-4

An Introduction to Error Correcting Codes, Shu Lin, Prentice Hall 1970

B-5

5 “0” Bits 0-202 (Data bits) Bits (203-250) 48 «0» m(x)= 00000 0000000011100110000010001111010011001001100001100001100101100001100010001010000001000111 … 010000000001001011000 000000000000000000000000000000000000000000000000 g(X)=

… …

49 bits remainder =

-------- BCH Code (last 48 bits) -------→ Figure B-1: Sample 48-Bit BCH Error-Correcting Code Calculation (for easier viewing the calculation is reduced and divided into 2 parts)

B-6

B.2 Sample 23 Hex ID Calculation Using the same data as above the 23 Hex ID can be generated as shown below. It should be noted that the 23 Hex ID cannot be formed directly from the transmitted message as additional bits have to be added to it and the order of the digital message data has to be changed. Referring to T.018 Section 3.6 and Table 3.9 and using the digital message data from above results in the following: 23 Hex ID Bit No Bits Data Content Message Content

Fixed Binary ‘1’

2 to 11

C/S Country Code ‘201’

Fixed Binary ‘1’

Fixed Binary ‘0’

Fixed Binary ‘1’

15 to 30

C/S TAC No ‘230’

31 to 44

Beacon Serial Number ‘573’

Test Protocol Flag

46 to 48

Aircraft / Vessel ID Type ‘N/A’

49 to 92

Aircraft / Vessel ID 44 Bits all ‘0’s 1001 1001 0011 0100 0000 0011 1001 1000 0010 0011 1101 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 Which in turn gives a final 23 Hex ID of: 23 Hex ID 9934039823D000000000000 Which it can be seen is very different to the first 23 Hex characters of the Digital Message Data 00E608F4C986196188A047C Finally, for completeness it can be noted that the unique 15 Hex ID for the same beacon is obtained by truncating the 23 Hex ID, as described in section 3.6, which would give a 15 Hex ID of: 9934039823D0000

END OF APPENDIX B -

C-1

APPENDIX C - BEACON ENCODED LOCATION CODING C.1 ENCODED LOCATION PROTOCOL This section defines the encoded location protocol which can be used with the 406 MHz beacon message formats for encoding beacon position data in the digital message transmitted by a 406 MHz distress beacon. C.2 Summary Encode location is represented differently in second generation beacons. In first generation beacons, degrees, minutes and seconds were used. For second generation beacons, degrees and decimal part of the degrees are used. Moreover, there is no coarse and fine offset fields: all information appears in one field. Moreover, there is no separate return link location protocol. Instead, RLS data is contained in one of the rotating fields. C.3 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 the degrees are set to "1", with N/S, E/W flags set to "0"; and b) the bits in the decimal parts of the degrees are set to the following patterns: i. Latitude: 000001111100000 (Note the first five decimal parts of degrees bits are set to “0”s, the middle five bits are set to “1” s and the last 5 bits are set to “0”s) ii. Longitude: 111110000011111 (Note the first five decimal parts of degrees bits are set to “1”s, the middle five bits are set to “0” s and the last 5 bits are set to “1”s) The default pattern shall also be transmitted 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 shall radiate a single self-test message with encoded position.

C-2

This default bit pattern is different from first generation beacons. The degree bits are all set to “1”s as in first generation beacons. But it is not easy to set the minutes bit to “0”s and the seconds bits to “1”s as the decimal parts do not fall on integer minute or second boundaries. C.4 Definition of Location Data Fields The general structure of encoded location data is illustrated below. C.4.1 Encoded Location field The 47 bits available in the main digital message are defined as follows: a) bits 44-66: latitude data (23 bits), including: • bit 44: N/S flag (N=0, S=1) • bits 45-51: degrees (0 to 90) in 1 degree increments • bits 52-66: decimal parts of degrees b) bits 67-90: longitude data (24 bits), including: • bit 67: E/W flag (E=0, W=1) • bits 68-75: degrees (0 to 180) in 1 degree increments • bits 76-90 decimal parts of degrees C.4.2 Encoded Location Data (1) All position information is encoded as degrees, and decimal parts of latitude or longitude. 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, or E/W flag bit. The following table illustrates the bit assignments for the degrees portion of the encoded location field.

C-3

Latitude Bit assignment Longitude Bit assignment Bit value in degrees N/A 68 (MSB)

45 (MSB)

The following table illustrates the bit assignments for the decimal parts of the degrees portion of the encoded location field. The equivalent in minutes and seconds is also provided. The resolution in meters of each bit of longitude at the equator is also given, with the resolution of each latitude bit 0.169% less than for the longitude bit (at the equator). This reflects the fact that the circumference around the earth at the equator is 40,075.16 Km and 40,008 Km for each meridian. Latitude bit assignment Longitude Bit assignment Bit value of decimal parts in degrees Bit value of decimal parts in minutes Bit value of decimal parts in seconds Resolution in meters (equator)

0.5

55566.67

0.25

27783.33

0.125 7.5

13891.67

0.0625 3.75

6945.833

0.03125 1.875 112.5 3472.917

0.015625 0.9375 56.25 1736.458

0.0078125 0.46875 28.125 868.2292

0.00390625 0.234375 14.0625 434.1146

0.001953125 0.1171875 7.03125 217.0573

0.000976563 0.05859375 3.515625 108.5286

0.000488281 0.029296875 1.7578125 54.26432

0.000244141 0.014648438 0.87890625 27.13216

0.00012207 0.007324219 0.439453125 13.56608

6.10352E-05 0.003662109 0.219726563 6.78304

3.05176E-05 0.001831055 0.109863281 3.39152 C.5 Instructions for converting Latitudes and Longitudes to a Binary Number Global Navigation Satellite System receivers (e.g., GPS, Glonass, Galileo, BDS, etc.) normally output position data using an IEC 61162-1 (NMEA 0183) formatted sentence. This will provide a position in decimal degrees, minutes and parts of a minute as a decimal fraction in a defined format for example “3546.295, N, 14821.291, W”. That is 35 degrees and 46.295 minutes North by 148 degrees and 21.291

C-4

minutes West. The size of the decimal fraction is not defined In IEC 61162-1, but in order to ensure adequate accuracy initially and during subsequent rounding processes the number of digits after the decimal point should not be less than 3. In order to transmit this as a part of a Second Generation Beacon message it is necessary to convert the position into a binary number expressed as degrees and a decimal fraction of a degree. The following text provides an example of how this can be achieved. Referring to C/S T.018 Table 3.1 Encoded GNSS Location we can see that the required message format is as follows: No of Bits Content

N/S flag (N=0, S=1)

Degrees (0 to 90) in 1 degree increments

Decimal parts of a degree (0.5 to 0.00003)

E/W flag (E=0. W=1)

Degrees (0 to 180) in 1 degree increments

Decimal parts of a degree (0.5 to 0.00003) The use of the bits for the N/S or E/W flags and the encoding of Degrees is straightforward and no further explanation is deemed necessary. But converting minutes and a decimal fraction of a minute to decimal parts of a degree and then to binary is less obvious, so an example of this is provided below. Using the example above “3546.295, N” in binary would appear as follows: N/ S Degrees Decimal Parts of a Degree 0/1

8 4 2 1 1/

1/1

1/3

1/6

. . . . . . . . . . . . . . . . . .

0 0 1 1

0 1 1 0 0 0 0 1 1 Initially the minutes and decimal fraction of minutes must be converted into a decimal fraction of a degree, this is achieved by simply dividing the whole number by 60 e.g., 46.295 Minutes divided by 60 equals 0.77158333 Degrees. Again in order to maintain accuracy this number should be rounded to no less than [5] decimal places e.g., [0.77158]. So 35 Degrees and 46.295 Minutes becomes [35.77158] Degrees. Two procedures for converting decimal parts of a degree to binary are provided below, the first uses the Successive Multiplication Method while the second uses the Integral Number Conversion Method. Successive Multiplication Method

Start with the decimal fraction part and multiply it by 2 (add it to itself)
If the result is greater than 1 then the first decimal fraction is a 1, if the result is less than 1 then the first decimal fraction is a 0
If the result was greater than 1 then subtract 1 from the result
Multiply the remaining number by 2
Repeat step 2) to obtain the second decimal fraction and then repeat steps 3) and 4)
Repeat step 5) for all the remaining decimal fractions

C-5

On completing the final step to obtain the fifteenth digit again repeat step 3), if the remainder is 0.5 or greater then increase the computed binary number by one to round to the closest possible number, or if the remaining number is less than 0.5 then use the binary number as computed The above example is provided below:
0.77158 x 2 = 1.54316 thus the first digit is a 1
1.54316 – 1 = 0.54316
0.54316 x 2 = 1.08632 thus the second digit is a 1
1.08632 – 1 = 0.08632
0.08632 x 2 = 0.1728 thus the third digit is a 0
0.17264 x 2 = 0.34528 thus the fourth digit is a 0
0.34528 x 2 = 0.69056 thus the fifth digit is a 0
0.69056 x 2 = 1.38112 thus the sixth digit is a 1
1.38112 – 1 = 0.38112
0.38112 x 2 = 0.76224 thus the seventh digit is a 0
Keep going as above
0.78336 x 2 = 1.56672 thus the fourteenth digit is a 1
1.56672 – 1 = 0.56672
0.56672 x 2 = 1.13344 thus the last digit is a 1
1.13344 – 1 = 0.13344
If the remaining number is 0.5 or greater then increase the computed binary number above by one to round to the closest possible number, or if the remaining number is less than 0.5 then use the binary number computed above
In this example, one computed 110001011000011, applying the rounding rule above means that in this instance the actual binary number to use is the same Integral Number Conversion Method
Start with the decimal fraction part and multiply it by 215 (2 to the power of 15)
Round the result to the nearest whole number
Convert this number to binary
The result is the binary fraction of the decimal fraction The above example is provided below:
0.77158 x 215 = 25283.13344
Rounding gives us 25283
Converting 25283 to binary gives 110001011000011

END OF APPENDIX C -

D-1

APPENDIX D - EXAMPLE OF LINEAR FEEDBACK SHIFT REGISTER (LFSR) IMPLEMENTATION The spreading PRN sequences are generated by a method equivalent to a Linear Feedback Shift Register (LFSR) using the generator polynomial G(x) = X23 + X18 + 1. The generator polynomial initialization values for I and Q components for beacon normal mode operation and for beacon self- test mode operation are given in Table 2.2. This appendix details the generation of the 64 first chips of the normal I-component using the LSFR implementation described in section 2.2.3 with the initialization value 000 0000 0000 0000 0000 0001 (see Table 2.2). The last column gives the result of the PRN sequence generation (here 8000 0108 4212 84A1, as per Table 2.2).

D-2

Figure D-1: Example of LSFR with the generation of the 64 first chips of the normal I- component 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Out 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0

1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0

0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0

0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0

0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0

0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0

1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0

0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0

0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0

0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0

0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0

1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0

0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1

0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0

1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0

0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0

1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0

0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1

0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0

0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0

0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0

1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0

0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1

0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0

1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0

D-3

0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0

1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0

0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1

0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0

0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0

0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0

1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0

0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1

0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0

1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0

0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1

1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0

1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1

0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0

0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0

0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0

1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0

1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1

0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0

1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0

0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1

1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0

A 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1

0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0

0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0

0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0

1 0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0

0 1 0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1

0 0 1 0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0

END OF APPENDIX D -

E-1

APPENDIX E - BIT ASSIGNMENT NUMBERS

Homing Status RLS Function Test Protocol

Bits 1 to 43 of 202 Information bits 1 to 43 of 154 bit Main Field Bits 44 to 90 of 202 Information bits 44 to 90 of 154 bit Main Field TAC Number (16 bits) (Part of 23 HEX ID) Serial Number (14 bits) (Part of 23 HEX ID) Country Code (10 bits) (Part of 23 HEX ID) 23 HEX ID bit numbers Encoded Location (47 bits) Vessel ID (47 bits) (Part of 23 HEX ID) Bits 138 to 154 of 202 Information bits 138 to 154 of 154 bit Main Field Bits 91 to 137 of 202 Information bits 91 to 137 of 154 bit Main Field Beacon Type (3 bits) Spare Bits (14 bits) 23 HEX ID bit numbers Bits 203 to 250 of message bits (Error Correction Code) 48 bits BCH (250,202) Rotating Field Information (48 bits) Bits 155 to 202 of 202 Information bits

E-2

Rotating Field #0 (C/S G.008 Requirements) (48 bits) Bits 155 to 202 of 202 Information bits Rotating Field bit number Bits 155 to 202 of 202 Information bits Rotating Field #1 (ELT(DT)) (48 bits) Rotating Field bit number Bits 155 to 202 of 202 Information bits Time of last encoded location (11 bits) Altitude of encoded location (10 bits) Triggering Event (4 bits) Rotating Field bit number Bits 155 to 202 of 202 Information bits Beacon Feedback (acknowledgement of RLM reception) (22 bits) Unassigned (11 bits) National Use (44 bits) Dilution of Precision (8 bits) Activation (2 bits) Rotating Field #15 (Cancellation Message) (48 bits) Rotating Field bit number Rotating Field ID "0000" (4 bits) Rotating Field ID "0001" (4 bits) Rotating Field ID "0010" (4 bits) Rotating Field ID "0011" (4 bits) Rotating Field ID "1111" (4 bits) Rotating Field #2 (RLS) (48 bits) Rotating Field bit number Bits 155 to 202 of 202 Information bits Rotating Field #3 (National Use) (48 bits) Fixed (all 1's) (42 bits) Method of Deactivation GNSS Status (2 bits) Remaining Battery (2 bits) Spare (9 bits) Unassigned (2 bits) Beacon RLS Capability (6 bits) RLS Provider ID (3 bits) Remaining Battery (3 bits) GNSS Status (2 bits) Spare (2 bits) Elapsed Time since Activation (6 bits) Time from last encoded location (11 bits) Altitude of encoded location (10 bits) NOTE: When displaying a message as 63 hex characters, one bit is inserted at the beginning of the message to indicate the PRN sequence (0 = Normal, 1 = self-test), followed by one zero, to form the 63 hexadecimal representation (2 bits + 250 bit message) for processing by the Cospas-Sarsat ground segment.

END OF APPENDIX E -

F-1

APPENDIX F - MOFFSET CALCULATIONS AND CRC CODE SAMPLE Note that the computation of the CRC for the MOffset uses an initial value of 0000 (hexadecimal), which does not affect the computation shown below. 1 0 0 1 1 0 0 1 0 0 1 1 0 1 0 0 0 0 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 0 1 0 0 0 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 CRC-polynomial: x16+x15+x2+1 15 Hex ID: 9934039823D8000 0 1 0 1 1 0 0 1 0 0 1 1 0 1 1 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 1 0 0 1 0 0 1 1 0 1 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 1 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1 1 0 1 0 1 0 1 0 1 0 0 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 0 0 1 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 1 0 1 0 0 1 0 1 0 1 1 1 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 1 0 1 0 1 1 1 1 0 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 1 1 1 1 0 1 1 1 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 0 1 0 1 1 1 1 0 1 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 1 1 1 1 0 1 1 1 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 1 1 1 0 1 1 1 0 1 0 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 1 1 0 1 1 1 0 1 0 0 1 0 0 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 1 1 1 0 1 0 0 1 0 0 0 0 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 1 1 0 1 0 0 1 0 0 0 0 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 1 0 1 0 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 0 0 1 1 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 0 0 0 0 0 1 1 0 0 1 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 1 0 0 1 1 1 0 1 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 1 1 0 1 1 0 0 0 0 1 0 1 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 1 1 0 0 0 0 1 0 1 0 1 0 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 1 0 0 0 0 1 0 1 0 1 0 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 1 0 0 1 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 1 0 1 0 1 0 0 1 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 1 0 1 0 1 0 0 1 1 0 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 0 1 1 0 1 0 1 1 CRC-16(9934039823D8000) = 0xAA6B and Moffset=BIN2DEC(CRC-16(9934039823D8000)) mod 60 = 7 Figure F-1: Example of calculation of Moffset

F-2

END OF APPENDIX F -

G-1

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

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

G-2

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

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

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

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

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

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

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

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

4:01 GNSS Receiver next turns off at 4:07§ GNSS Receiver reverts to non- RLS operation 6:00 4:07 Note that interleaved with the GNSS Receiver timings, the GNSS receiver also turns on in accordance with section 4.5.5.2, 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.018, section 4.5.5.2. † 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.018 section 4.5.5.2 timing, until UTC is obtained.

G-3

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

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

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

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

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

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

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

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

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.

H-1

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

H-2

H.2 Information to be Included in the User Manual of an RLS Type 3 TWC-Capable Beacon This beacon features the Two-Way Communication (TWC) capability. The TWC function provides the beacon user with a confirmation indication that the distress signal from an activated beacon has been detected by the Cospas-Sarsat System and is being transmitted to the responsible Search-And-Rescue (SAR) Authorities. It is important to note that this confirmation does NOT imply that a search and rescue operation has been organized or initiated. In addition, the TWC feature enables the beacon user to establish communication with the appropriate SAR Authorities. TWC functionality relies on the exchange of information between beacon user and SAR Authorities, aiming to facilitate and enhance SAR operations by allowing the beacon user to provide valuable information to, or receive instructions from, SAR Authorities. Upon beacon activation, a series of initial automatic questions will be displayed for the beacon user to respond to. The answers encoded by the user will be transmitted to the SAR Authorities as soon as possible. SAR Authorities have the capability to send new or previously asked questions and instructions to the beacon user. New messages sent from SAR Authorities will take priority over the initial automatic questions should the user not have completed answering them. The TWC is designed to send an acknowledgment to the beacon user in less than 30 minutes from beacon activation (actual acknowledgement times are typically in the order of few minutes). It is important to highlight that alerting the distress to SAR authorities is independent of, and may occur before, the TWC acknowledgment indication on the beacon. The TWC specification is detailed in the Galileo SAR Service Definition Document Issue (TBD). TWC is an optional function and may not be permitted in all countries or for all beacon types. You may visit the web page Where Can I Buy an TWC-Enabled Beacon? (TBD) to learn the most recent information about national support for TWC. Cospas-Sarsat strongly recommends that you appropriately register your beacon. It only is possible to register a beacon in the registry operated by the country matching the “country code” electronically programmed into the beacon or the International Beacon Registration Database (IBRD) (https://www.406registration.com/) if the country uses the IBRD for their registrations. For example, it only is possible to register a beacon with a French country code in France’s national registry. However, owners of Belgian-coded beacons must register in the IBRD. The country code is encoded in the beacon’s unique identification number (UIN, also called Hex ID), which is used to register the beacon. Visit the web page Beacon Registration Contacts to see where you can register your beacon. (https://www.406registration.com/countriessupported.aspx) – END OF APPENDIX H –

I-1

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

I-2

AIRCRAFT – In addition to the TAC and Serial Number aircraft may also be coded with one of three forms of identity, either the Aircraft Registration Marking (commonly referred to as the Tail Number), the Aviation 24-Bit Address (as used by the ADS-B system) or the Aircraft Operator designator followed by a serial number. The Aviation 24-Bit Address may also be followed by the 3-letter Aircraft Operator Designator (3LD), which is essential for ELT(DT)s. Aircraft Registration Marking – This identity, often referred to as the aircraft Tail Number can be encoded in up to 7 alphanumerical characters. Aviation 24-Bit Address – This identity is becoming more common in larger aircraft as it is allocated to an aircraft for use with systems such as the ADS-B. For ELT(DT)s required to meet the Automatic Distress Tracking (ADT) requirements of the ICAO GADSS system, it is essential to code the ELT(DT) with the aircraft 24-Bit address followed by the 3-letter Aircraft Operator Designator, as both of these data items are required by the ICAO Location of an Aircraft in Distress Repository (LADR). Note that the Aircraft 24-Bit address followed by the Aircraft Operator Designator can also be used to code ELTs other than ELT(DT)s if required. Aircraft Operator and Serial Number – This identity is less common but can be used to identify an aircraft it consists of the identity of the aircraft operator followed by a serial number allocated to the beacon by the aircraft operator to create a unique identity for that aircraft. – END OF DOCUMENT –

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

205 KiB

Raw Blame History

Bits

Bits

Bits

Bits

Bits

Bits

Bits

Bits

Bits

when the GNSS Self-test is initiated, the beacon shall attempt to obtain location data from the internal navigation device, if this data is available,

if location data is not available from the internal navigation device, then the beacon shall obtain the location data from the external navigation interface,

205 KiB Raw Blame History Unescape Escape

Bits

Bits

Bits

Bits

Bits

Bits

Bits

Bits

Bits

when the GNSS Self-test is initiated, the beacon shall attempt to obtain location data from the internal navigation device, if this data is available,

if location data is not available from the internal navigation device, then the beacon shall obtain the location data from the external navigation interface,

205 KiB

Raw Blame History