Ryan Malloy
4ed92efd69
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.
5523 lines
196 KiB
Markdown
5523 lines
196 KiB
Markdown
---
|
||
title: "T001: C/S T.001 - Issue 4 - Rev. 13"
|
||
description: "Official Cospas-Sarsat T-series document T001"
|
||
sidebar:
|
||
badge:
|
||
text: "T"
|
||
variant: "note"
|
||
# Extended Cospas-Sarsat metadata
|
||
documentId: "T001"
|
||
series: "T"
|
||
seriesName: "Technical"
|
||
documentType: "specification"
|
||
isLatest: true
|
||
issue: 4
|
||
revision: 13
|
||
documentDate: "October 2025"
|
||
originalTitle: "C/S T.001 - Issue 4 - Rev. 13"
|
||
---
|
||
|
||
> **📋 Document Information**
|
||
>
|
||
> **Series:** T-Series (Technical)
|
||
> **Version:** Issue 4 - Revision 13
|
||
> **Date:** October 2025
|
||
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)
|
||
|
||
---
|
||
|
||
SPECIFICATION FOR
|
||
COSPAS-SARSAT
|
||
406 MHz DISTRESS BEACONS
|
||
C/S T.001
|
||
Issue 4 – Revision 13
|
||
|
||
|
||
|
||
|
||
SPECIFICATION FOR COSPAS-SARSAT
|
||
406 MHz DISTRESS BEACONS
|
||
History
|
||
Issue
|
||
Revision
|
||
Date
|
||
Comments
|
||
|
||
|
||
Approved by the Cospas-Sarsat Steering Committee
|
||
(CSSC-15)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-15)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-19)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-21)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-23)
|
||
|
||
|
||
Editorial changes, approved by the Cospas-Sarsat Council
|
||
(CSC-25) as Corrigendum to C/S T.001 Issue 3 - Rev.3
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-29)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-31)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-33)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-35)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-39)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-41)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-43)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-45)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-47)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-49)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-51)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-53)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-55)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-57)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-58)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-59)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-60)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-61)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-62)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-63)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-64)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-65)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-66)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-67)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-69)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-71)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-73)
|
||
|
||
|
||
TABLE OF CONTENTS
|
||
Page
|
||
History
|
||
........................................................................................................................................ i
|
||
Table of Contents ................................................................................................................................. ii
|
||
List of Figures
|
||
................................................................................................................................. v
|
||
List of Tables
|
||
................................................................................................................................. v
|
||
1.
|
||
Introduction ............................................................................................................. 1-1
|
||
1.1
|
||
Purpose ....................................................................................................................... 1-1
|
||
1.2
|
||
Scope .......................................................................................................................... 1-1
|
||
2.
|
||
System Requirements ............................................................................................. 2-1
|
||
2.1
|
||
Beacon Functional Elements ...................................................................................... 2-1
|
||
2.2
|
||
Digital Message Generator ......................................................................................... 2-1
|
||
Repetition Period ...........................................................................................2-1
|
||
Total Transmission Time ...............................................................................2-2
|
||
Unmodulated Carrier .....................................................................................2-2
|
||
Digital Message .............................................................................................2-4
|
||
2.2.4.1 Bit Synchronization ....................................................................................................2-4
|
||
2.2.4.2 Frame Synchronization ...............................................................................................2-4
|
||
2.2.4.3 Format Flag ................................................................................................................2-4
|
||
2.2.4.4 Message Content ........................................................................................................2-4
|
||
2.3
|
||
Modulator and 406 MHz Transmitter ........................................................................ 2-5
|
||
Transmitted Frequency ..................................................................................2-5
|
||
Transmitter Power Output .............................................................................2-6
|
||
Antenna Characteristics .................................................................................2-7
|
||
Spurious Emissions ........................................................................................2-7
|
||
Data Encoding................................................................................................2-8
|
||
Modulation .....................................................................................................2-8
|
||
Voltage Standing-Wave Ratio .......................................................................2-8
|
||
Maximum Continuous Transmission .............................................................2-8
|
||
3.
|
||
DIGITAL MESSAGE CONTENT ........................................................................ 3-1
|
||
3.2
|
||
Basic Structure ............................................................................................................ 3-1
|
||
3.3
|
||
Beacon Coding ........................................................................................................... 3-2
|
||
3.4
|
||
Cancellation Message (ELT(DT) only) ...................................................................... 3-2
|
||
4.
|
||
ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS .................... 4-1
|
||
4.1
|
||
General ....................................................................................................................... 4-1
|
||
4.2
|
||
Thermal Environment................................................................................................. 4-1
|
||
Operating Temperature Range .......................................................................4-1
|
||
Temperature Gradient ....................................................................................4-1
|
||
Thermal Shock ...............................................................................................4-1
|
||
4.3
|
||
Mechanical Environment ........................................................................................... 4-2
|
||
4.4
|
||
Other Environmental Requirements ........................................................................... 4-3
|
||
4.5
|
||
Operational Requirements .......................................................................................... 4-3
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Duration of Continuous Operation ................................................................4-3
|
||
Other Operational Requirements ...................................................................4-3
|
||
Auxiliary Radio-Locating Device ..................................................................4-3
|
||
Beacon Self-Test Mode .................................................................................4-4
|
||
Encoded Position Data ...................................................................................4-7
|
||
4.5.5.1 General .......................................................................................................................4-7
|
||
4.5.5.2 Message Content and Timing .....................................................................................4-7
|
||
4.5.5.3 Internal Navigation Device Performance ...................................................................4-8
|
||
4.5.5.4 Internal Navigation Device Timing ............................................................................4-9
|
||
4.5.5.5 External Navigation Device Input ............................................................................4-10
|
||
4.5.5.6 ELT(DT) Navigation Device Requirements .............................................................4-10
|
||
Beacon Activation........................................................................................4-12
|
||
4.5.6.1 ELT(DT) Modes of Operation ..................................................................................4-13
|
||
RLS Beacon Requirements ..........................................................................4-14
|
||
4.5.7.1 GNSS Receiver ........................................................................................................4-15
|
||
4.5.7.2 RLS GNSS Receiver Operation ...............................................................................4-15
|
||
4.5.7.2.1 Operation Cycle ........................................................................................................4-15
|
||
4.5.7.2.2 Derivation of Moffset ...............................................................................................4-17
|
||
4.5.7.3 Indications of RLS and RLM ...................................................................................4-17
|
||
4.5.7.4 Confirmation of a Return-Link Message Receipt .....................................................4-18
|
||
4.5.7.5 RLS Beacon Documentation ....................................................................................4-18
|
||
Beacon Labelling and Marking ....................................................................4-18
|
||
Operator Controlled Voice Transceivers .....................................................4-19
|
||
ELT(DT)s Specifically Designed to Withstand a Crash Impact ..................4-20
|
||
4.5.10.1 Introduction ..............................................................................................................4-20
|
||
4.5.10.2 Beacon Hex ID .........................................................................................................4-20
|
||
4.5.10.3 Burst Repetition Period (with Crash Detection) .......................................................4-20
|
||
4.5.10.4 GNSS Update Rate (after Crash Detection) .............................................................4-21
|
||
4.5.10.5 Duration of Continuous Operation ...........................................................................4-21
|
||
4.5.10.6 Homing and Locating Signals ..................................................................................4-22
|
||
ELT(DT)s Combined with Automatic ELTs ...............................................4-22
|
||
4.5.11.1 Introduction ..............................................................................................................4-22
|
||
4.5.11.2 Beacon Coding and Beacon Hex ID .........................................................................4-22
|
||
4.5.11.3 Burst Repetition Period ............................................................................................4-23
|
||
4.5.11.4 System Requirements ...............................................................................................4-23
|
||
4.5.11.5 Cancellation Message ...............................................................................................4-24
|
||
4.5.11.6 Encoded Position Data and Navigation Device Performance ..................................4-24
|
||
4.5.11.7 Duration of Continuous Operation ...........................................................................4-24
|
||
4.5.11.8 Class of Operation ....................................................................................................4-24
|
||
4.5.11.9 Homing and Locating Signals ..................................................................................4-24
|
||
External Power Source for ELT(DT)s .........................................................4-25
|
||
ANNEX A BEACON CODING ............................................................................................... A-1
|
||
A1
|
||
GENERAL ................................................................................................................ A-1
|
||
A1.1
|
||
Summary ....................................................................................................... A-1
|
||
A1.2
|
||
Message Format Flag, Protocol Flag, and Country Code ............................. A-2
|
||
A1.2.1 Format Flag ............................................................................................................... A-2
|
||
A1.2.2 Protocol Flag ............................................................................................................. A-2
|
||
A1.2.3 Country Code ............................................................................................................ A-2
|
||
A1.3
|
||
Protocol Codes .............................................................................................. A-3
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
A2
|
||
USER PROTOCOLS ................................................................................................ A-5
|
||
A2.1
|
||
Structure of User Protocols ........................................................................... A-5
|
||
A2.2
|
||
Maritime User Protocol ................................................................................ A-7
|
||
A2.3
|
||
Radio Call Sign User Protocol ...................................................................... A-8
|
||
A2.4
|
||
Aviation User Protocol ................................................................................. A-9
|
||
A2.5
|
||
Serial User Protocol ...................................................................................... A-9
|
||
A2.5.1 Serial Number ......................................................................................................... A-10
|
||
A2.5.2 Aircraft 24-bit Address ............................................................................................ A-11
|
||
A2.5.3 Aircraft Operator Designator and Serial Number .................................................... A-11
|
||
A2.6
|
||
Test User Protocol ...................................................................................... A-12
|
||
A2.7
|
||
Orbitography Protocol ................................................................................ A-12
|
||
A2.8
|
||
National User Protocol................................................................................ A-12
|
||
A2.9
|
||
Non-Protected Data Field ........................................................................... A-13
|
||
A2.9.1 Maritime Emergency code ...................................................................................... A-14
|
||
A2.9.2 Non-Maritime Emergency code .............................................................................. A-14
|
||
A2.9.3 National Use ............................................................................................................ A-15
|
||
A3
|
||
LOCATION PROTOCOLS .................................................................................... A-17
|
||
A3.1
|
||
Summary ..................................................................................................... A-17
|
||
A3.2
|
||
Default Values in Position Data .................................................................. A-18
|
||
A3.3
|
||
Definition of Location Protocols ................................................................ A-19
|
||
A3.3.1 Position Data ........................................................................................................... A-19
|
||
A3.3.2 Supplementary Data ................................................................................................ A-19
|
||
A3.3.3 Test Location Protocols ........................................................................................... A-21
|
||
A3.3.4 User-Location Protocols (See Figure A7) ............................................................... A-23
|
||
A3.3.5 Standard Location Protocols (see Figure A8) .......................................................... A-25
|
||
A3.3.6 National Location Protocol (see Figure A9) ............................................................ A-28
|
||
A3.3.7 RLS Location Protocol (see Figure A10) ................................................................ A-31
|
||
A3.3.8 ELT(DT) Location Protocol (see Figure A11) ........................................................ A-36
|
||
ANNEX B BCH AND CRC CalculationS ............................................................................... B-1
|
||
B1
|
||
Sample 21-Bit BCH Code Calculation ...................................................................... B-1
|
||
B2
|
||
Sample 12-Bit BCH Code Calculation ...................................................................... B-4
|
||
ANNEX C EXAMPLES OF RLS GNSS RECEIVER TIMING .......................................... C-1
|
||
ANNEX D RLS Information .................................................................................................... D-1
|
||
|
||
|
||
LIST OF FIGURES
|
||
Figure 2.1: Burst Transmission Scheme for ELT(DT)s transmitting the 3LD aircraft operator
|
||
designator in PDF-2....................................................................................................2-1
|
||
Figure 2.2: Short Message Format ......................................................................................................2-4
|
||
Figure 2.3: Long Message Format ......................................................................................................2-5
|
||
Figure 2.4: Spurious Emission Mask for 406.0 to 406.1 MHz Band ..................................................2-7
|
||
Figure 2.5: Data Encoding and Modulation Sense ...............................................................................2-8
|
||
Figure 2.6: Definition of Modulation Rise and Fall Times ..................................................................2-9
|
||
Figure 2.7: Definition of Modulation Symmetry .................................................................................2-9
|
||
Figure 4.1: Temperature Gradient .......................................................................................................4-2
|
||
Figure A1: Data Fields of the Short Message Format ....................................................................... A-3
|
||
Figure A2: Data Fields of the Long Message Format ........................................................................ A-3
|
||
Figure A3: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols ............... A-6
|
||
Figure A4: Summary of User Protocols Coding Options ................................................................ A-16
|
||
Figure A5: Outline of Location Protocols........................................................................................ A-18
|
||
Figure A6: General Format of Long Message for Location Protocols ............................................ A-22
|
||
Figure A7: User-Location Protocol.................................................................................................. A-24
|
||
Figure A8: Standard Location Protocols .......................................................................................... A-27
|
||
Figure A9: National Location Protocol ............................................................................................ A-30
|
||
Figure A10: RLS Location Protocol ................................................................................................ A-35
|
||
Figure A11: ELT(DT) Location Protocol ........................................................................................ A-40
|
||
Figure B1: Sample 21-Bit BCH Error-Correcting Code Calculation ............................................... B-3
|
||
Figure B2: Sample 12-Bit BCH Error-Correcting Code Calculation ............................................... B-5
|
||
LIST OF TABLES
|
||
Table A1: Format Flag and Protocol Flag Combinations .................................................................... A-3
|
||
Table A2: Protocol Codes Assignments ............................................................................................ A-4
|
||
Table A3: Modified-Baudot Code ..................................................................................................... A-7
|
||
Table A4: Maritime Emergency Codes in Accordance with the Modified (1) IMO Nature of
|
||
Distress Indication ................................................................................................... A-15
|
||
Table A5: Non-Maritime Emergency Codes ................................................................................... A-15
|
||
|
||
1-1
|
||
|
||
1.
|
||
INTRODUCTION
|
||
1.1
|
||
Purpose
|
||
The purpose of this document is to define the minimum requirements to be used for the development
|
||
and manufacture of 406 MHz Emergency Locator Transmitters (ELTs), Emergency
|
||
Position-Indicating Radio Beacons (EPIRBs), and Personal Locator Beacons (PLBs). In this
|
||
document, the term ELT indicates an aviation distress beacon, an EPIRB a maritime distress beacon,
|
||
and a PLB a distress beacon for personal use.
|
||
Specifications that are critical to the Cospas-Sarsat System are defined in detail; specifications which
|
||
could be developed by the national authorities are identified in more general terms.
|
||
Where there are specific requirements in this document for a distress tracking ELT (ELT(DT)) these
|
||
refer to a specific type of ELT designed to be activated prior to a crash and to function in compliance
|
||
with the ICAO GADSS* requirements for the location of an aeroplane in distress, aimed at
|
||
establishing, to a reasonable extent, the location of an accident site within a 6 NM radius. An
|
||
ELT(DT) may be activated automatically upon detection of a distress condition while in flight or it
|
||
may also be activated manually.
|
||
1.2
|
||
Scope
|
||
This document contains the minimum requirements that apply to Cospas-Sarsat 406 MHz distress
|
||
beacons. It is divided into the following sections:
|
||
Section 2 gives the system requirements applicable to all types of beacons. When
|
||
met, these requirements will enable the beacons to provide the intended service in
|
||
terms of location probability and accuracy and will not disturb the system
|
||
operation.
|
||
Section 3 deals with the beacon message content. Basic message structure is
|
||
defined. Assignment and meaning of the available data bits are defined in
|
||
Annex A to this specification.
|
||
Section 4 defines a set of environmental and operational requirements. These
|
||
requirements are not intended to be exhaustive and may be complemented by more
|
||
detailed national or international standards (e.g., RTCA standards for ELTs).
|
||
However, they represent the minimum environmental and operational
|
||
performance requirements for a 406 MHz beacon to be compatible with the
|
||
Cospas-Sarsat System.
|
||
* See ICAO Convention on International Civil Aviation Annex 6, Part 1.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
1-2
|
||
|
||
Annex A defines the beacon coding.
|
||
Annex B provides samples of error correcting code calculations, Moffset
|
||
calculations and CRC code sample.
|
||
A full list of acronyms used in this document can be found in document C/S S.011,
|
||
“Cospas-Sarsat Glossary”.
|
||
- END OF SECTION 1 -
|
||
|
||
|
||
|
||
|
||
|
||
2-1
|
||
|
||
2.
|
||
SYSTEM REQUIREMENTS
|
||
2.1
|
||
Beacon Functional Elements
|
||
This section defines the requirements for the two following functional elements of a 406 MHz
|
||
distress beacon:
|
||
digital message generator; and
|
||
modulator and 406 MHz transmitter.
|
||
2.2
|
||
Digital Message Generator
|
||
The digital message generator will key the modulator and transmitter so that the message defined
|
||
in section 3 is transmitted.
|
||
Repetition Period
|
||
The repetition period shall not be so stable that any two transmitters appear to be synchronized
|
||
closer than a few seconds over a 5-minute period. The intent is that no two beacons will have all
|
||
of their bursts coincident. The repetition period (TR) shall be randomised around a mean value of
|
||
50 seconds, so that time intervals between the beginnings of two successive bursts are randomly
|
||
distributed on the interval from 47.5 to 52.5 seconds. The average repetition period shall be 50
|
||
seconds ± 1.5 seconds.
|
||
For ELT(DT)s (except those transmitting the 3LD* aircraft operator designator in PDF-2) the
|
||
value of the repetition period shall be as follows:
|
||
From beacon activation, transmit a total of 24 bursts, the time interval between the
|
||
beginning of two successive bursts shall be 5 seconds +0.0 / - 0.2 seconds. The
|
||
first burst timing shall meet the requirements of 4.5.6;
|
||
Then transmit a further 18 bursts commencing 10 seconds + 0.0 / - 0.2 after the
|
||
burst 24, at time intervals between the beginning of two successive bursts of
|
||
10 seconds +0.0 / - 0.2 seconds; and
|
||
The next burst (burst number 43) shall then start between 27.0 and 30.0 seconds
|
||
after the beginning of burst 42. Subsequent bursts shall be randomized with
|
||
uniform (flat) distribution around a mean value of 28.5 seconds so that the time
|
||
* 3LD is a 3-letter aircraft operator designator from the list of "Designators for Aircraft Operating Agencies,
|
||
Aeronautical Authorities and Services" published by the International Civil Aviation Organization (ICAO) as
|
||
document 8585.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
2-2
|
||
|
||
intervals between the beginnings of two successive bursts (TR) are randomly
|
||
distributed on the interval 27.0 to 30.0 seconds. The standard deviation over
|
||
18 successive bursts of TR shall be greater than 0.8 seconds. The minimum value
|
||
of TR observed over the 18 successive bursts shall be between 27.0 and
|
||
27.2 seconds, the maximum value of TR observed over the 18 successive bursts
|
||
shall be between 29.8 and 30.0 seconds.
|
||
For ELT(DT)s transmitting the 3LD aircraft operator designator in PDF-2, the transmission
|
||
scheme is as follows. An illustrative version of this is provided in Figure 2.1.
|
||
From beacon activation, transmit a total of 24 bursts, the time interval between the beginning of two
|
||
successive bursts shall be 5 seconds +0.0 / - 0.2 seconds and every 4th burst starting with burst 2 shall
|
||
transmit the 3LD.
|
||
The first burst timing shall meet the requirements of 4.5.6.
|
||
Then transmit a further 18 bursts commencing 10 seconds + 0.0 / - 0.2 after the 24th burst, at time
|
||
intervals between the beginning of two successive bursts of 10 seconds + 0.0 / - 0.2 seconds. In
|
||
addition, transmit an additional burst, containing the 3LD, 5 seconds +/- 0.5 seconds after the beginning
|
||
of the first of these 18 bursts and then after every 6th burst (i.e. 3 additional bursts with the 3LD,
|
||
interleaved between the 18 bursts, making a total of 21 bursts).
|
||
The next burst shall then start between 27.0 and 30.0 seconds after the beginning of the last (45th) burst
|
||
and subsequent bursts shall be randomized with uniform (flat) distribution around a mean value of
|
||
28.5 seconds so that the time intervals between the beginnings of two successive bursts (TR) are
|
||
randomly distributed on the interval 27.0 to 30.0 seconds. In addition, an additional burst containing
|
||
the 3LD shall be transmitted after the 16th of these bursts and then after every 30th burst thereafter at
|
||
15 seconds +/- 0.5 seconds after the beginning of the previous burst. The standard deviation over
|
||
18 successive bursts of TR (excluding bursts containing the 3LD) shall be greater than 0.8 seconds. The
|
||
minimum value of TR observed over the 18 successive bursts shall be between 27.0 and 27.2 seconds,
|
||
and the maximum value of TR observed over the 18 successive bursts shall be between 29.8 and
|
||
30.0 seconds (ignoring bursts containing the 3LD).
|
||
Total Transmission Time
|
||
The total transmission time, measured at the 90 percent power points, shall be 440 ms ±1 percent
|
||
for the short message and 520 ms ±1 percent for the long message.
|
||
Unmodulated Carrier
|
||
The initial 160 ms ±1 percent of the transmitted signal shall consist of an unmodulated carrier at
|
||
the transmitter frequency measured between the 90 percent power point and the beginning of the
|
||
modulation.
|
||
|
||
|
||
|
||
|
||
|
||
2-3
|
||
|
||
Note - The times in seconds under the axis of each set of bursts are for reference only and do not necessarily indicate where bursts will occur as timing
|
||
tolerances will vary this.
|
||
Figure 2.1: Burst Transmission Scheme for ELT(DT)s transmitting the 3LD aircraft operator designator in PDF-2
|
||
|
||
|
||
|
||
2-4
|
||
|
||
Digital Message
|
||
a) Short Message
|
||
The final 280 ms ±1 percent of the transmitted signal shall contain a 112-bit message
|
||
at a bit rate of 400 bps ±1 percent;
|
||
b) Long Message
|
||
The final 360 ms ±1 percent of the transmitted signal shall contain a 144-bit message
|
||
at a bit rate of 400 bps ±1 percent.
|
||
For ELT(DT)s, and RLS location protocol beacons, the final 360 ms ±1 percent of
|
||
the transmitted signal shall contain a 144-bit message at a bit rate of 400 bps
|
||
±0.1 percent.
|
||
c) Cancellation Message (ELT(DT) only)
|
||
ELT(DT)s shall also have means of deactivation by the same means of activation
|
||
which shall be followed by a cancellation message sequence, as defined in section
|
||
3.4.
|
||
2.2.4.1
|
||
Bit Synchronization
|
||
A bit-synchronization pattern consisting of "1"s shall occupy the first 15-bit positions.
|
||
2.2.4.2
|
||
Frame Synchronization
|
||
A frame synchronization pattern consisting of 9 bits shall occupy bit positions 16 through 24. The
|
||
frame synchronization pattern in normal operation shall be 000101111. However, if the beacon
|
||
radiates a modulated signal in the self-test mode, the frame synchronization pattern shall be
|
||
011010000 (i.e. the last 8 bits are complemented).
|
||
2.2.4.3
|
||
Format Flag
|
||
Bit 25 is a format (F) flag bit used to indicate the length of the message to follow. Value "0"
|
||
indicates a short message; value "1" indicates a long message.
|
||
2.2.4.4
|
||
Message Content
|
||
The content of the remaining 87 bits (short message - see Figure 2.2) or 119 bits
|
||
(long message - see Figure 2.3) is defined in section 3.
|
||
Figure 2.2: Short Message Format
|
||
87 BITS (SEE SECTION 3)
|
||
160 ms
|
||
CARRIER
|
||
|
||
BITS
|
||
|
||
BITS
|
||
(2)
|
||
(1)
|
||
NOTE:
|
||
(3)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
2-5
|
||
|
||
Figure 2.3: Long Message Format
|
||
Notes:
|
||
(1) Bit Synchronization : 15 "1" bits
|
||
(2) Frame Synchronization : 000101111 (except as in section 4.5.4)
|
||
(3) "0" bit indicates short-message format
|
||
"1" bit indicates long-message format
|
||
2.3
|
||
Modulator and 406 MHz Transmitter
|
||
Transmitted Frequency\*
|
||
To ensure adequate System capacity and an efficient use of the available frequency spectrum in
|
||
the band 406.0 - 406.1 MHz allocated by the ITU for the operation of low-power satellite
|
||
emergency position-indicating radiobeacons, a number of channels have been defined in the
|
||
allocated band and will be assigned by Cospas-Sarsat from time to time, as necessary to satisfy
|
||
capacity requirements.
|
||
The frequency channels in the band 406.0 - 406.1 MHz are defined by the centre frequency of the
|
||
channels, as assigned by Cospas-Sarsat.
|
||
Except as provided below for beacons type approved by Cospas-Sarsat for operation at 406.025 MHz
|
||
and 406.028 MHz, the beacon carrier frequency shall be set in accordance with the Cospas-Sarsat
|
||
406 MHz Channel Assignment Table, as provided in document C/S T.012 “Cospas-Sarsat 406 MHz
|
||
Frequency Management Plan”, at the designated centre frequency of the appropriate channel ±1 kHz,
|
||
and shall not vary more than ± 5 kHz from that channel centre frequency in 5 years.
|
||
The carrier frequency of beacons operating in the 406.025 MHz channel in accordance with the
|
||
Cospas-Sarsat 406 MHz Channel Assignment Table shall be set at 406.025 MHz ±2 kHz. The carrier
|
||
frequency shall not vary more than ± 5 kHz from 406.025 MHz in 5 years.
|
||
The carrier frequency of beacons operating in the 406.028 MHz channel in accordance with the
|
||
Cospas-Sarsat 406 MHz Channel Assignment Table shall be set at 406.028 ± 1 kHz. The carrier
|
||
frequency shall not vary more than +2 kHz /-5 kHz from 406.028 MHz in 5 years.
|
||
* This section of the beacon specification does not apply to Cospas-Sarsat System beacons (i.e., orbitography or
|
||
calibration beacons). The transmitted frequency requirements for orbitography beacons are detailed in document
|
||
C/S T.006.
|
||
119 BITS (SEE SECTION 3)
|
||
160 ms
|
||
CARRIER
|
||
|
||
BITS
|
||
|
||
BITS
|
||
(2)
|
||
(1)
|
||
NOTE:
|
||
(3)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
2-6
|
||
|
||
The transmitted frequency short-term variations shall not exceed 2 parts in 109 in 100 ms.
|
||
The transmitted frequency medium-term stability shall be defined by the mean slope of the frequency
|
||
versus time over a 15-minute period and by the residual frequency variation about the mean slope. The
|
||
mean slope shall not exceed 1 part in 109 per minute, except as noted below. The residual frequency
|
||
variation shall not exceed 3 parts in 109.
|
||
After allowing 15-minutes for beacon warm-up, the medium-term frequency stability requirements
|
||
shall be met for all defined environmental conditions, except for the temperature gradient and the
|
||
thermal shock as defined in sections 4.2.2 and 4.2.3 respectively.
|
||
The mean slope of the medium-term frequency stability measurements shall not exceed 2 parts in
|
||
109 per minute, and the residual frequency variation shall not exceed 3 parts in 109:
|
||
• during the variable temperature conditions of the temperature gradient (+/- 5 C/h slope)
|
||
defined in section 4.2.2 and for the 15 minute periods immediately after the temperature had
|
||
stabilised at the maximum or minimum values; and
|
||
• during the thermal shock defined in section 4.2.3.
|
||
It is recommended that distress transmissions commence as soon as possible after activation, but in
|
||
accordance with section 4.5.6.
|
||
The mean slope and the residual frequency variation shall be measured as follows: Data shall be
|
||
obtained by making 18 sequential frequency measurements, one every repetition period
|
||
(50 sec ±5 percent, see section 2.2.1) over an approximate 15-minute interval; each measurement shall
|
||
be a 100-ms frequency average performed during the modulated part of the message.
|
||
The mean slope is defined as that of the least-squares straight-line fit to the 18 data points. Residual
|
||
frequency variation is defined as the root mean square (RMS) error of the points relative to the
|
||
least-squares estimate.
|
||
For ELT(DT)s, the requirement of medium-term stability (mean slope and residual frequency
|
||
variation) does not apply.
|
||
Transmitter Power Output
|
||
For all beacon types other than ELT(DT), the transmitter power output shall be within the limits
|
||
of 35 to 39 dBm measured into a 50-Ohm load. This power output shall be maintained during the
|
||
minimum operating lifetime of 24 hours (or for a longer period, as specified by National
|
||
Administrations, or by International Organisations, or as declared by the beacon manufacturer, if it
|
||
is different from 24 hours), at any temperature throughout the specified operating temperature
|
||
range. Power output rise time shall be less than 5 ms measured between the 10% and 90% power
|
||
points. The power output is assumed to rise linearly from zero and therefore must be zero prior to
|
||
about 0.6 ms before the beginning of the rise time measurement; if it is not zero, the maximum
|
||
acceptable level is -10 dBm.
|
||
For ELT(DT)s, the transmitter power output shall be within the limits of 36 dBm to 39 dBm measured
|
||
into a 50-Ohm load. This power output shall be maintained during the minimum operating lifetime of
|
||
370-minutes (or for a longer period, as specified by National Administrations or by International
|
||
|
||
|
||
|
||
2-7
|
||
|
||
Organizations, or as declared by the beacon manufacturer, if it is different from 370 minutes), or for
|
||
an ELT(DT) specifically designed to withstand a crash, or an ELT(DT) combined with an Automatic
|
||
ELT for the Duration of Continuous Operation as defined in either 4.5.10.5 or 4.5.11.7 as applicable,
|
||
at any temperature throughout the specified operating temperature range. Power output rise time shall
|
||
be less than 2 ms measured between the 10% and 90% power points. The power output is assumed to
|
||
rise linearly from zero and therefore must be zero prior to about 0.6 ms before the beginning of the rise
|
||
time measurement; if it is not zero, the maximum acceptable level is -10 dBm.
|
||
Antenna Characteristics
|
||
The following antenna characteristics are defined for all azimuth angles and for elevation angles
|
||
greater than 5° and less than 60°:
|
||
- Pattern : hemispherical
|
||
- Polarization : circular (RHCP) or linear
|
||
- Gain : between:
|
||
-3 dBi and 4 dBi over 90% of the above region
|
||
-2 dBi and 6 dBi over 90% of the above region for ELT(DT)s
|
||
- Antenna VSWR : not greater than 1.5:1
|
||
The antenna characteristics should be measured in a configuration as close as possible to its operational
|
||
condition.
|
||
Spurious Emissions
|
||
The in-band spurious emissions shall not exceed the levels specified by the signal mask in
|
||
Figure 2.4, when measured in a 100 Hz resolution bandwidth.
|
||
Figure 2.4: Spurious Emission Mask for 406.0 to 406.1 MHz Band
|
||
Pc
|
||
(POWER OUTPUT OF
|
||
UNMODULATED CARRIER)
|
||
0 dBc
|
||
|
||
dBc
|
||
|
||
dBc
|
||
|
||
dBc
|
||
|
||
dBc
|
||
- 35 dBc
|
||
- 35 dBc
|
||
|
||
dBc
|
||
|
||
dBc
|
||
|
||
kHz
|
||
|
||
kHz
|
||
|
||
kHz
|
||
|
||
kHz
|
||
fc
|
||
|
||
kHz
|
||
|
||
kHz
|
||
24 kHz
|
||
- 24 kHz
|
||
406.1 MHz
|
||
406.0 MHz
|
||
FREQUENCY (fc = BEACON CARRIER FREQUENCY)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
2-8
|
||
|
||
Data Encoding
|
||
The data shall be encoded biphase L, as shown in Figure 2.5.
|
||
Figure 2.5: Data Encoding and Modulation Sense
|
||
Modulation
|
||
The carrier shall be phase modulated positive and negative 1.1 ± 0.1 radians peak, referenced to an
|
||
unmodulated carrier. Positive phase shift refers to a phase advance relative to nominal phase.
|
||
Modulation sense shall be as shown in Figure 2.5.
|
||
The rise (R) and fall (F) times of the modulated waveform, as shown in Figure 2.6, shall be
|
||
150 ± 100 s.
|
||
For ELT(DT)s, the rise (R) and fall (F) times of the modulated waveform, shall be between 50 µs
|
||
and 150 µs.
|
||
Modulation symmetry (see Figure 2.7) shall be such that:
|
||
|
||
.0
|
||
|
||
|
||
|
||
+
|
||
−
|
||
|
||
|
||
|
||
|
||
Voltage Standing-Wave Ratio
|
||
The modulator and 406 MHz transmitter shall be able to meet all requirements, except for those in
|
||
paragraph 2.3.2 (transmitter power output), at any VSWR between 1:1 and 3:1, and shall not be
|
||
damaged by any load from open circuit to short circuit.
|
||
Maximum Continuous Transmission
|
||
The distress beacon shall be designed to limit any inadvertent continuous 406 MHz transmission
|
||
to a maximum of 45 seconds.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
2-9
|
||
|
||
Modulated Signal
|
||
Time
|
||
Figure 2.6\*: Definition of Modulation Rise and Fall Times
|
||
Time
|
||
Modulated Signal
|
||
Figure 2.7†: Definition of Modulation Symmetry
|
||
- END OF SECTION 2 -
|
||
* Figure not to scale.
|
||
† Figure not to scale.
|
||
|
||
3-1
|
||
|
||
3.
|
||
DIGITAL MESSAGE CONTENT
|
||
3.2
|
||
Basic Structure
|
||
The digital message which is transmitted by the 406 MHz beacon consists of:
|
||
112 bits for the short message; and
|
||
144 bits for the long message.
|
||
These bits are divided into five groups:
|
||
The first 24 bits transmitted, positions 1 through 24, are system bits; they are defined in section 2
|
||
and are used for bit and frame synchronization.
|
||
(1) The following 61 bits, positions 25 through 85, are data bits. This bit group is referred to
|
||
as the first protected data field (PDF-1). The first data bit (position 25) indicates if the
|
||
message is short or long: "0" = short message, "1" = long message.
|
||
(2) The following 21 bits, positions 86 through 106, are a Bose-Chaudhuri-Hocquenghem or
|
||
BCH (82,61) error-correcting code. This bit group is referred to as the first BCH
|
||
error-correcting field (BCH-1). This code is a shortened form of a BCH (127,106) triple
|
||
error-correcting code, as described in Annex B. This code can detect and correct up to
|
||
three bit errors in the 82 bits of (PDF-1 + BCH-1). The combination of PDF-1 and BCH-1
|
||
is referred to as the first protected field.
|
||
(3) The following group consists of data bits, the number and definition of these bits depends
|
||
on the message format, as follows:
|
||
Short message:
|
||
the last 6 bits of the message in positions 107 through 112,
|
||
these data bits are not protected. This bit group is referred to as the non-protected
|
||
data field;
|
||
Long message:
|
||
the following 26 bits of the message in positions 107 through
|
||
132. This bit group is referred to as the second protected data field (PDF-2).
|
||
(4) The last 12 bits of the long message, positions 133 through 144, are a Bose-Chaudhuri-
|
||
Hocquenghem or BCH (38,26) error-correcting code. This bit group is referred to as the
|
||
second BCH error-correcting field (BCH-2). This code is a shortened form of a BCH
|
||
(63,51) double error-correcting code, as described in Annex B. This code can detect and
|
||
correct up to 2 bit errors in the 38 bits of (PDF-2 + BCH-2). The combination of PDF-2
|
||
and BCH-2 is referred to as the second protected field.
|
||
|
||
|
||
|
||
|
||
|
||
3-2
|
||
|
||
3.3
|
||
Beacon Coding
|
||
Beacon coding methods are defined in Annex A to this specification. Specific operational
|
||
requirements for beacon coding, such as the self-test mode and the encoding of position data, are
|
||
defined in section 4 of this specification.
|
||
Beacon message protocols that support encoded location information (e.g., User-Location,
|
||
Standard Location and National Location) shall only be used in beacons that are designed to accept
|
||
encoded location information from a navigation system.
|
||
The 15 hexadecimal characters that uniquely identify each 406 MHz beacon are called the beacon
|
||
identification or beacon 15 Hex ID. This beacon identification comprises bits 26 to 85 of PDF-1.
|
||
For location protocols, the position data bits in PDF-1 are set to the default values specified in
|
||
Annex A.
|
||
For purposes of non-operational testing (e.g., type-approval testing), beacons shall support
|
||
message encoding with test variants for each of the declared message protocols intended for use
|
||
in that beacon, defined in sections A1.3 and A2.6 (for user protocols), A3.3.3 (for test location
|
||
protocols (not including RLS and ELT(DT))), A3.3.7.1 and A3.3.7.3 (for RLS location protocol)
|
||
and A3.3.8.1 and A3.3.8.4 (for ELT(DT) location protocol).
|
||
3.4
|
||
Cancellation Message (ELT(DT) only)
|
||
When the ELT(DT) is deactivated the ELT(DT) shall transmit the first cancellation messages
|
||
within 5 seconds, and transmit a total of 10 identical cancellation messages at intervals of
|
||
10 seconds ±0.5 seconds, after which time the beacon shall cease transmitting. In the case the
|
||
ELT(DT) is activated (e.g., triggered) during the cancellation sequence, the beacon shall terminate
|
||
the cancellation transmission sequence and reinitiate the alert sequence per section 2.2.1.
|
||
The content of the Cancellation Message is documented in Annex A, section A3.3.8 and table A11.
|
||
- END OF SECTION 3 -
|
||
|
||
4-1
|
||
|
||
4.
|
||
ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS
|
||
4.1
|
||
General
|
||
As explained in section 1.2, the environmental and operational requirements defined in this section are
|
||
not intended to be exhaustive. They are minimum requirements, which may be complemented by
|
||
national or international standards.
|
||
4.2
|
||
Thermal Environment
|
||
Operating Temperature Range
|
||
Three standard classes of operating temperature range are defined, inside which the system
|
||
requirements of section 2 shall be met:
|
||
Class 0:
|
||
-55°C to +70°C
|
||
Class 1:
|
||
-40°C to +55°C
|
||
Class 2:
|
||
-20°C to +55°C
|
||
Temperature Gradient
|
||
All system requirements of section 2, including the frequency requirements defined in section 2.3.1,
|
||
shall be met when the fully packaged beacon is subjected to the temperature gradient shown in Figure
|
||
4.1.
|
||
Thermal Shock
|
||
All system requirements of section 2 shall be met, including the mean slope of the medium-term
|
||
frequency stability measurements which shall not exceed 2.0 parts in 109 per minute, for measurements
|
||
beginning 15 minutes after simultaneously activating the beacon and applying a thermal shock of 30°C
|
||
within the specified operating temperature range of the beacon. Subsequently, system requirements
|
||
shall continue to be met for a minimum period of two (2) hours.
|
||
For ELT(DT)s all system requirements of section 2 shall be met, excluding the medium-term frequency
|
||
stability requirements, for measurements beginning with the first transmission after simultaneously
|
||
activating the beacon and applying a thermal shock of 50°C within the specified operating temperature
|
||
range of the beacon. Subsequently, system requirements shall continue to be met for a minimum period
|
||
of two (2) hours.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-2
|
||
|
||
NOTES:
|
||
Tmax = + 70°C (Class 0 beacon)
|
||
Tmax = + 55°C (Class 1 & 2 beacons)
|
||
Tmin = - 55°C (Class 0 beacon)
|
||
Tmin = - 40°C (Class 1 beacon)
|
||
Tmin = - 20°C (Class 2 beacon)
|
||
tstart
|
||
= test start time
|
||
tstop
|
||
= test stop time
|
||
ton
|
||
= beacon turn-on time after 2 hour “cold soak”
|
||
tmeas = start time of frequency stability measurement (ton + 15 min,
|
||
except for ELT(DT)s where tmeas = ton)
|
||
A\*
|
||
= 7°C/hour for Class 0 (45oC/hour for ELT(DT))
|
||
A\*
|
||
= 5°C/hour for Class 1 and Class 2 (33oC/hour for ELT(DT))
|
||
α
|
||
= For ELT(DT)s the time between points C and D is reduced
|
||
on the down-ramp test to one (1) hour.
|
||
SLOPE = +A* °C/h
|
||
SLOPE = -A* °C/h
|
||
TIME
|
||
tmeas
|
||
2h
|
||
2h
|
||
1h
|
||
2hα
|
||
TEMPERATURE (°C)
|
||
ton
|
||
Twarm-up = 15 min
|
||
Tmin
|
||
tstart
|
||
tstop
|
||
C
|
||
D
|
||
Figure 4.1: Temperature Gradient
|
||
4.3
|
||
Mechanical Environment
|
||
Beacons shall be submitted to vibration and shock tests consistent with their intended use.
|
||
|
||
4-3
|
||
|
||
Internationally-recognized standards such as RTCA/DO-183* for ELTs could be used by the
|
||
national authorities.
|
||
4.4
|
||
Other Environmental Requirements
|
||
Other environmental requirements such as humidity tests, altitude tests, over/under pressure tests,
|
||
waterproofness tests, sand and dust tests, fluids susceptibility tests, etc., may be defined by national
|
||
authorities, preferably using internationally-recognized standards.
|
||
4.5
|
||
Operational Requirements
|
||
Duration of Continuous Operation
|
||
The minimum duration of continuous operation shall be at least 24 hours† at any temperature
|
||
throughout the specified operating temperature range.
|
||
The minimum duration of continuous operation for an ELT(DT) to meet the ICAO GADSS
|
||
requirement at any temperature throughout the specified operating temperature range shall be
|
||
370 minutes‡. At the end of the 370-minute period, the ELT(DT) shall continue transmitting on the
|
||
same schedule as before the 370-minute limit was reached until the ELT(DT) is either deactivated, or
|
||
runs out of battery life. Minimum duration of continuous operation requirements for Crash Survivable
|
||
ELT(DT)s can be found in section 4.5.10.5 and for Combined ELT(DT)s in section 4.5.11.5.
|
||
Other Operational Requirements
|
||
Other operational requirements such as installation and maintenance methods, remote monitoring,
|
||
activation methods on planes or boats, etc. may be defined by national authorities.
|
||
Auxiliary Radio-Locating Device
|
||
The transmission of the 406 MHz satellite signal shall take precedence over any Radio-Locating
|
||
Signals. Homing signal types should be momentarily interrupted, delayed, rescheduled, or
|
||
eliminated according to the relevant standard for each type, in order to ensure that homing signals
|
||
are not transmitted at the same time as the 406-MHz signal to satellites.
|
||
* Document RTCA/DO-183 was obsolete in 1989, and later was replaced with document RTCA/DO-204B, subject to
|
||
future changes.
|
||
† For installations meeting IMO GMDSS requirements, a minimum operating lifetime of 48 hours at any temperature
|
||
throughout the specified operating temperature range is necessary.
|
||
‡ This duration is based on ICAO standards for Extended Diversion Time operations (EDTO) and the maximum
|
||
diversion time capability of existing aircraft types, as of April 2018.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-4
|
||
|
||
The distress beacon may transmit radio-locating signals in compliance with appropriate national
|
||
or international standards. The inclusion of any Radio-Locating Signals within a beacon and the
|
||
prioritization of these Radio-Locating Signals is the responsibility of the appropriate national or
|
||
international bodies.
|
||
Any such radio-locating device must satisfy all the national performance standards applicable to
|
||
radio-locating devices at the selected frequency.
|
||
Beacon Self-Test Mode
|
||
All beacons shall include a self-test mode of operation.
|
||
In the self-test mode beacons shall transmit a 406 MHz signal with digital message encoded in
|
||
accordance with Annex A to this specification and 121.5 MHz signal (if applicable). The content
|
||
of the self-test message shall always provide the beacon 15 Hex ID, except for location protocol
|
||
beacons when transmitting a GNSS self-test message encoded with location data.
|
||
The self-test mode (or GNSS self-test mode) shall not be used for the purposes of repetitive
|
||
automated interrogation of the beacon status. A beacon (e.g., ELT(DT)) may contain a different
|
||
test mode that can be used for repetitive automated interrogation of its status, but operation of the
|
||
beacon in this different test mode shall not result in the transmission of a 406 MHz signal or other
|
||
radio locating signals (if applicable), nor interfere with the normal operation of the beacon.
|
||
In the self-test mode the digital message must have a frame synchronization pattern of 011010000.
|
||
This bit pattern complements the last 8 bits of the normal frame synchronization pattern so that
|
||
this test burst will not be processed by the satellite equipment.
|
||
The complete self-test transmission must be limited to one burst only regardless of the duration of
|
||
activation of the self-test control. The maximum duration of the self-test mode transmission should
|
||
be 440 ms (±1%) for a short message and 520 ms (±1%) for a long message. Except for ELT(DT)s,
|
||
which shall transmit long self-test message, other types of beacons coded with a Location Protocol
|
||
may transmit either a long self-test message or a short self-test message. If a 440 ms (short self-
|
||
test message) transmission is used for beacons encoded with Location Protocol long format
|
||
messages, the message shall be truncated (stop at bit 112) without changing the long message
|
||
format flag bit 25 from a 1.
|
||
ELT(DT)s coded with a 3LD in PDF-2 shall transmit a long self-test message with the rotating
|
||
field and the encoded 3LD in PDF-2 (if the ELT(DT) is capable of transmitting a 3LD in PDF-2,
|
||
but has not been coded with a 3LD, then the default 3LD shall be used).
|
||
The self-test mode shall be activated by a separate switch position.
|
||
The self-test function shall perform an internal check and provide distinct indication (which shall
|
||
occur during the declared timeframe for the self-test mode) that:
|
||
the self-test mode has been initiated;
|
||
RF power is being emitted at 406 MHz and at 121.5 MHz, if applicable;
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-5
|
||
|
||
the internal check has passed successfully, or has failed;
|
||
the beacon battery may not have sufficient energy to support beacon operation for
|
||
the manufacturer-declared minimum operating lifetime\*† ; and
|
||
for RLS-capable beacons, when coded with the RLS Location protocol (i.e., the
|
||
RLS functionality is enabled), the beacon shall:
|
||
i)
|
||
provide an indication that RLS functionality is enabled, and
|
||
ii)
|
||
activate the RLS and RLM indicator(s) to confirm to the user that
|
||
the indicator(s) are functional.
|
||
The beacon shall be designed to ensure an automatic termination of the self-test mode immediately
|
||
after completion of the self-test cycle and indication of the self-test results. Regardless of the self-
|
||
test switch position, this shall not prevent the beacon from being activated automatically or
|
||
manually, as applicable, once the self-test mode has terminated.
|
||
For location protocol beacons the content of the encoded position data field of the self-test message
|
||
shall be the default values specified in Annex A. Additionally, location protocol beacons may
|
||
optionally provide for the transmission of a GNSS self-test message encoded with location data.
|
||
ELT(DT) beacons shall include a GNSS self-test mode resulting in a single burst transmission. All
|
||
ELT(DT)s, including those capable of transmitting a 3LD in PDF-2, shall transmit a long GNSS
|
||
self-test message with location data encoded in PDF-1 and PDF-2 (bits 113 and 114 shall indicate
|
||
the location freshness).
|
||
Location protocol beacons which provide for the transmission of an encoded position in a GNSS
|
||
self-test message shall:
|
||
activate the GNSS self-test mode via a distinct operation from the normal self-test
|
||
mode, but the GNSS self-test mode may be activated via the same self-test
|
||
switch(es) or operation provided that it shall require a separate, deliberate action
|
||
by the user that would limit the likelihood of inadvertent activation, and shall not
|
||
result in more than a single self-test burst regardless of the duration of activation
|
||
of the GNSS self-test control;
|
||
provide for that in the case of internal GNSS receivers powered by the primary‡
|
||
beacon battery the number of GNSS self-tests shall be limited by the beacon design
|
||
to prevent inadvertent battery depletion;
|
||
* By decision of the Cospas-Sarsat Council at its Fifty-seventh Session, this requirement will only be mandatory for
|
||
new beacon models submitted for type approval testing after 1 January 2018, as a target, subject to further review and
|
||
consideration.
|
||
† Self-test indication of insufficient battery energy shall commence prior to the point, at which the residual battery
|
||
energy is less than the energy required to support the declared minimum operating lifetime, as declared by the beacon
|
||
manufacturer.
|
||
‡ The primary battery is the battery which is powering the 406 MHz function.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-6
|
||
|
||
provide a distinct indication to register successful completion or failure of the
|
||
GNSS self-test;
|
||
provide, for beacons with internal navigation devices:
|
||
- a separate distinct indication that the limited number of GNSS self-test
|
||
attempts has been attained, which shall be immediately indicated to the
|
||
user once the GNSS Self-test has been initiated,
|
||
- a means to prevent any RF-transmissions or further GNSS receiver
|
||
power drain, if further GNSS self-test activations are attempted, once
|
||
the GNSS Self-test limit has been reached;
|
||
ensure that the duration of the GNSS self-test is limited to a maximum time
|
||
duration set by the manufacturer, noting that:
|
||
- in the case where the beacon fails to encode the location into the
|
||
406 MHz message within this time limit the GNSS self-test shall cease,
|
||
the beacon shall indicate a GNSS self-test failure and may transmit a
|
||
single self-test burst with default location data in both PDF-1 and
|
||
PDF-2,
|
||
- in the case where the beacon encodes the location into the 406 MHz
|
||
message within this time limit the GNSS self-test shall cease at that time
|
||
(before the time limit is reached), indicate a GNSS self-test pass and
|
||
may transmit a single self-test burst containing the valid location data in
|
||
both PDF-1 and PDF-2;
|
||
provide an automatic termination of GNSS self-test mode, irrespective of the
|
||
switch position, immediately after completion of the GNSS self-test cycle and
|
||
indication of the test results;
|
||
for beacons that provide a GNSS self-test using both the internal navigation device
|
||
and the external navigation interface:
|
||
- when the GNSS Self-test is initiated, the beacon shall attempt to obtain
|
||
location data from the internal navigation device, if this data is available,
|
||
- if location data is not available from the internal navigation device, then
|
||
the beacon shall obtain the location data from the external navigation
|
||
interface,
|
||
- if the location data from the external navigation interface is not
|
||
available, the beacon shall wait to obtain location data from the internal
|
||
navigation device for the maximum duration of the GNSS self-test, as
|
||
declared by the beacon manufacturer; and
|
||
include instructions for the GNSS self-test in the Beacon Instruction Manual which
|
||
shall include a clear warning on the use and limitations of this function, noting that
|
||
instructions for the GNSS self-test shall not be included on the beacon itself.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-7
|
||
|
||
Encoded Position Data\*
|
||
4.5.5.1 General
|
||
Beacon position data, obtained from a navigation device internal, integral† or external to the
|
||
beacon, may be encoded in the beacon message. Position data can be encoded in either the PDF-2
|
||
part of the message, or in both PDF-1 and PDF-2 parts of the message.
|
||
The two levels of position resolution that can be encoded in the beacon message include:
|
||
• position data with resolution of 4 seconds in PDF-2, given as an offset of the
|
||
position data provided in PDF-1 with a resolution of 30 minutes, 15 minutes or
|
||
2 minutes; and
|
||
• position data with resolution of 4 minutes in PDF-2, together with any of the user
|
||
protocol identification methods used in PDF-1.
|
||
Operation or failure of an internal or external navigation device providing position data to the
|
||
beacon shall not degrade beacon performance.
|
||
ELT(DT)s shall comply with the requirements of section 4.5.5.6 instead of sections 4.5.5.2 to
|
||
4.5.5.5.
|
||
4.5.5.2
|
||
Message Content and Timing
|
||
Position data shall be encoded into the beacon message according to one of the methods specified
|
||
in Annex A. The identification data and encoded position data are protected by a BCH error-
|
||
correcting code. A 21-bit BCH code (BCH-1) protects the data of the first protected data field
|
||
(PDF-1) and a 12-bit BCH code (BCH-2) protects the data of the second protected data field
|
||
(PDF-2). The BCH codes shall always correspond to the message content. The beacon shall
|
||
recompute these codes each time the message content is changed.
|
||
The beacon shall commence transmissions upon activation even if no valid position data are
|
||
available. Until valid position data is available, the content of the encoded position data field of
|
||
the message shall be the default values specified in Annex A. The first input of position data into
|
||
the beacon message shall occur as soon as valid position data becomes available. All beacons with
|
||
internal navigation devices shall provide position data updates, in accordance with section 4.5.5.4.
|
||
If, after providing valid data, the navigation input fails or is not available, the beacon message shall
|
||
retain the last valid position for 4 hours ± 5 minutes after the last valid position data input. After
|
||
4 hours ± 5 minutes the encoded position shall be set to the default values specified in Annex A.
|
||
* ELTs carried to satisfy the requirements of ICAO Annex 6, Parts I, II and III shall operate in accordance with ICAO
|
||
Annex 10.
|
||
† An integral navigation device is a part of the beacon system but may be separate to the beacon transmitter and shall
|
||
comply with the performance requirements of an internal navigation device.
|
||
|
||
|
||
|
||
4-8
|
||
|
||
When the beacon radiates a 406 MHz signal in the self-test mode, the content of the encoded
|
||
position of the self-test message shall be set to the default values specified in Annex A, except for
|
||
location protocol beacons in the optional GNSS self-test mode, when the beacon transmits a single
|
||
self-test message with encoded position.
|
||
4.5.5.3 Internal Navigation Device Performance
|
||
An internal navigation device shall be capable of global operation and shall conform to an
|
||
applicable international standard. An internal navigation device shall incorporate self-check
|
||
features to ensure that erroneous position data is not encoded into the beacon message. The self-
|
||
check features shall prevent position data from being encoded into the beacon message unless
|
||
minimum performance criteria are met. These criteria could include the proper internal
|
||
functioning of the device, the presence of a sufficient number of navigation signals, sufficient
|
||
quality of the signals, and sufficiently low geometric dilution of precision.
|
||
The distance between the position transmitted in the beacon message and the known* beacon
|
||
position at the time of the position update shall not exceed:
|
||
- 500 m for beacons transmitting messages encoded with the Standard, National, or
|
||
RLS Location protocols,
|
||
- 5.25 km for beacons transmitting messages encoded with the User-Location
|
||
protocol.
|
||
The encoded position data shall be provided in the WGS 84 or GTRF geodetic reference systems.
|
||
The internal navigation device shall provide valid data within 10 minutes after its activation.
|
||
Internal navigation device cold start shall be forced at every beacon activation. Cold start refers
|
||
to the absence of time dependent or position dependent data in memory, which might affect the
|
||
acquisition of the GNSS position.
|
||
4.5.5.3.1
|
||
ELTs with an Internal Navigation Device Powered Externally Prior to Activation
|
||
If an internal navigation device cold start is forced upon application of external power to the
|
||
internal navigation device, and does not cold start upon beacon activation, then the requirements
|
||
of this section apply.
|
||
For ELTs with externally powered internal navigation devices, which are continuously operational
|
||
prior to beacon activation, and are designed to obtain and update position data from an internal
|
||
* The known beacon position shall have a 2-D location accuracy of ± 10 meters or better, which may be achieved by
|
||
placing the beacon on the earth surface in a surveyed position with known geographical coordinates, or by determining
|
||
the beacon position with a high-resolution GNSS receiver.
|
||
|
||
4-9
|
||
|
||
GNSS receiver and retain position data in the beacon memory, prior to the beacon activation, the
|
||
internal navigation device cold start shall be forced on each initial power up of the internal
|
||
navigation device.
|
||
To facilitate the provision of position data prior to activation, the ELT shall attempt to update the
|
||
position retained in memory from the internal navigation device at intervals of no longer than 2
|
||
seconds. If, after ELT activation, current navigation data is not available, then the ELT shall
|
||
transmit its first and subsequent 406-MHz messages with the last position available prior to ELT
|
||
activation (as retained in beacon memory for this purpose) until a new position is available or 4
|
||
hours ± 5 minutes has elapsed.
|
||
The ELT shall not use external power to power the internal navigation device once activated.
|
||
After activation the beacon shall only be powered by the internal battery, apart from external
|
||
interfaces to/from the beacon approved for use with the beacon (e.g., Remote Control Panel,
|
||
ARINC interface, etc.).
|
||
4.5.5.4 Internal Navigation Device Timing\*
|
||
The internal navigation device within the beacon shall be activated immediately after the beacon
|
||
is turned on. Once the navigation device acquires a fix, it shall continue to attempt to acquire
|
||
locations for a further period of at least 10 seconds and encode the location with the lowest HDOP
|
||
obtained during this period into the next available beacon message. Between each attempt to obtain
|
||
a ‘fix’ the navigation device may be put into a sleep mode that may retain ephemeris and/or
|
||
almanac data, such that when it is subsequently woken up it warm starts. Subsequent valid updated
|
||
location ‘fixes’ shall be encoded into the next available beacon message. The navigation device
|
||
search/sleep timing should be determined by the beacon manufacturer to optimize location
|
||
performance whilst conserving battery capacity, subject to the following minimum requirements:
|
||
The internal navigation device shall make an attempt to obtain an initial location for a period of at
|
||
least 10 minutes after beacon activation unless a location is obtained sooner than this. After this initial
|
||
attempt to obtain a location, the internal navigation device shall make subsequent attempts to obtain
|
||
an initial location, or an updated location, as applicable, at intervals of no more than 15 minutes and
|
||
no less than every 4 minutes and 25 seconds, measured from the end of the last update attempt, for
|
||
* These requirements are mandatory for new beacon models first submitted for type approval testing after 1 December
|
||
2021, however manufacturers may voluntarily choose to comply with these requirements before this date. For beacons
|
||
first submitted for type approval testing prior to this date, the version of C/S T.001 in force at the time of submission
|
||
shall apply. Type approved beacons subject to change notices do not have to comply with these latest internal
|
||
navigation device timing requirements and may continue to comply with the version of C/S T.001 that was in force at
|
||
the time of the original type approval, unless the manufacturer decides to update the beacon navigation system, in
|
||
which case the applicability of the these requirements will be as of 1 December 2022.
|
||
|
||
4-10
|
||
|
||
the remainder of the manufacturer declared minimum operating lifetime of the beacon\*†. Whenever an
|
||
initial location or an updated location is obtained, it shall be encoded into the next available beacon
|
||
message to be transmitted. If an updated location is not obtained prior to the transmission of the next
|
||
beacon message then the previous location (or if there was no previous location, default position
|
||
values) shall be transmitted until either a location becomes available or 4 hours ± 5 minutes have
|
||
elapsed (after which time the encoded position shall be set to the default values).
|
||
Attempts at obtaining an initial location or location update shall require the navigation device to
|
||
be powered up for a period of at least 90 seconds each time, unless a location is obtained sooner
|
||
than this, in which case the navigation device may then be put into a sleep mode 10 seconds later
|
||
(noting that if this occurs after 80 seconds, this 10-second period can be reduced accordingly to
|
||
maintain the total 90 seconds navigation device ‘on’ time).
|
||
4.5.5.5 External Navigation Device Input
|
||
It is recommended that beacons, which are designed to accept data from an external navigation
|
||
device, be compatible with an applicable international standard, such as the IEC Standard on
|
||
Digital Interfaces (IEC Publication 61162).
|
||
Features should be provided to ensure that erroneous position data is not encoded into the beacon
|
||
message.
|
||
For a beacon designed to operate with an external navigation device, if appropriate navigation data
|
||
input is present, the beacon shall produce a digital message with the properly encoded position
|
||
data and BCH code(s) within 1 minute after its activation.
|
||
If a beacon is designed to accept position data from an external navigation device prior to beacon
|
||
activation, navigation data input should be provided at intervals not longer than:
|
||
• 20 minutes for EPIRBs and PLBs; or
|
||
• 1 minute for ELTs.
|
||
4.5.5.6 ELT(DT) Navigation Device Requirements
|
||
ELT(DT)s shall incorporate an internal navigation device and may incorporate an interface to an
|
||
external navigation device (e.g., the aircraft avionics), which produce navigation data for encoding
|
||
into the beacon message. ELT(DT) shall be encoded with the ELT(DT) Location Protocol. The
|
||
BCH codes shall always match the message content. The ELT(DT) shall recompute these codes
|
||
each time the message content is changed.
|
||
* For EPIRBs with VDR functionality, after at least 48 hours of operation, the update rate can be extended to a
|
||
maximum of once every 60 minutes for the remainder of the operating lifetime, if required.
|
||
† IMO Performance standards applicable to EPIRBs to be used on SOLAS-compatible vessels (Resolution MSC.471
|
||
(101) applicable from 1 July 2022, Annex, Part 4, section .1 requires that, when the EPIRB is activated, the GNSS
|
||
receiver position fix shall be updated at intervals of no more than five minutes.
|
||
|
||
4-11
|
||
|
||
The first ELT(DT) transmission shall occur no more than 5 seconds after the beacon activation. If,
|
||
after the ELT(DT) activation, current navigation data is not available, then the ELT(DT) shall
|
||
transmit its first and subsequent 406-MHz messages with the last position available prior to the
|
||
ELT(DT) activation (which shall be retained in beacon memory for this purpose) and with the
|
||
encoded position freshness (to an accuracy of 5 seconds). To facilitate the provision of position
|
||
data prior to activation, the ELT(DT) shall attempt to update the position retained in memory from
|
||
either the internal navigation device or the external navigation input at intervals of no longer than
|
||
2 seconds.
|
||
If no position is available prior to the ELT(DT) activation, or if 4 hours ± 5 minutes elapse since
|
||
the last valid position data input, the ELT(DT) shall transmit the default position values specified
|
||
in Annex A until such time, as navigation data becomes available either from an internal GNSS
|
||
receiver or, if applicable, from an external navigation device. If navigation data is available,
|
||
406-MHz transmissions shall contain a valid encoded position, calculated within the 2 seconds
|
||
immediately prior to a 406-MHz transmission, and the encoded position freshness.
|
||
The initial position transmitted in the first burst may be obtained from either the internal navigation
|
||
device or from the external navigation device input.* The transmission in the beacon message of
|
||
this external source of position is only subsequently allowed if the internal GNSS receiver is not
|
||
able to produce a valid encoded position less than 2 seconds before the burst. If position data is
|
||
available from both sources, within 2 seconds before any subsequent burst, then the location
|
||
produced by the internal GNSS receiver has priority over the external source of data.
|
||
Internal navigation device cold start shall be forced on each initial power up of the internal
|
||
navigation device, but shall not occur if the ELT(DT) is subsequently activated or between
|
||
ELT(DT) transmissions. Cold start refers to the absence of time dependent or position dependent
|
||
data in the beacon’s or in the GNSS receiver’s memory, which might affect the acquisition of the
|
||
GNSS position.
|
||
ELT(DT)s shall attempt to acquire fresh position information prior to every 406 MHz transmission
|
||
and shall encode the latest position obtained within less than 2 seconds (defined as current position)
|
||
prior to each burst into that transmission. For ELT(DT)s using rotating field data in PDF-2, (e.g.,
|
||
the aircraft operator 3LD), the current position is transmitted with its full resolution (using both
|
||
PDF-1 and PDF-2) according to the transmission scheme described in section 2.2.1.
|
||
If an updated position is not available within 2 seconds immediately prior to every 406 MHz
|
||
transmission, then the ELT(DT) shall transmit the latest position that it has, unless this position is
|
||
more than 4 hours old, in accordance with section 4.5.5.2, in which case it shall revert to
|
||
transmitting the default position until such time as an updated position is available.
|
||
* The internal navigation device or even the entire ELT(DT) may be powered by an external source prior to its activation
|
||
in order to comply with this requirement.
|
||
|
||
4-12
|
||
|
||
The freshness of the encoded location transmitted by the ELT(DT) shall be indicated in the
|
||
ELT(DT) message as defined in Annex A.3.3.8.
|
||
The internal navigation device shall be capable of global operation and shall conform to an
|
||
applicable international standard. The internal navigation device shall incorporate self-check
|
||
features to ensure that erroneous position data is not encoded into the beacon message. The self-
|
||
check features shall prevent position data from being encoded into the ELT(DT) message unless
|
||
minimum performance criteria are met. These criteria could include the proper internal
|
||
functioning of the device, the presence of a sufficient number of navigation signals, sufficient
|
||
quality of the signals, and sufficiently low geometric dilution of precision.
|
||
The navigation device shall provide a 3-D position which shall be encoded into the ELT(DT)
|
||
message in accordance with Annex A.3.3.8. If a 3-D position is not available, then a 2-D position
|
||
shall be provided and the altitude bits in the message shall be set to their default values.
|
||
The distance between the position provided by the internal navigation device, at the time of the
|
||
position update, and the 2D position contained in the next 406 MHz transmission from the
|
||
ELT(DT) while static shall not exceed 200 m. The distance between the altitude provided by the
|
||
internal navigation device, at the time of the position update, and the altitude contained in the next
|
||
406 MHz transmission from the ELT(DT) while static shall not exceed 700 m. The encoded
|
||
position data shall be provided in the WGS 84 or GTRF geodetic reference systems.
|
||
If the ELT(DT) incorporates an interface to an external navigation device, it is recommended that
|
||
this be compatible with an applicable international standard, such as the IEC Standard on Digital
|
||
Interfaces (IEC Publication 61162).
|
||
When the ELT(DT) radiates a 406 MHz signal in the self-test mode, the content of the encoded
|
||
position of the self-test message shall be set to the default values specified in Annex A, except
|
||
when transmitting an optional GNSS self-test, when the ELT(DT) shall radiate a single self-test
|
||
message with encoded position.
|
||
Beacon Activation
|
||
The beacon should be designed to prevent inadvertent activation.
|
||
After activation, the beacon shall not transmit a 406 MHz distress message until at least
|
||
one repetition period (as defined in section 2.2.1) has elapsed. Thereafter the beacon shall not
|
||
transmit more frequently than the minimum repetition period (as defined in section 2.2.1)
|
||
regardless of the duration of activation of any controls or the activation of any combination of
|
||
controls. Once activated and transmitting 406 MHz distress messages, the activation of any control
|
||
other than the ‘Off’ or ‘Reset’ controls shall not stop the beacon from transmitting or result in
|
||
transmission of messages with inverted frame sync (self-test bursts).
|
||
|
||
|
||
|
||
4-13
|
||
|
||
ELTs when automatically activated by G-switch / deformation shall transmit the first 406 MHz
|
||
distress message as soon as possible, which shall be within no more than 15 seconds after beacon
|
||
activation\*.
|
||
For ELT(DT)s, the transmission of 406 MHz distress messages shall start within 5 seconds after
|
||
beacon activation, as defined in section 2.2.1.
|
||
4.5.6.1 ELT(DT) Modes of Operation
|
||
ELT(DT)s shall allow for automatic and manual means of activation. All ELT(DT )s shall include
|
||
a means of receiving information from the aircraft to determine whether the ELT(DT) is on the
|
||
ground or in the air and shall take this status into account when activated. ELT(DT)s shall also
|
||
have means of deactivation by the same means of activation which shall be followed by a
|
||
cancellation message sequence.
|
||
Standalone ELT(DT)s (i.e., those that do not comply with either sections 4.5.10 or 4.5.11) should
|
||
function as follows. National Administrations or Aviation Authorities may define additional
|
||
functionality.
|
||
Activation Criteria
|
||
Activation Means
|
||
Manual
|
||
Avionics
|
||
On Ground
|
||
406 Distress
|
||
Tracking (DT)
|
||
sequence and
|
||
121.5 optional if
|
||
available
|
||
Avionics Disabled
|
||
In Air
|
||
406 DT sequence
|
||
only preferred,
|
||
121.5 optional if
|
||
available
|
||
406 DT sequence only
|
||
If the beacon is activated in one aircraft state (e.g., In Flight) and the aircraft transitions to another
|
||
state (e.g., On Ground) while the beacon is still activated, the beacon transmission characteristics
|
||
should behave as indicated for the new aircraft state as per the table above.
|
||
Consequently:
|
||
• If the ELT(DT) has been automatically activated by the triggering system†, it shall
|
||
only be de-activated by the same means.
|
||
* This requirement is mandatory to new beacon models submitted for type-approval testing at accepted test facilities
|
||
after 1 January 2018.
|
||
† For example, triggered in compliance with EUROCAE ED-237
|
||
|
||
4-14
|
||
|
||
• If the ELT(DT) has been automatically activated by the beacon\*, it shall only be
|
||
deactivated by manually resetting the beacon.
|
||
• If the beacon has been manually activated (i.e., from the cockpit), it shall only be
|
||
manually de-activated.
|
||
• If the beacon has been activated by any combination of activation means, it can
|
||
only be de-activated once each activation means has been deactivated.
|
||
• Bits 107 and 108 of the ELT(DT) Location Protocol message shall indicate the most
|
||
recent means of activation. If one means of activation is removed but others remain
|
||
then Bits 107 and 108 shall revert to indicating the previous most recent means of
|
||
activation.
|
||
Thus an ELT(DT) shall as a minimum have the following modes of operation:
|
||
OFF - The complete ELT(DT) (and any related components) is/are unpowered.
|
||
ARMED - The ELT(DT) or some parts of it may if required be powered up, such that
|
||
when it is activated automatically† or manually, it can start transmitting within 5 seconds
|
||
and meet the requirements in this specification for ELT(DT)s including the provision of
|
||
encoded location in the first burst. However, until the ELT(DT) is activated there are no
|
||
outputs from the ELT(DT) at all (e.g., no 406 MHz or Homing Signal transmissions).
|
||
ON - The ELT(DT) has been either activated automatically and/or has been manually
|
||
activated and is transmitting 406 MHz signals in full compliance with the ELT(DT)
|
||
requirements in this specification.
|
||
RESET – The ELT(DT) is deactivated and ceases transmitting distress alerts and instead
|
||
transmits a sequence of cancellation messages as defined by section 3.3. Upon
|
||
completion of the cancellation message sequence, the ELT(DT) reverts to the ARMED
|
||
condition. The ELT(DT) can only be deactivated as defined above.
|
||
RLS Beacon Requirements
|
||
Beacons with a Return Link Service (RLS) function shall support message encoding with the RLS
|
||
Location Protocol and a Location Test Protocol‡, and shall meet the following additional
|
||
requirements.
|
||
* For example, triggered by G-switch / deformation.
|
||
† For example, triggered in compliance with EUROCAE ED-237 or by G-switch / deformation.
|
||
‡ The location test protocol may be either Standard Location Test or National Location Test protocol and must be used
|
||
in addition to the RLS Location Test protocol.
|
||
|
||
|
||
|
||
4-15
|
||
|
||
4.5.7.1 GNSS Receiver
|
||
The RLS beacon shall contain an internal GNSS Receiver capable of receiving and decoding
|
||
Return Link Messages (RLMs) from a Cospas-Sarsat recognised Return Link Service Provider
|
||
(RLSP) and of providing these messages to the beacon in an IEC 61162-1 compliant sentence, or
|
||
in an equivalent proprietary sentence defined by the GNSS-receiver manufacturer.
|
||
If the GNSS receiver is capable of processing signals from only one GNSS constellation, this shall
|
||
be the associated RLS provider’s constellation, and satellites should be tracked above 5 degrees of
|
||
elevation.
|
||
If the GNSS receiver is capable of processing signals from several GNSS constellations
|
||
(multi-constellation GNSS receiver), such a receiver shall prioritize the reception from satellites
|
||
of the GNSS constellation associated with the RLS provider above 5 degrees of elevation over
|
||
other GNSS constellations.
|
||
The following Return Link Messages have been defined to date:
|
||
• Acknowledgement Type-1 RLM: An automated response that acknowledges
|
||
receipt of the RLS request,
|
||
• Test Return Link Message: An RLM dedicated for testing, including automatic
|
||
response that acknowledges receipt of the RLS request from an RLS beacon coded
|
||
with an RLS Location Test Protocol.
|
||
The definition of the RLM message content included as part of the Galileo L1 navigation message
|
||
is defined in the Galileo Open Service Public Signal in Space ICD Issue 1.3.
|
||
4.5.7.2
|
||
RLS GNSS Receiver Operation
|
||
4.5.7.2.1
|
||
Operation Cycle
|
||
In addition to the beacon’s normal GNSS receiver operating cycle as defined in section 4.5.5.4, or
|
||
as defined by the beacon manufacturer if the receiver is designed to be active more frequently than
|
||
those requirements, the RLS beacon shall:
|
||
when encoded with an RLS Location Protocol maintain the GNSS receiver in an
|
||
active mode of operation for a minimum period of 30 minutes after beacon
|
||
activation or until a valid RLM message is acquired or the beacon is deactivated,
|
||
whichever occurs first, such that it can continuously check for receipt of an RLM
|
||
message and Coordinated Universal Time (UTC), during this period;
|
||
as soon as possible determine UTC from the GNSS receiver and maintain a clock
|
||
for at least 6 hours from the time the beacon was first activated, to an accuracy of
|
||
better than three seconds (once UTC has been acquired) or until the beacon is
|
||
deactivated (if UTC is not acquired see (e) below);
|
||
|
||
|
||
|
||
|
||
|
||
4-16
|
||
|
||
if an RLM message has not been received within the first 30 minutes period, then,
|
||
at the end of this time, utilise UTC time to next activate the GNSS receiver* at the
|
||
next occurrence of UTC Moffset† minutes (where 0 ≤ Moffset ≤ 59), to check for
|
||
receipt of an RLM, for a minimum period of 15 minutes, or until an RLM message
|
||
is acquired (e.g. if the first 30 minute period ended at 02:29 and Moffset is
|
||
15 minutes, then next activate the GNSS receiver at 03:15, or if Moffset is
|
||
44 minutes, then next activate the GNSS receiver at 02:44);
|
||
then during each subsequent hour reactivate* the GNSS receiver (in accordance
|
||
with section 4.5.5.4 and this section 4.5.7.2) to check for receipt of an RLM for a
|
||
minimum period of 15 minutes at Moffset minutes, with 0 ≤ Moffset ≤ 59, past the
|
||
hour until either an RLM message is received or 6 hours has elapsed since the
|
||
beacon was activated or the beacon is deactivated;
|
||
if UTC cannot be determined within 30 minutes after beacon activation the beacon
|
||
shall attempt to obtain UTC using the timings detailed in section 4.5.5.4. If UTC
|
||
is then determined the beacon shall continue as per c) and d) above from the next
|
||
occurrence of UTC Moffset minutes; and
|
||
once an RLM message is received, or after 6 hours has elapsed since beacon
|
||
activation, whichever is sooner, the beacon shall revert to the GNSS timings in
|
||
section 4.5.5.4.
|
||
For instance, if the beacon is activated at 03.17h UTC, then the GNSS receiver would remain active
|
||
until at least 03.47h UTC, or until an RLM message is acquired if sooner, or the beacon is deactivated,
|
||
if it is deactivated before that time. If an RLM message is acquired within this period, then the beacon
|
||
reverts to the GNSS timings in section 4.5.5.4. If an RLM message is not acquired, then it would re-
|
||
activate at the next occurrence of Moffset past the hour and remain active until at least Moffset+15, or
|
||
until an RLM message is acquired, or the beacon is deactivated and it would then reactivate again
|
||
during the next hour at Moffset until Moffset+15, etc. The scheme continues as above until an RLM
|
||
message is acquired, or 6 hours has elapsed since beacon activation, that is in this example until
|
||
09.17h UTC, at which time if an RLM wasn’t acquired earlier the GNSS Receiver reverts to the
|
||
GNSS timings in section 4.5.5.4. If the beacon is deactivated then the entire operation cycle
|
||
commences again from the beginning when the beacon is next activated.
|
||
NOTE – The Galileo system will cease sending RLM messages back to the beacon, either once
|
||
it receives an RLM Acknowledgement confirming that the RLM has been received by the
|
||
beacon, or 6 hours have elapsed since the first RLS Request message from the beacon was
|
||
received by the RLSP, whichever is the sooner.
|
||
* There is no specific requirement to deactivate the GNSS receiver between position updates so the “next activation”
|
||
may simply consist of ensuring that the GNSS receiver remains on at the start of this period. The GNSS receiver may
|
||
have been previously activated due to a required GNSS position update and not as a result of the Moffset timing.
|
||
† Note that in between Moffset activations the GNSS receiver must also comply with the requirements in section 4.5.5.4.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-17
|
||
|
||
4.5.7.2.2
|
||
Derivation of Moffset
|
||
The value of Moffset per each beacon is computed from the beacon 15 Hex ID, where the 19 bits
|
||
containing the coarse position of the beacon are considered to be filled with default bits. More
|
||
specifically:
|
||
Moffset = BIN2DEC(CRC16(Beacon 15 Hex ID in Binary)) mod 60
|
||
Where BIN2DEC and CRC16 are functions performing the conversion of binary number to a decimal
|
||
number and the CRC-16 of a stream of bits with polynomial x16+x15+x2+1 respectively. The
|
||
CRC-16 is used to obtain a uniform distribution of Moffset.
|
||
An example calculation of Moffset is shown in Figure B.3 in Annex B.
|
||
4.5.7.3
|
||
Indications of RLS and RLM
|
||
The beacon shall provide distinct RLS Type 1 request and RLM indication designed to advise the
|
||
user that:
|
||
• a Type 1 RLS (or Type 1 RLS Test) request has been transmitted, and
|
||
• the beacon has received a Type 1 Return Link Message (RLM Type 1) (or Test
|
||
Return Link Message (Test RLM Type 1)) associated with this beacon.
|
||
The RLS and RLM indications shall:
|
||
be readily visible to the user when the beacon is operated in all its normal
|
||
operational configurations as declared by the manufacturer;
|
||
be clearly visible to the user in direct sunlight;
|
||
provide distinct unique indication;
|
||
remain inactive at all times when the beacon message is encoded with any protocol
|
||
other than the RLS Location Protocol or RLS Location Test Protocol;
|
||
within 5 seconds after the beacon encoded with the RLS Location Protocol or RLS
|
||
Location Test Protocol transmits an initial RLS request , commence indication of
|
||
an RLS request until either a valid RLM Type 1 or Test RLM message is received,
|
||
or the beacon is deactivated, or the beacon battery is discharged;
|
||
within 5 seconds of the beacon receiving a valid RLM Type 1 or Test RLM
|
||
message, commence a distinct RLM indication until either the beacon is
|
||
deactivated or the beacon battery is discharged;
|
||
only provide the RLM indication when the beacon has received an RLM Type 1
|
||
or Test RLM message with the 15 Hex ID programmed into these messages that
|
||
match this beacon 15 Hex ID; and
|
||
if the RLS functionality is enabled, provide an indication during the self-test mode
|
||
in accordance with section 4.5.4 e).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-18
|
||
|
||
4.5.7.4
|
||
Confirmation of a Return-Link Message Receipt
|
||
Upon receipt of an Acknowledgement Type-1 RLM or a Test RLM associated with the beacon
|
||
15 Hex ID, the beacon shall, within 1 minute, acknowledge the RLM receipt by changing the coding
|
||
of bits 111 and 112 in its message as defined for the RLS Location Protocol in sectionA3.3.7.2. Once
|
||
changed, bits 111 and 112 shall no longer be changed until the beacon is switched off or the beacon
|
||
battery is depleted.\*
|
||
Once the beacon has received an Acknowledgement Type-1 RLM or a Test RLM and has
|
||
acknowledged the RLM receipt, the GNSS Receiver shall continue to function as required by section
|
||
4.5.7.2.1 unless the beacon is coded as a "Type-1 only capable" RLS beacon as defined in section
|
||
A.3.3.7.3. In this specific case only, the GNSS receiver may revert to operating as defined within
|
||
Section 4.5.5.4, taking into account the time elapsed between the moment of activation and the
|
||
moment when the Type-1 RLM message is received, until either the beacon is deactivated or the
|
||
beacon performance ceases to meet specification due to battery depletion.
|
||
Example:
|
||
A beacon is activated at 9:00. It transmits emergency signals for 2 hours and 30 minutes. During the
|
||
period from 11:00 to 11:15 it receives a Type-1 RLM Acknowledgement. The GNSS receiver could
|
||
then revert to operating in accordance to the requirements for internal GNSS receiver without the RLS
|
||
capability which specifies that, for the first 6 hours after beacon activation, the navigation device shall
|
||
attempt location update at least once every 30 minutes.
|
||
4.5.7.5
|
||
RLS Beacon Documentation
|
||
The operation of the RLS function shall be clearly explained in the User Manual including the
|
||
performance characteristics of the overall RLS system. Suggested minimum text is provided in
|
||
Annex D.
|
||
Beacon Labelling and Marking
|
||
All beacons shall have the following information indelibly marked on the exterior of the beacon:
|
||
beacon model name,
|
||
beacon manufacturers name,
|
||
Cospas-Sarsat type approval certificate number (C/S TAC Number),
|
||
beacon 15-Hex ID,
|
||
Aircraft operator 3LD - for ELT(DT)s coded with a 3LD in PDF-2,
|
||
beacon operating temperature range,
|
||
minimum operating lifetime,
|
||
* Transmission of RLMs associated with the beacon 15 HEX ID may be stopped by the RLSP upon a successful receipt of
|
||
the confirmation of the RLM reception by the beacon.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4-19
|
||
|
||
for RLS-capable beacons:
|
||
- wording on the Beacon Identity label (label with C/S TAC Number /
|
||
15-Hex ID) indicating whether the RLS function is enabled or disabled,
|
||
- marking(s) to indicate which are the RLS and RLM indicator(s).
|
||
Operator Controlled Voice Transceivers
|
||
If an operator-controlled voice transceiver integrated with a beacon uses the same power source as
|
||
the beacon, then there are additional considerations affecting the beacon operating lifetime:
|
||
• the maximum cumulative duration of voice-transceiver transmission that does not
|
||
reduce available power-source energy below the amount needed to operate the beacon
|
||
for its declared minimum operating lifetime; and
|
||
• transceiver operational features that mitigate the effects of unintentional transmissions
|
||
by limiting the duration of each transmission to a certain maximum time (“time-out
|
||
timer”).
|
||
An operator-controlled voice transceiver that shares a power source with the beacon is assumed to be
|
||
a transceiver used only in distress situations (similar to a 121.5-MHz homing signal sharing a beacon’s
|
||
power source). Therefore, the voice transceiver shall not be capable of drawing power from the shared
|
||
power source until after the beacon has been activated. The manufacturer shall specify a maximum
|
||
cumulative voice-transceiver transmit-mode ‘on’ time that ensures that sufficient energy is available
|
||
from the common (beacon/transceiver) power supply to allow the beacon to meet the manufacturer’s
|
||
declared Minimum Operating Lifetime.
|
||
The declared maximum cumulative transmit-mode ‘on’ time shall not be less than 10% of the declared
|
||
Minimum Operating Lifetime for the beacon. The declared maximum cumulative transmit-mode
|
||
‘on’ time shall be clearly reflected in the beacon instruction manual, together with an
|
||
explanation/warning to the user that voice-transceiver transmit operation exceeding the declared
|
||
maximum cumulative transmit-mode ‘on’ time will reduce duration of operation of the activated 406-
|
||
MHz beacon.
|
||
An operator-controlled voice transceiver as described above should ideally include a means to prevent
|
||
continuous transmission by the voice transceiver beyond a predetermined limit of time set by the
|
||
beacon manufacturer’s design, once the Push-To-Talk (PTT) switch has been operated (“time-out”
|
||
timer). If this feature is included in the design, continuous transmission by the voice transceiver shall
|
||
not exceed 30 minutes. Releasing and reactivating the PTT switch should reset the “time-out timer”
|
||
for this function.
|
||
Operator controlled voice transceivers in beacons without the above “time-out timer” function shall
|
||
be deemed to transmit continuously for the purposes of the operating lifetime at minimum temperature
|
||
test.
|
||
|
||
|
||
|
||
|
||
|
||
4-20
|
||
|
||
ELT(DT)s Specifically Designed to Withstand a Crash Impact
|
||
4.5.10.1
|
||
Introduction
|
||
Potentially there may be ELT(DT)s that have additional functionality, as defined by National
|
||
Administrations and/or Aviation Authorities, which are designed to:
|
||
1)
|
||
function both prior to a crash and after a crash, and withstand crash impact
|
||
conditions;
|
||
2)
|
||
be activated in-flight or by crash;
|
||
3)
|
||
have homing and locating signals; and/or
|
||
4)
|
||
have extended operating life.
|
||
Crash Survivable ELT(DT)s should function as follows.
|
||
If the beacon is activated in one aircraft state (e.g., In Flight) and the aircraft transitions to another
|
||
state (e.g., On Ground) while the beacon is still activated, the beacon transmission characteristics
|
||
should behave as indicated for the new aircraft state as per the table above.
|
||
If there is a conflict between the requirements of this section and any other section of this document,
|
||
then this section takes precedence.
|
||
4.5.10.2
|
||
Beacon Hex ID
|
||
The Hex ID of the ELT(DT) shall not change from when activated in flight compared to when
|
||
operating after a crash.
|
||
4.5.10.3
|
||
Burst Repetition Period (with Crash Detection)
|
||
If the ELT(DT) includes a crash detection function, within 5 seconds of a crash the ELT(DT) shall
|
||
initiate or restart the transmission schedule for an ELT(DT) as if the ELT(DT) had just been activated
|
||
Activation Criteria
|
||
Activation Means
|
||
Manual
|
||
Automatic
|
||
Activation by the
|
||
Beacon
|
||
Avionics Trigger
|
||
Unknown aircraft state
|
||
406 Distress
|
||
Tracking (DT)
|
||
sequence only
|
||
preferred,
|
||
homing permitted
|
||
406 FGB sequence
|
||
and homing
|
||
406 DT sequence only
|
||
On Ground
|
||
406 DT sequence
|
||
and homing
|
||
406 Post Crash (PC)
|
||
sequence and homing
|
||
Disabled
|
||
In Flight
|
||
406 DT sequence
|
||
only preferred
|
||
homing permitted
|
||
406 PC sequence and
|
||
homing
|
||
406 DT sequence only
|
||
|
||
|
||
|
||
4-21
|
||
|
||
as defined in section 2.2.1 and maintain this transmission schedule for the first 95 bursts
|
||
(approximately 30 minutes) after the crash detection. After burst number 95 (after crash detection),
|
||
the ELT(DT) shall transmit bursts with a repetition period randomized with uniform (flat) distribution
|
||
around a mean value of 120 seconds, so that the time intervals between the beginnings of two
|
||
successive bursts (TR) are randomly distributed over the interval of 115 to 125 seconds. After burst
|
||
number 95 (after crash detection), the standard deviation over the next 18 successive bursts of TR shall
|
||
be greater than 2.5 seconds. The minimum value of TR observed over the 18 successive bursts shall
|
||
be between 115.0 and 115.2 seconds, the maximum value of TR observed over the 18 successive
|
||
bursts shall be between 124.8 and 125.0 seconds.
|
||
For an ELT(DT) transmitting the 3LD in PDF-2, after burst number 95, after the crash detection, the
|
||
3LD is no longer required to be transmitted.
|
||
Operation after 370 minutes without crash detection
|
||
If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash mode or
|
||
has not been deactivated, then it shall continue transmitting on the same schedule (with the GNSS
|
||
encoded location updated before each transmitted burst) as before the 370-minute limit was reached
|
||
until the ELT(DT) is either deactivated, gets a subsequent “crash” indication to transition to the “post-
|
||
crash” mode, runs out of battery life or reaches the minimum duration of continuous operation,
|
||
whichever occurs first.
|
||
4.5.10.4
|
||
GNSS Update Rate (after Crash Detection)
|
||
During a 30-minute period after a crash detection, the GNSS encoded location shall be updated
|
||
before each transmitted burst, as per section 4.5.5.6.
|
||
Beyond 30 minutes, the GNSS encoded location shall be updated in accordance with
|
||
section 4.5.5.4 and 4.5.5.5 (if applicable).
|
||
The transmission in the beacon message of the external source of position is only subsequently
|
||
allowed if the internal GNSS receiver is not able to produce a valid encoded position in accordance
|
||
with section 4.5.5.4. If position data is available from both sources, before any subsequent burst,
|
||
then the location produced by the internal GNSS receiver has priority over the external source of
|
||
data.
|
||
4.5.10.5
|
||
Duration of Continuous Operation
|
||
The minimum duration of continuous operation under worst case conditions for this type of
|
||
ELT(DT) shall be at least 24 hours at any temperature throughout the specified operating
|
||
temperature range. This is to be understood to mean the total operating time which is a combination
|
||
of the time prior to a crash (minimum of 10 minutes and maximum of 370 minutes) and post-crash.
|
||
For the avoidance of doubt, if the ELT(DT) continues to operate after 370 minutes without crash
|
||
detection, then the 24-hour minimum duration of continuous operation does not apply and might be
|
||
reduced as a result of the extended operation in this pre-crash mode.
|
||
|
||
4-22
|
||
|
||
4.5.10.6
|
||
Homing and Locating Signals
|
||
The inclusion or otherwise of one or more homing signals in the ELT(DT) and the activation and
|
||
duration of any homing signal transmissions are the responsibility of national administrations.
|
||
ELT(DT)s Combined with Automatic ELTs
|
||
4.5.11.1
|
||
Introduction
|
||
Potentially there may be ELT(DT)s that have combined functionality, that is they function as an
|
||
ELT(DT) during a flight, but on detection of an incident perform as an Automatic ELT (either an
|
||
ELT(AD), ELT(AF) or ELT(AP)), such a combined ELT would be required to meet the regulatory
|
||
requirements set by National Administrations and/or Aviation Authorities, for both an ELT(DT)
|
||
and the type of Automatic ELT that it is combined with.
|
||
However, from a Cospas-Sarsat perspective there are certain key functions of such a combined
|
||
ELT that need to be clearly defined related to its performance and operation and the transition from
|
||
an ELT(DT) to either an ELT(AD), ELT(AF) or ELT(AP) as follows.
|
||
ELT(DT)s combined with Automatic ELTs should function as follows.
|
||
Activation Criteria
|
||
Activation Means
|
||
Manual
|
||
Automatic
|
||
Activation by the
|
||
Beacon
|
||
Avionics Trigger
|
||
Unknown aircraft state
|
||
406 Distress
|
||
Tracking (DT)
|
||
sequence only
|
||
preferred,
|
||
homing permitted
|
||
406 FGB sequence
|
||
and homing
|
||
406 DT sequence only
|
||
On Ground
|
||
406 FGB sequence
|
||
and homing
|
||
406 FGB sequence
|
||
and homing
|
||
Disabled
|
||
In Flight
|
||
406 DT sequence
|
||
only preferred,
|
||
homing permitted
|
||
406 FGB sequence
|
||
and homing
|
||
406 DT sequence only
|
||
If the beacon is activated in one aircraft state (e.g., In Flight) and the aircraft transitions to another
|
||
state (e.g., On Ground) while the beacon is still activated, the beacon transmission characteristics
|
||
should behave as indicated for the new aircraft state as per the table above.
|
||
If there is a conflict between the requirements of this section and any other section of this
|
||
document, then this section takes precedence.
|
||
4.5.11.2
|
||
Beacon Coding and Beacon Hex ID
|
||
The combined ELT(DT) and Automatic ELT shall be encoded with the ELT(DT) Location
|
||
Protocol at all times. The Beacon Coding shall not change to another Protocol when operating as
|
||
an Automatic ELT.
|
||
|
||
|
||
|
||
4-23
|
||
|
||
The 15-Hex ID shall remain the same regardless of whether the device is operating as an ELT(DT)
|
||
or as an automatic ELT.
|
||
Bits 107 and 108 in the ELT(DT) Location Protocol shall be used to indicate both the ELT(DT)
|
||
and Automatic ELT means of activation. The most recent means of activation, whether by the
|
||
ELT(DT) or the Automatic ELT shall be encoded and transmitted in the beacon message.
|
||
4.5.11.3
|
||
Burst Repetition Period
|
||
When activated as an ELT(DT) the beacon shall meet the burst repetition requirements for an
|
||
ELT(DT) as defined in section 2.2.1. When activated as an Automatic ELT or if transitioning from
|
||
an ELT(DT) to an Automatic ELT then the combined device shall commence the burst repetition
|
||
requirements for a non-ELT(DT) 406 MHz beacon as defined in section 2.2.1.
|
||
For ELT(DT)s combined with an automatic ELT and transmitting the 3LD in PDF-2, the
|
||
transmissions for the first five minutes after activation as an automatic ELT shall alternate between
|
||
the encoded location and the 3LD in PDF-2, starting with the encoded location.
|
||
Operation after 370 minutes without crash detection
|
||
If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash mode or
|
||
has not been deactivated, then it shall continue transmitting on the same schedule (with the GNSS
|
||
encoded location updated before each transmitted burst) as before the 370-minute limit was reached
|
||
until the ELT(DT) is either deactivated, gets a subsequent “crash” indication to transition to the “post-
|
||
crash” (Automatic ELT) mode, runs out of battery life or reaches the minimum duration of continuous
|
||
operation, whichever occurs first.
|
||
4.5.11.4
|
||
System Requirements
|
||
The combined ELT(DT) and Automatic ELT shall meet the more stringent requirements that apply
|
||
to either part of the device (except where stated otherwise below), for the operating temperature
|
||
range (as per section 4.2.1) of the beacon under test. Specifically, the combined device shall:
|
||
a) comply with the Digital Message Requirements for an ELT(DT) (section 2.2.4 b));
|
||
b) comply with the Medium-Term Frequency Stability Requirements for a non-ELT(DT)
|
||
406 MHz beacon (section 2.3.1);
|
||
c) meet the Transmitter Power Output requirements for an ELT(DT) (section 2.3.2) while
|
||
operating as an ELT(DT), when operating as an Automatic ELT or when transitioning from
|
||
an ELT(DT) to an Automatic ELT then the Power Output requirement of the combined
|
||
device may be relaxed to that of a non-ELT(DT) 406 MHz beacon (section 2.3.2);
|
||
d) comply with the Modulation rise and fall times for an ELT(DT) (section 2.3.6);
|
||
e) comply with both the Temperature Gradient requirements for an ELT(DT) and the
|
||
Temperature Gradient requirements for a non-ELT(DT) 406 MHz beacon (section 4.2.2);
|
||
and
|
||
f) comply with both the Thermal Shock requirements for an ELT(DT) and the Thermal Shock
|
||
requirements for a non-ELT(DT) 406 MHz beacon (section 4.2.3).
|
||
|
||
4-24
|
||
|
||
4.5.11.5
|
||
Cancellation Message
|
||
The cancellation message shall function as it would for an ELT(DT) (as defined in section 3.3)
|
||
while functioning as an Automatic ELT as well as while functioning as an ELT(DT).
|
||
4.5.11.6
|
||
Encoded Position Data and Navigation Device Performance
|
||
While operating as an ELT(DT) the navigation device shall comply with the requirements of
|
||
section 4.5.5.6.
|
||
When operating as an Automatic ELT, that is automatically activated, the navigation device shall
|
||
comply with the requirements of sections 4.5.5.3, 4.5.5.4 and 4.5.5.5 (if applicable).
|
||
When operating as an Automatic ELT, that is manually activated, the navigation device shall
|
||
comply with the requirements of section 4.5.5.6, for a period of at least 6 hours and 10 minutes,
|
||
after which time the navigation device shall comply with the requirements of sections 4.5.5.3,
|
||
4.5.5.4 and 4.5.5.5 (if applicable).
|
||
The transmission in the beacon message of position from an external source of navigation
|
||
information is only subsequently allowed if the internal GNSS receiver is not able to produce a
|
||
valid encoded position in accordance to the section 4.5.5.4. If position data is available from both
|
||
sources, before any subsequent burst, then the location produced by the internal GNSS receiver
|
||
has priority over the external source of data.
|
||
4.5.11.7
|
||
Duration of Continuous Operation
|
||
The minimum duration of continuous operation under worst case conditions for this type of
|
||
combined ELT shall be a combination of the minimum duration of continuous operation for an
|
||
ELT(DT) (370 minutes) and the minimum duration of continuous operation for a non-ELT(DT)
|
||
406 MHz beacon (24 hours), thus resulting in a total of at least 30 hours and 10 minutes. For the
|
||
avoidance of doubt, if the combined ELT continues to operate after 370 minutes without crash
|
||
detection then the 30 hours and 10 minutes minimum duration of continuous operation does not
|
||
apply, and might be reduced as a result of the extended operation in the ELT(DT) mode.
|
||
4.5.11.8
|
||
Class of Operation
|
||
The combined device may, if required, function at different classes of temperature as an ELT(DT)
|
||
or Automatic ELT (e.g., the ELT(DT) part of the device may be specified to operate as a Class 1
|
||
device, while the Automatic ELT part of the device may be specified to operate as a Class 2
|
||
device).
|
||
4.5.11.9
|
||
Homing and Locating Signals
|
||
The inclusion or otherwise of one or more homing signals in the combined device and the
|
||
activation and duration of any homing signal transmissions are the responsibility of national
|
||
administrations.
|
||
|
||
4-25
|
||
|
||
External Power Source for ELT(DT)s
|
||
The ELT(DT) shall have its own integral or internal power source. However, when available, all
|
||
ELT(DT)s (including those in compliance with sections 4.5.10 and 4.5.11) may use the external
|
||
aircraft electrical power source. An ELT(DT) shall comply with all applicable requirements
|
||
regardless of power source. In addition, the ELT(DT) performance shall not be impacted by
|
||
switching between power sources.
|
||
– END OF SECTION 4 –
|
||
|
||
|
||
|
||
ANNEXES
|
||
TO THE SPECIFICATION FOR
|
||
COSPAS-SARSAT
|
||
406 MHz DISTRESS BEACONS
|
||
|
||
A-1
|
||
|
||
ANNEX A
|
||
BEACON CODING
|
||
A1
|
||
GENERAL
|
||
A1.1 Summary
|
||
This annex defines the 406 MHz beacon digital message coding. The digital message is divided into
|
||
various bit fields as follows:
|
||
Short Message Format (see Figure A1)
|
||
Bit Field Name
|
||
Bit Field Location
|
||
1. Bit synchronization
|
||
bit 1 through bit 15
|
||
2. Frame synchronization
|
||
bit 16 through bit 24
|
||
3. First protected data field (PDF-1)
|
||
bit 25 through bit 85
|
||
4. First BCH error correcting field (BCH-1)
|
||
bit 86 through bit 106
|
||
5. Non-protected data field
|
||
bit 107 through bit 112
|
||
Long Message Format (see Figure A2)
|
||
Bit Field Name
|
||
Bit Field Location
|
||
1. Bit synchronization
|
||
bit 1 through bit 15
|
||
2. Frame synchronization
|
||
bit 16 through bit 24
|
||
3. First protected data field (PDF-1)
|
||
bit 25 through bit 85
|
||
4. First BCH error correcting field (BCH-1)
|
||
bit 86 through bit 106
|
||
5. Second protected data field (PDF-2)
|
||
bit 107 through bit 132
|
||
6. Second BCH error correcting field (BCH-2)
|
||
bit 133 through bit 144
|
||
The bit synchronization and frame synchronization fields are defined in sections 2.2.4.1 and 2.2.4.2,
|
||
respectively.
|
||
The first protected data field (PDF-1) and the non-protected data field of the short message are
|
||
defined in section 3.1 and section A2 of this Annex, and shown in Figures A1, A3 and A4.
|
||
The first protected data field (PDF-1) and the second protected data field (PDF-2) of the long
|
||
message are defined in section 3.1 and section A3 of this Annex, and shown in Figures A2, A5, A6,
|
||
A7, A8, A9, A10 and A11.
|
||
The BCH error correcting fields BCH-1 and BCH-2 fields are defined in section 3.1 and the
|
||
corresponding 21 bit BCH error-correcting code and 12 bit BCH error-correcting code are described
|
||
at Annex B.
|
||
|
||
A-2
|
||
|
||
A1.2 Message Format Flag, Protocol Flag, and Country Code
|
||
The bit allocations for the message format flag, protocol flag and country code are identical in all
|
||
beacon protocols. They are assigned in PDF-1 of the short and the long messages as follows:
|
||
Bits
|
||
Usage
|
||
|
||
format flag (F)
|
||
|
||
protocol flag (P)
|
||
27-36
|
||
country code
|
||
A1.2.1
|
||
Format Flag
|
||
The format flag (bit 25) shows whether the message is short or long using the following code:
|
||
F=0
|
||
short format
|
||
F=1
|
||
long format
|
||
A1.2.2
|
||
Protocol Flag
|
||
The protocol flag (bit 26) indicates which type of protocol is used to define the structure of encoded
|
||
data, according to the following code:
|
||
P=0
|
||
standard location protocols or national location protocol
|
||
P=1
|
||
user protocols or user-location protocols.
|
||
The various protocols are identified by a specific protocol code, as described in section A1.3.
|
||
A1.2.3
|
||
Country Code
|
||
Bits 27-36 designate a three-digit decimal country code number expressed in binary notation.
|
||
Country codes are based on the International Telecommunication Union (ITU) Maritime
|
||
Identification Digit (MID) table available on the ITU website (http://www.itu.int/en/ITU-
|
||
R/terrestrial/fmd/Pages/mid.aspx). National administrations which were allocated more than one
|
||
MID code may opt to use only one of these codes. However, when the 6 trailing digits of a MMSI
|
||
are used to form the unique beacon identification, the country code shall always correspond to the
|
||
first 3 digits of the MMSI code. This coding method should be used only if the first 3 digits (MID)
|
||
forming part of a unique 9-digit code of ship station identity correspond to the 3-digit country code
|
||
encoded in bits 27 to 36.
|
||
Exceptionally when 98MIDXXXX is used in encoding EPIRB onboard craft associated with a
|
||
parent ship in accordance with recommendation ITU-R M.585, 98M is filled into the country code
|
||
field in binary notation and the trailing six digits IDXXXX are filled into bits 40-75 using the
|
||
modified-Baudot code.
|
||
For all types of protocols, except the test protocols, the country code designates the country of
|
||
beacon registration, where additional information can be obtained from a database. But when
|
||
98MIDXXXX is used in encoding craft associated with a parent ship, country code 98M doesn’t
|
||
designate the country of beacon registration, the 3rd, 4th and 5th digits MID provide this.
|
||
|
||
A-3
|
||
|
||
A1.3 Protocol Codes
|
||
Each coding protocol is identified by a unique protocol code defined as follows:
|
||
-
|
||
3-bit code in bits 37 to 39 for user and user-location protocols;
|
||
-
|
||
4-bit code in bits 37 to 40 for standard location and national location protocols, RLS
|
||
Location Protocol and ELT(DT) Location Protocol.
|
||
Table A1 shows the combinations of the format flag and the protocol flag which identify each
|
||
category of coding protocols. The protocol codes assignments are summarized in Table A2.
|
||
Table A1: Format Flag and Protocol Flag Combinations
|
||
Format Flag (bit 25) →
|
||
Protocol Flag (bit 26)
|
||
|
||
(short)
|
||
|
||
(long)
|
||
|
||
(protocol code: bits 37-40)
|
||
Not Used
|
||
Standard Location Protocols
|
||
National Location Protocol
|
||
RLS Location Protocols
|
||
ELT(DT) Location Protocol
|
||
|
||
(protocol code: bits 37-39)
|
||
User Protocols
|
||
User Protocols (\*)
|
||
User-Location Protocols
|
||
Figure A1: Data Fields of the Short Message Format
|
||
Bit
|
||
Synchronization
|
||
Frame
|
||
Synchronization
|
||
First Protected Data Field (PDF-1)
|
||
BCH-1
|
||
Non-Protected Data Field
|
||
Unmodulated
|
||
Carrier
|
||
(160 ms)
|
||
Bit
|
||
Synchronization
|
||
Pattern
|
||
Frame
|
||
Synchronization
|
||
Pattern
|
||
Format
|
||
Flag
|
||
Protocol
|
||
Flag
|
||
Country
|
||
Code
|
||
Identification
|
||
Data
|
||
21-Bit
|
||
BCH
|
||
Code
|
||
Emergency Code/ National Use
|
||
or Supplement. Data
|
||
Bit No.
|
||
1-15
|
||
16-24
|
||
|
||
|
||
27-36
|
||
37-85
|
||
86-106
|
||
107-112
|
||
15 bits
|
||
9 bits
|
||
1 bit
|
||
1 bit
|
||
10 bits
|
||
49 bits
|
||
21 bits
|
||
6 bits
|
||
Figure A2: Data Fields of the Long Message Format
|
||
Bit
|
||
Synchronization
|
||
Frame
|
||
Synchronization
|
||
First Protected Data Field (PDF-1)
|
||
BCH-1
|
||
Second Protected
|
||
Data Field (PDF-2)
|
||
BCH-2
|
||
Unmodulated
|
||
Carrier
|
||
(160 ms)
|
||
Bit
|
||
Synchronization
|
||
Pattern
|
||
Frame
|
||
Synchronization
|
||
Pattern
|
||
Format
|
||
Flag
|
||
Protocol
|
||
Flag
|
||
Country
|
||
Code
|
||
Identification or
|
||
Identification
|
||
plus Position
|
||
21-Bit
|
||
BCH
|
||
Code
|
||
Supplementary and
|
||
Position or National
|
||
Use Data
|
||
12-Bit
|
||
BCH
|
||
Code
|
||
Bit No.
|
||
1-15
|
||
16-24
|
||
|
||
|
||
27-36
|
||
37-85
|
||
86-106
|
||
107-132
|
||
133-144
|
||
15 bits
|
||
9 bits
|
||
1 bit
|
||
1 bit
|
||
10 bits
|
||
49 bits
|
||
21 bits
|
||
26 bits
|
||
12 bits
|
||
* Only Orbitography and National User protocols (see section A2.7 and document C/S T.006, and section A2.8,
|
||
respectively).
|
||
|
||
A-4
|
||
|
||
Table A2: Protocol Codes Assignments
|
||
A2-A:
|
||
User and User-Location Protocols
|
||
(F=0, P=1) short message
|
||
(F=1, P=1) long message
|
||
Protocol Codes
|
||
(Bits 37 - 39)
|
||
1. EPIRB - Maritime User Protocol:
|
||
(MMSI, 6 digits)
|
||
|
||
(radio call sign, 6 characters)
|
||
|
||
2. EPIRB - Radio Call Sign User Protocol
|
||
|
||
3. ELT - Aviation User Protocol
|
||
(aircraft registration markings)
|
||
|
||
4. Serial User Protocol:
|
||
|
||
bits 40, 41, 42 used to identify beacon type:
|
||
000 ELTs with serial identification number;
|
||
001 ELTs with aircraft operator designator & serial number;
|
||
010 float free EPIRBs with serial identification number;
|
||
100 non float free EPIRBs with serial identification number;
|
||
110 PLBs with serial identification number;
|
||
011 ELTs with aircraft 24-bit address;
|
||
101 & 111 spares.
|
||
bit 43 = 0:
|
||
serial identification number is assigned nationally; or
|
||
bit 43 = 1:
|
||
identification data include the C/S type approval certificate
|
||
number.
|
||
5. Test User Protocol
|
||
|
||
6. Orbitography Protocol
|
||
|
||
7. National User Protocol\*
|
||
|
||
8. Not to be used (allocated to Second Generation Beacons)
|
||
|
||
A2-B:
|
||
Standard National, RLS and ELT(DT) Location Protocols
|
||
(F=1, P=0) long message
|
||
Protocol Codes
|
||
(Bits 37 - 40)
|
||
Standard Location Protocols
|
||
1. EPIRB - MMSI/Location Protocol
|
||
|
||
2. ELT - 24-bit Address/Location Protocol
|
||
|
||
3. Serial Location Protocols
|
||
a) ELT - serial
|
||
|
||
b) ELT - aircraft operator designator
|
||
|
||
c) EPIRB-serial
|
||
|
||
d) PLB-serial
|
||
|
||
4. Ship Security
|
||
|
||
5. National Location Protocol
|
||
a) ELT
|
||
|
||
b) EPIRB
|
||
|
||
c) PLB
|
||
|
||
* The National User Protocol has certain bits which are nationally defined, as described in section A2.8.
|
||
|
||
A-5
|
||
|
||
6. Test location Protocols
|
||
a) Standard Test Location Protocol
|
||
|
||
b) National Test Location Protocol
|
||
|
||
7. RLS Location Protocol
|
||
|
||
8. ELT(DT) Location Protocol
|
||
|
||
9. Spare
|
||
0000, 0001
|
||
A2
|
||
USER PROTOCOLS
|
||
This section defines the user protocol message formats which can be used to encode the beacon
|
||
identification and other data in the message transmitted by a 406 MHz distress beacon.
|
||
A2.1 Structure of User Protocols
|
||
The user protocols have the following structure:
|
||
bits
|
||
usage
|
||
|
||
format flag (short message=0, long message =1)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
protocol code
|
||
40-83
|
||
identification data
|
||
84-85
|
||
auxiliary radio-locating device type(s)
|
||
Bits 37-39 in the protocol code field designate one of the user protocol codes as listed in
|
||
Table A2-A, and indicate how the remaining bits of identification data are encoded/decoded.
|
||
Bits 40-83 are used to encode the identification data of the beacon and, together with the protocol
|
||
flag, the country code, the protocol code, and bits 84-85, shall form a unique identification for each
|
||
beacon, i.e. the beacon 15 Hex ID. They will be discussed separately for each user protocol.
|
||
Bits 84-85 are used to indicate for all user protocols excluding the orbitography protocol, the type
|
||
of auxiliary radio-locating device(s) forming part of the particular beacon. The assignment of bits
|
||
is as follows:
|
||
bits 84-85
|
||
auxiliary radio-locating device type
|
||
|
||
no auxiliary radio-locating device
|
||
|
||
121.5 MHz
|
||
|
||
maritime 9 GHz Search and Rescue Radar Transponder (SART)
|
||
|
||
other auxiliary radio-locating device(s)
|
||
If other auxiliary radio-locating device(s) is (are) used in addition to 121.5 MHz, the code for
|
||
121.5 MHz (i.e. 01) should be used.
|
||
The bit assignments for user protocols, in PDF-1 of the 406 MHz beacon digital message, are
|
||
summarized in Figure A3.
|
||
|
||
A-6
|
||
|
||
Figure A3: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols
|
||
1. MARITIME USER PROTOCOL
|
||
Bits
|
||
25 26 27
|
||
36 37
|
||
39 40
|
||
|
||
|
||
.....
|
||
|
||
|
||
Country Code
|
||
|
||
|
||
MMSI or Radio Call Sign (42 bits)
|
||
|
||
|
||
R
|
||
L
|
||
2. RADIO CALL SIGN USER PROTOCOL
|
||
Bits
|
||
25 26 27
|
||
36 37
|
||
39 40
|
||
|
||
|
||
.....
|
||
|
||
|
||
Country Code
|
||
|
||
|
||
Radio Call Sign (42 bits)
|
||
|
||
|
||
R
|
||
L
|
||
3. SERIAL USER PROTOCOL
|
||
Bits
|
||
25 26 27
|
||
36 37
|
||
39 40
|
||
|
||
|
||
73 74
|
||
|
||
|
||
.....
|
||
|
||
|
||
Country Code
|
||
|
||
|
||
T T
|
||
T
|
||
C
|
||
Serial Number and other Data
|
||
C/S Cert. No or
|
||
National Use
|
||
R
|
||
L
|
||
4. AVIATION USER PROTOCOL
|
||
Bits
|
||
25 26 27
|
||
36 37
|
||
39 40
|
||
|
||
|
||
.....
|
||
|
||
|
||
Country Code
|
||
|
||
|
||
Aircraft Registration Marking (42 bits)
|
||
E N 1
|
||
R
|
||
L
|
||
5. NATIONAL USER PROTOCOL
|
||
Bits
|
||
25 26 27
|
||
36 37
|
||
39 40
|
||
|
||
......
|
||
F
|
||
|
||
Country Code
|
||
|
||
|
||
National Use (46 bits)
|
||
6. TEST USER PROTOCOL
|
||
Bits
|
||
25 26 27
|
||
36 37
|
||
39 40
|
||
|
||
.....
|
||
F
|
||
|
||
Country Code
|
||
|
||
|
||
Test Beacon Data (46 bits)
|
||
7. ORBITOGRAPHY PROTOCOL
|
||
Bits
|
||
25 26 27
|
||
|
||
|
||
39 40
|
||
|
||
......
|
||
F
|
||
|
||
Country Code
|
||
|
||
|
||
Orbitography Data (46 bits)
|
||
8. SGB PROTOCOL (Reserved for SGB – but not transmitted)
|
||
Bits
|
||
25 26 27 36
|
||
|
||
39 40
|
||
|
||
......
|
||
…
|
||
|
||
Country Code
|
||
|
||
|
||
As Defined in C/S T.018 (46 bits)
|
||
Notes:
|
||
RL
|
||
=
|
||
Auxiliary radio-locating device (see section A2.1)
|
||
TTT =
|
||
000 - ELT with serial number
|
||
010 - float free EPIRB with serial number
|
||
011 - ELT with 24-bit aircraft address 100 - non float free EPIRB with serial number
|
||
001 - ELT with aircraft operator
|
||
110 - personal locator beacon (PLB) with serial number
|
||
designator and serial number
|
||
C
|
||
=
|
||
C/S Type Approval Certificate Flag:
|
||
"1" = C/S Type Approval Certificate number encoded in bits 74 to 83
|
||
"0" = other national use
|
||
F
|
||
=
|
||
Format Flag ("0" = short message, "1" = long message)
|
||
EN
|
||
=
|
||
Specific ELT number on designated aircraft (see section A2.4) \*
|
||
* Effective as of 1 November 2011.
|
||
|
||
A-7
|
||
|
||
Table A3: Modified-Baudot Code
|
||
Letter
|
||
Code
|
||
MSB
|
||
LSB
|
||
Letter
|
||
Code
|
||
MSB
|
||
LSB
|
||
Figure
|
||
Code
|
||
MSB
|
||
LSB
|
||
A
|
||
B
|
||
C
|
||
D
|
||
E
|
||
F
|
||
G
|
||
H
|
||
I
|
||
J
|
||
K
|
||
L
|
||
M
|
||
|
||
|
||
N
|
||
O
|
||
P
|
||
Q
|
||
R
|
||
S
|
||
T
|
||
U
|
||
V
|
||
W
|
||
X
|
||
Y
|
||
Z
|
||
|
||
|
||
( )\*
|
||
( - )**
|
||
/
|
||
|
||
|
||
MSB: most significant bit
|
||
* Space
|
||
LSB: least significant bit
|
||
** Hyphen
|
||
Note:
|
||
The modified-Baudot code is used to encode alphanumeric characters in EPIRB messages containing MMSI
|
||
or radio call sign identification, and in ELTs containing the aircraft registration marking or the 3-letter
|
||
aircraft operator designator.
|
||
A2.2 Maritime User Protocol
|
||
The maritime user protocol has the following structure:
|
||
Bits
|
||
Usage
|
||
|
||
format flag (=0)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
user protocol code (=010)
|
||
40-75
|
||
radio call sign or trailing 6 digits of MMSI
|
||
76-81
|
||
specific beacon number
|
||
82-83
|
||
spare (=00)
|
||
84-85
|
||
auxiliary radio-locating device type(s)
|
||
Bits 40-75 designate the radio call sign or the last 6 digits of the 9 digit maritime mobile service
|
||
identity (MMSI) using the modified-Baudot code shown in Table A3.
|
||
This code enables 6 characters to be encoded using 36 bits (6x6 = 36). This data will be right
|
||
justified with a modified-Baudot space (100100) being used where no character exists. If all
|
||
characters are digits, the entry is interpreted as the trailing 6 digits of the MMSI. This coding
|
||
method should be used only if the first 3 digits forming part of a unique 9-digit code of ship station
|
||
identity correspond to the 3 digit country code encoded in bits 27 to 36 or are 98M forming the
|
||
first three digits of an MMSI in the form 98MIDXXXX for craft associated with a parent vessel.
|
||
|
||
A-8
|
||
|
||
Bits 76 to 81 are used to identify specific beacons on the same vessel (the first or only float free
|
||
beacon shall be coded with a modified-Baudot zero (001101); additional beacons shall be
|
||
numbered consecutively using modified-Baudot characters 1 to 9 and A to Z).
|
||
The maritime user and the radio call sign user protocols may be used for beacons that require
|
||
coding with a radio call sign. The maritime user protocol may be used for radio call signs of 6 or
|
||
fewer characters. Radio call signs of 7 characters must be encoded using the radio call sign user
|
||
protocol.
|
||
A2.3 Radio Call Sign User Protocol
|
||
The radio call sign user protocol is intended to accommodate a vessel's radio call sign of up to
|
||
seven characters, where letters may be used only in the first four characters, thereby complying
|
||
with the ITU practice on formation of radio call signs.
|
||
The radio call sign user protocol has the following structure:
|
||
Bits
|
||
Usage
|
||
|
||
format flag (=0)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
user protocol code (=110)
|
||
40-75
|
||
radio call sign
|
||
40-63
|
||
first 4 characters (modified-Baudot)
|
||
64-75
|
||
last 3 characters (binary-coded decimal)
|
||
76-81
|
||
specific beacon number
|
||
82-83
|
||
spare (=00)
|
||
84-85
|
||
auxiliary radio-locating device type(s)
|
||
Bits 40 to 75 contain the radio call sign of up to 7 characters. Radio call signs of fewer than
|
||
7 characters should be left justified in the radio call sign field (bits 40-75) and padded with "space"
|
||
(1010) characters in the binary-coded decimal field (bits 64-75).
|
||
Bits 76 to 81 are used to identify specific beacons on the same vessel (the first or only float free
|
||
beacon shall be coded with a modified-Baudot zero (001101); additional beacons shall be
|
||
numbered consecutively using modified-Baudot characters 1 to 9 and A to Z).
|
||
|
||
A-9
|
||
|
||
A2.4 Aviation User Protocol
|
||
The aviation user protocol has the following structure:
|
||
Bits
|
||
Usage
|
||
|
||
format flag (=0)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
user protocol code (=001)
|
||
40-81
|
||
aircraft registration marking
|
||
82-83
|
||
specific ELT number
|
||
84-85
|
||
auxiliary radio-locating device type(s)
|
||
Bits 40-81 designate the aircraft registration marking which is encoded using the modified-Baudot
|
||
code shown in Table A3. This code enables 7 characters to be encoded using 42 bits (6x7=42).
|
||
This data will be right justified with a modified-Baudot space (100100) being used where no
|
||
character exists.
|
||
Bits 82-83 are used to create a unique ELT identification when several ELTs coded with the
|
||
Aviation User protocol are installed on the same aircraft. “00” indicates the first ELT on the aircraft
|
||
coded with this protocol and “01”, “10” and “11” identify additional ELTs, all coded with the
|
||
Aviation User protocol.\*
|
||
A2.5 Serial User Protocol
|
||
The serial user protocol is intended to permit the manufacture of beacons whose 15 Hex ID will
|
||
be identified in a data base giving specifics about the unit. The following types of serial
|
||
identification data can be encoded in the beacon:
|
||
• serial number
|
||
• 24-bit aircraft address number
|
||
• aircraft operator designator and a serial number.
|
||
Bits 40-42 indicate the beacon type with serial identification data encoded, as follows:
|
||
000 indicates an aviation ELT serial number is encoded in bits 44-63
|
||
010 indicates a maritime float free EPIRB serial number is encoded in bits 44-63
|
||
100 indicates a maritime non float free EPIRB serial number is encoded in bits 44-63
|
||
110 indicates a personal locator beacon (PLB) serial number is encoded in bits 44-63
|
||
|
||
indicates the aircraft 24-bit address is encoded in bits 44-67 and specific ELT number
|
||
in bits 68-73 if several ELTs, encoded with the same 24-bit address, are carried in the
|
||
same aircraft
|
||
* Effective as of 1 November 2011.
|
||
|
||
A-10
|
||
|
||
indicates an aircraft operator designator and a serial number are encoded in bits 44-61
|
||
and 62-73, respectively.
|
||
Bit 43 is a flag bit to indicate that the Cospas-Sarsat type approval certificate number is encoded.
|
||
If bit 43 is set to 1:
|
||
-
|
||
bits 64-73 should either be set to all 0s or allocated for national use and control (and will be
|
||
made public when assigned by the responsible administration) or used as defined for coding
|
||
the aircraft 24-bit address or aircraft operator designator;
|
||
-
|
||
bits 74-83 should be encoded with the Cospas-Sarsat type approval certificate number which
|
||
is assigned by the Cospas-Sarsat Secretariat for each beacon model approved according to
|
||
the type approval procedure of document C/S T.007. The certificate number is to be encoded
|
||
in binary notation with the least significant bit on the right.
|
||
If bit 43 is set to 0:
|
||
-
|
||
bits 64-83 are for national use and control (and will be made public when assigned by the
|
||
responsible administration) or used as defined for coding the aircraft 24-bit address or aircraft
|
||
operator designator.
|
||
Details of each type of serial identification data are given hereunder.
|
||
A2.5.1
|
||
Serial Number
|
||
The serial user protocol using a serial number encoded in the beacon message has the following
|
||
structure:
|
||
Bits 25 26 27 36 37 40 44 63 64 73 74 83 85
|
||
---+--+--+------------+-----+-----+-+-----------------+-------------+-------------+---+-
|
||
¦ ¦ ¦ Country ¦ ¦ ¦ ¦ (20 bits) ¦ All "0" or ¦ C/S cert. No. ¦
|
||
¦0 ¦1 ¦ Code ¦0 1 1¦T T T¦C¦ Serial Number ¦ Nat. Use ¦ or Nat. Use ¦R L¦
|
||
---------------------------------------------------------------------------------------
|
||
Bits
|
||
Usage
|
||
|
||
format flag (= 0)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
user protocol code (=011)
|
||
40-42
|
||
beacon type (=000, 010, 100 or 110)
|
||
|
||
flag bit for Cospas-Sarsat type approval certificate number
|
||
44-63
|
||
serial number
|
||
64-73
|
||
all 0s or national use
|
||
74-83
|
||
C/S type approval certificate number or national use
|
||
84-85
|
||
auxiliary radio-locating device type(s)
|
||
Bits 44-63 designate a serial identification code number ranging from 0 to 1,048,575 (i.e., 220-1)
|
||
expressed in binary notation, with the least significant bit on the right.
|
||
|
||
A-11
|
||
|
||
This serial number encoded in the beacon message is not necessarily the same as the production
|
||
serial number of the beacon.
|
||
A2.5.2
|
||
Aircraft 24-bit Address
|
||
The serial user protocol using the aircraft 24-bit address has the following structure:
|
||
Bits 25 26 27 36 37 40 44 67 68 73 74 83 85
|
||
---+--+--+------------+-----+-----+-+-----------------+-------------+-------------+---+-
|
||
¦ ¦ ¦ Country ¦ ¦ ¦ ¦ Aircraft ¦ Additional ¦ C/S Cert.No.¦ ¦
|
||
¦0 ¦1 ¦ Code ¦0 1 1¦0 1 1¦C¦ 24-bit Address ¦ ELT No.s ¦ or Nat. Use ¦R L¦
|
||
---------------------------------------------------------------------------------------
|
||
Bits
|
||
Usage
|
||
|
||
format flag (= 0)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
user protocol code (=011)
|
||
40-42
|
||
beacon type (=011)
|
||
|
||
flag bit for Cospas-Sarsat type approval certificate number
|
||
44-67
|
||
aircraft 24-bit address
|
||
68-73
|
||
specific ELT number, if several ELTs encoded with the same
|
||
24-bit address are carried in the same aircraft
|
||
74-83
|
||
C/S type approval certificate number or national use
|
||
84-85
|
||
auxiliary radio-locating device type(s)
|
||
Bits 44-67 are a 24-bit binary number assigned to the aircraft. Bits 68-73 contain the 6-bit specific
|
||
ELT number, in binary notation with the least significant bit on the right, which is an order number
|
||
of the ELT in the aircraft, where “000000” indicates the first ELT on the aircraft coded with this
|
||
protocol and “000001”, “000010”, “000011”, etc., identify additional ELTs, all coded with the
|
||
Aircraft 24-bit Address User protocol. The purpose of this specific number is to produce different
|
||
15 Hex numbers containing the same 24-bit address.
|
||
A2.5.3
|
||
Aircraft Operator Designator and Serial Number
|
||
The serial user protocol using the aircraft operator designator and serial number has the following
|
||
structure:
|
||
Bits 25 26 27 36 37 40 44 61 62 73 74 83 85
|
||
---+--+--+------------+-----+-----+-+-------------------+-----------+-------------+---+-
|
||
¦ ¦ ¦ Country ¦ ¦ ¦ ¦ Operator 3-letter ¦ Serial ¦ C/S Cert. No. ¦
|
||
¦0 ¦1 ¦ Code ¦0 1 1¦0 0 1¦C¦ Designator ¦ Number ¦ or Nat. Use ¦R L¦
|
||
---------------------------------------------------------------------------------------
|
||
Bits
|
||
Usage
|
||
|
||
format flag (=0)
|
||
27-36
|
||
country code
|
||
37-39
|
||
user protocol code (=011)
|
||
40-42
|
||
beacon type (=001)
|
||
|
||
flag bit for Cospas-Sarsat type approval certificate number
|
||
44-61
|
||
aircraft operator designator
|
||
|
||
A-12
|
||
|
||
62-73
|
||
serial number assigned by operator
|
||
74-83
|
||
C/S type approval certificate number or national use
|
||
84-85
|
||
auxiliary radio-locating device type(s)
|
||
Bits 44-61 are a 3-letter aircraft operator designator from the list* of "Designators for Aircraft
|
||
Operating Agencies, Aeronautical Authorities and Services" published by the International Civil
|
||
Aviation Organization (ICAO). The 3 letters are encoded using the modified-Baudot code of
|
||
Table A3.
|
||
Bits 62 to 73 are a serial number (in the range of 1 up to 4095) as designated by the aircraft
|
||
operator, encoded in binary notation, with the least significant bit on the right.
|
||
A2.6 Test User Protocol
|
||
The test user protocol will be used for demonstrations, type approval, national tests, training
|
||
exercises, etc. Mission Control Centres (MCCs) will not forward messages coded with this
|
||
protocol unless requested by the authority conducting the test.
|
||
The test user protocol has the following structure:
|
||
Bits
|
||
Usage
|
||
|
||
format flag (short message = 0, long message = 1)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
test user protocol code (=111)
|
||
40-85
|
||
national use
|
||
A2.7 Orbitography Protocol
|
||
The orbitography protocol is for use by special system calibration transmitters and is intended for
|
||
use only by operators of the Local User Terminals. Therefore, it is not further described in this
|
||
document.
|
||
A2.8 National User Protocol
|
||
The national user protocol is a special coding format having certain data fields, indicated as
|
||
"national use", which are defined and controlled by the national administration of the particular
|
||
country which is coded into the country code field.
|
||
* The list of designators, comprising about 3000 operating agencies, authorities or services world-wide, is published by ICAO
|
||
in document 8585, and can be purchased from ICAO in printed and electronic form.
|
||
|
||
A-13
|
||
|
||
The national user protocol may be either a short or a long message, as indicated by the format flag
|
||
(bit 25). The correct BCH code(s) must be encoded in bits 86-106, and in bits 133-144 if a long
|
||
message is transmitted.
|
||
The national user protocol has the following structure:
|
||
Bits 25 26 27 36¦37 ¦40 85 86 106 107 132¦133 144¦
|
||
---+--+--+----------+-----+---------------------------+-------------+-------------¦--------¦
|
||
¦ ¦ ¦ Country ¦ ¦ National Use ¦ BCH Code ¦National Use BCH Code¦
|
||
¦F ¦1 ¦ Code ¦1 0 0¦ (46 bits) ¦ (21 bits) ¦ (26 bits) ¦(12 bits)
|
||
---------------------------------------------------------------------------------¦--------¦
|
||
Bits
|
||
Usage
|
||
|
||
format flag (short message =0, long message =1)
|
||
|
||
protocol flag (=1)
|
||
27-36
|
||
country code
|
||
37-39
|
||
national user protocol code (=100)
|
||
40-85
|
||
national use
|
||
86-106
|
||
21-bit BCH code
|
||
107-112
|
||
national use
|
||
113-132
|
||
national use (if long message)
|
||
133-144
|
||
12-bit BCH code (if long message)
|
||
Once the beacon has been activated, the content of the message in bits 1 to 106 must remain fixed,
|
||
but bits 107 onwards are permitted to be changed periodically, provided the correct 12-bit BCH
|
||
code is also recomputed and that such changes do not occur more frequently than once every
|
||
20 minutes.
|
||
It should be noted that distress alert messages encoded with the national user protocol can be
|
||
passed within the Cospas-Sarsat System only as hexadecimal data, and the content of the message
|
||
can only be interpreted by the appropriate national administration.
|
||
A2.9 Non-Protected Data Field
|
||
The non-protected data field consists of bits 107 to 112, which can be encoded with emergency
|
||
code / national use data as described below. However, when neither the emergency code nor the
|
||
national use data have been implemented, nor such data entered, the following default coding
|
||
should be used for bits 107 to 112:
|
||
000000:
|
||
for beacons that can be activated only manually, i.e.
|
||
bit 108 = 0 (see below)
|
||
010000:
|
||
for beacons that can be activated both manually and automatically, i.e.,
|
||
bit 108 = 1 (see below).
|
||
Bit 107 is a flag bit that should be automatically set to (=1) if emergency code data has been entered
|
||
in bits 109 to 112, as defined below.
|
||
|
||
A-14
|
||
|
||
Bit 108 indicates the method of activation (the switching mechanism) that has been built into the
|
||
beacon:
|
||
bit 108 set to (=0) indicates that a switch must be manually set to “on” after the time of the
|
||
distress to activate the beacon;
|
||
bit 108 set to (=1) indicates that the beacon can be activated either manually or automatically.
|
||
A float-free beacon shall have bit 108 set to 1.
|
||
A2.9.1
|
||
Maritime Emergency code
|
||
The emergency code is an optional feature that may be incorporated in a beacon to permit the user
|
||
to enter data in the emergency code field (bits 109-112) after beacon activation of any maritime
|
||
protocol (i.e. maritime user protocol, maritime serial user protocols, and radio call sign user
|
||
protocol). If data is entered in bits 109 to 112 after activation, then bit 107 should be automatically
|
||
set to (=1) and bits 109 to 112 should be set to an appropriate maritime emergency code shown in
|
||
Table A4. If a beacon is pre-programmed, bits 109 to 112 should be coded as "unspecified distress"
|
||
(i.e. 0000).
|
||
A2.9.2
|
||
Non-Maritime Emergency code
|
||
The emergency code is an optional feature that may be incorporated in a beacon to permit the user
|
||
to enter data in the emergency code field (bits 109-112) of any non-maritime protocol (i.e. aviation
|
||
user protocol, serial user aviation and personal protocols, or other spare protocols). If data is
|
||
entered in bits 109 to 112, then bit 107 should be automatically set to (=1) and bits 109 to 112
|
||
should be set to an appropriate non-maritime emergency code shown in Table A5.
|
||
|
||
A-15
|
||
|
||
Table A4: Maritime Emergency Codes in Accordance with
|
||
the Modified (1) IMO Nature of Distress Indication
|
||
IMO
|
||
Indication(2
|
||
)
|
||
Binary
|
||
Code
|
||
Usage
|
||
|
||
|
||
1001 to 1111
|
||
Fire/explosion
|
||
Flooding
|
||
Collision
|
||
Grounding
|
||
Listing, in danger of capsizing
|
||
Sinking
|
||
Disabled and adrift
|
||
Unspecified distress (3)
|
||
Abandoning ship
|
||
Spare (could be used in future for
|
||
assistance desired or other information to
|
||
facilitate the rescue if necessary)
|
||
(1)
|
||
Modification applies only to code "1111", which is used as a "spare" instead of as the "test"
|
||
code.
|
||
(2)
|
||
IMO indication is an emergency code number, it is different from the binary encoded
|
||
number.
|
||
(3)
|
||
If no emergency code data has been entered, bit 107 remains set to (=0).
|
||
Table A5: Non-Maritime Emergency Codes
|
||
Bits
|
||
Usage (1)
|
||
|
||
|
||
No fire (=0); fire (=1)
|
||
No medical help (=0); medical help required (=1)
|
||
Not disabled (=0); disabled (=1)
|
||
Spare (=0)
|
||
(1) If no emergency code data has been entered, bit 107 remains set to (=0).
|
||
A2.9.3
|
||
National Use
|
||
When bit 107 is set to (=0), codes (0001) through (1111) for bits 109 to 112 may be used for
|
||
national use and should be set in accordance with the protocol of an appropriate national authority.
|
||
|
||
A-16
|
||
|
||
Figure A4: Summary of User Protocols Coding Options
|
||
b 25:
|
||
Message format flag:
|
||
0 = short message, 1 = long message
|
||
b 26:
|
||
Protocol flag:
|
||
1 = User protocols
|
||
b 27 - b 36:
|
||
Country code number:
|
||
3 digits, as listed in Appendix 43 of the ITU Radio Regulations
|
||
b 37 - b 39:
|
||
User protocol code:
|
||
000 = Orbitography
|
||
110 = Radio call sign
|
||
001 = Aviation
|
||
111 = Test
|
||
010 = Maritime
|
||
100 = National
|
||
011 = Serial
|
||
101 = Spare
|
||
b 37 - b 39: 010 = Maritime user
|
||
110 = Radio call sign user
|
||
011 = Serial user
|
||
001 = Aviation user
|
||
100 = National User
|
||
b 40 - b 75:
|
||
Trailing 6 digits of
|
||
MMSI or radio call
|
||
sign
|
||
(modified-
|
||
Baudot)
|
||
b 40 - b 63:
|
||
First four characters
|
||
(modified-Baudot)
|
||
b 40 - 42:
|
||
Beacon type
|
||
000 =
|
||
Aviation
|
||
001 =
|
||
Aircraft Operator
|
||
011 =
|
||
Aircraft Address
|
||
010 =
|
||
Maritime (float free)
|
||
100 =
|
||
Maritime (non float free)
|
||
110 =
|
||
Personal
|
||
b 40 - b 81: Aircraft Registration
|
||
Marking (modified -
|
||
Baudot)
|
||
b 40 - 85:
|
||
National use
|
||
b 43:
|
||
C/S Certificate flag
|
||
b 64 - b 75:
|
||
Last three characters
|
||
(binary coded decimal)
|
||
b 44 - b 73: Serial No. and
|
||
other data
|
||
b 76 - b 81:
|
||
Specific
|
||
beacon
|
||
(modified-Baudot)
|
||
b 76 - b 81:
|
||
Specific
|
||
beacon
|
||
(modified-Baudot)
|
||
b 74 - b 83: C/S Cert. No. or
|
||
National use
|
||
b 82 - b 83:
|
||
00 = Spare
|
||
b 82 - b 83:
|
||
00 = Spare
|
||
b 82 - b 83: Specific ELT number*
|
||
b 84 - 85:
|
||
Auxiliary radio-locating device type(s):
|
||
00 = No Auxiliary radio-locating device
|
||
01 = 121.5 MHz
|
||
10 = Maritime locating: 9 GHz SART
|
||
11 = Other auxiliary radio-locating device(s)
|
||
b 86 - b 106:
|
||
BCH code:
|
||
21-bit error-correcting code for bits 25 to 85
|
||
b 107:
|
||
Emergency code use of b 109 - b 112:
|
||
0 = National use, undefined
|
||
(default = 0)
|
||
1 = Emergency code flag
|
||
b 107 - 112:
|
||
National use
|
||
b 108:
|
||
Activation type:
|
||
0 = Manual activation only
|
||
1 = Automatic and manual activation
|
||
b 109 - b 112:
|
||
Nature of distress:
|
||
Maritime emergency codes (see Table A.4)
|
||
(default = 0000)
|
||
Non-maritime emergency codes (see Table A5) (default = 0000)
|
||
* Effective as of 1 November 2011.
|
||
|
||
A-17
|
||
|
||
A3
|
||
LOCATION PROTOCOLS
|
||
This section defines the protocols which can be used with the 406 MHz beacon message formats for
|
||
encoding beacon position data, as well as the beacon identification data, in the digital message
|
||
transmitted by a 406 MHz distress beacon.
|
||
A3.1 Summary
|
||
Five types of location protocols are defined for use with the long message\*, as shown in Figure A5.
|
||
User-Location Protocols. These location protocols are for use with the long message format.
|
||
The beacon identification data is provided in PDF-1 by one of the user protocols defined in
|
||
section A2 (see Figure A3). Position data is provided as latitude and longitude, to 4-minute
|
||
resolution, encoded into PDF-2.
|
||
Standard Location Protocols. These location protocols are for use with the long message
|
||
format. The beacon identification data is provided in a standardized format in 24 bits of PDF-1.
|
||
Position data to 15-minute resolution is also given in PDF-1, with position offsets to 4-second
|
||
resolution in PDF-2.
|
||
National Location Protocol. This location protocol is for use with the long message format.
|
||
The beacon identification data is provided in a nationally-defined format in 18 bits of PDF-1.
|
||
Position data, to 2-minute resolution, is given in PDF-1, with position offsets to 4-second
|
||
resolution in PDF-2.
|
||
Return Link Service (RLS) Location Protocol†. This location protocol is for use with the
|
||
long message format. The beacon identification data is provided in 26 bits of PDF-1 where the
|
||
first two bits define the beacon type and the remaining 24 bits define the RLS truncated TAC
|
||
number and serial number. Position data, to 30-minute resolution, is given in PDF-1, with
|
||
position offsets to 4-second resolution in PDF-2. PDF-2 also contains six supplementary data
|
||
bits which contain RLS data.
|
||
ELT(DT) Location Protocol‡. This location protocol is for use with the long message format.
|
||
The beacon identification data is provided in 26 bits of PDF-1 where the first two bits define the
|
||
type of beacon identity and the remaining 24 bits provide that identity. Position data to
|
||
30-minute resolution is also given in PDF-1, with position offsets to 4-second resolution in
|
||
PDF-2. PDF-2 also contains six supplementary data bits which contain altitude and other
|
||
ELT(DT) data.
|
||
\*
|
||
Cospas-Sarsat no longer permits the use of short format location protocols. Information on these protocols is
|
||
available in C/S T.001, Issue 3- Revision 7.
|
||
†
|
||
By decision of the Cospas-Sarsat Council at its Fifty-Seventh Session, this protocol will be effective as of 1 January
|
||
2018, as a target, subject to further review and consideration.
|
||
‡
|
||
By decision of the Cospas-Sarsat Council at its Fifty-Seventh Session, this protocol will be effective as of 1 January
|
||
2018, as a target, subject to further review and consideration.
|
||
|
||
A-18
|
||
|
||
A3.2 Default Values in Position Data
|
||
The following default values shall be used in all encoded position data fields of the location protocols,
|
||
when no valid data is available:
|
||
a) all bits in degrees fields set to "1", with N/S, E/W flags set to "0";
|
||
b) all bits in the minutes fields set to "0", with signs set to "1"; and
|
||
c) all bits in the seconds fields set to "1" (the value "1111" = 60 sec is out of range).
|
||
This pattern shall also be transmitted if the beacon radiates a 406 MHz message in the self-test mode.
|
||
Additionally, if a location protocol beacon includes an optional GNSS self-test and this fails to
|
||
provide a valid location to encode into the transmitted self-test message, then the beacon may radiate
|
||
a single self-test message with the above default data. However if a location protocol beacon with
|
||
optional GNSS self-test obtains a location, then the beacon may radiate a single self-test message with
|
||
encoded position.
|
||
Figure A5: Outline of Location Protocols
|
||
U s e r - L o c a t i o n P r o t o c o l s
|
||
bit
|
||
|
||
bits
|
||
27-39
|
||
bits 40-83
|
||
bits
|
||
84-85
|
||
bits 86-106
|
||
bit 107
|
||
bits 108-132
|
||
bits 133-144
|
||
|
||
.......
|
||
Identification Data (44 bits)
|
||
Radio-
|
||
locating
|
||
Device
|
||
21-Bit
|
||
BCH code
|
||
Posit. Data
|
||
Source
|
||
Position Data to 4 min
|
||
Resolution (25 bits)
|
||
12-Bit
|
||
BCH code
|
||
S t a n d a r d L o c a t i o n P r o t o c o l s
|
||
bit
|
||
|
||
bits
|
||
27-40
|
||
bits 41-64
|
||
bits 65-85
|
||
bits 86-106
|
||
bits 107-112
|
||
bits 113-132
|
||
bits 133-144
|
||
|
||
.......
|
||
Identification Data
|
||
(24 bits)
|
||
Position Data to 15 min
|
||
Resolution (21 bits)
|
||
21-Bit
|
||
BCH code
|
||
Supplementary
|
||
Data
|
||
Position Data to 4 sec
|
||
Resolution (20 bits)
|
||
12-Bit
|
||
BCH code
|
||
N a t i o n a l L o c a t i o n P r o t o c o l
|
||
bit
|
||
|
||
bits
|
||
27-40
|
||
bits 41-58
|
||
bits 59-85
|
||
bits 86-106
|
||
bits 107-112
|
||
bits 113-126
|
||
bits
|
||
127-132
|
||
bits 133-144
|
||
|
||
.......
|
||
Identification Data
|
||
(18 bits)
|
||
Position Data to 2 min
|
||
Resolution (27 bits)
|
||
21-Bit
|
||
BCH code
|
||
Supplementary
|
||
Data
|
||
Position Data to 4 sec
|
||
Resolution (14 bits)
|
||
National
|
||
Use
|
||
12-Bit
|
||
BCH code
|
||
E L T ( D T ) a n d R L S L o c a t i o n P r o t o c o l
|
||
bit
|
||
|
||
bits
|
||
27-40
|
||
bits 41-66
|
||
bits 67-85
|
||
bits 86-106
|
||
bits 107-114
|
||
bits 115-132
|
||
bits 133-144
|
||
|
||
.......
|
||
Identification Data
|
||
(26 bits)
|
||
Position Data to 30 min
|
||
Resolution (19 bits)
|
||
21-Bit
|
||
BCH code
|
||
Supplementary
|
||
Data (8 bits)
|
||
Position Data to 4 sec
|
||
Resolution (18 bits)
|
||
12-Bit
|
||
BCH code
|
||
|
||
A-19
|
||
|
||
A3.3 Definition of Location Protocols
|
||
The general structure of location protocols is illustrated in Figure A6.
|
||
A3.3.1
|
||
Position Data\*
|
||
All position information is encoded as degrees, minutes and seconds of latitude or longitude, or as
|
||
fractions of these units. Latitude and longitude data are rounded off (i.e., not truncated) to the available
|
||
resolution. All rounding shall follow normal rounding conventions, for example with a resolution of
|
||
4, 0.000 to 1.999 shall be rounded down to 0 and 2.000 to 3.999 shall be rounded up to 4. In each
|
||
location field the Most Significant Bit (MSB) is the lowest numbered bit in the message which is not
|
||
a N/S, E/W or Δ sign flag bit.
|
||
For User Location Protocols, the position encoded in PDF-2 shall be as close as possible to the actual
|
||
position.
|
||
For Standard Location, National Location, RLS Location, and ELT(DT) Location Protocols the
|
||
position is encoded as follows. The coarse position encoded in PDF-1 is selected to be as close as possible
|
||
to the actual position. The actual position is then rounded following the above rules to the nearest
|
||
4 seconds. The offset to be encoded in PDF-2 is then calculated by subtracting the coarse position encoded
|
||
in PDF-1 from the rounded position, ensuring that the sign of the offset is included in PDF-2†. If there is
|
||
no offset in either latitude or longitude (or both) in PDF-2 (i.e. the offset minutes and seconds are all zeroes)
|
||
then the appropriate offset data flag shall be set to its default value (i.e., 1).
|
||
When a position is encoded in PDF-1, the higher resolution information given in PDF-2 is an offset
|
||
( latitude and longitude) relative to position provided in PDF-1.
|
||
The latitude and longitude values contained in PDF-1 are positive numbers regardless of their
|
||
directions. The offset is applied by adding or subtracting the offset value in accordance with the offset
|
||
sign in PDF-2. For example:
|
||
100° E. longitude + 30 offset = 100° 30 E. longitude
|
||
100° W. longitude + 30 offset = 100° 30 W. longitude (not 99° 30 W. longitude)
|
||
100° W. longitude - 30 offset = 99° 30W. longitude (not 100° 30 W. longitude).
|
||
A3.3.2
|
||
Supplementary Data
|
||
The following supplementary data are provided in location protocols, in addition to the required
|
||
identification data and available position data.
|
||
* Beacons submitted for type approval testing prior to 1 November 2010 may at manufacturers choice use the location
|
||
protocol coding system defined in A3.3.1 or the previous system as defined in section A3.3.1 of document C/S T.001,
|
||
Issue 3 - Revision 8. Manufacturers who choose to use the location encoding system defined in A3.3.1 may use the
|
||
answer sheets in C/S T.007, Issue 3 - Revision 9. Manufacturers who submit for type approval testing after
|
||
1 November 2010 must use the answer sheets in C/S T.007, Issue 3 - Revision 10.
|
||
† Note that the encoded location in PDF-1 will be closest to the actual, but in some cases may not be the closest location
|
||
to the rounded location.
|
||
|
||
A-20
|
||
|
||
A3.3.2.1
|
||
Source of Position Data
|
||
This information is encoded in bit 107 for the user-location protocol and RLS location
|
||
protocol or bit 111 for the standard and national location protocols with the following
|
||
interpretation:
|
||
"0" =
|
||
the encoded position data is provided by an external navigation device
|
||
"1" =
|
||
the encoded position data is provided by an internal navigation device
|
||
A3.3.2.2
|
||
Auxiliary Radio Locating Device (homing transmitter) Code
|
||
The "121.5 MHz homing" data is encoded in bit 112 for the standard and national location
|
||
protocols (short and long versions) and in bit 108 for the RLS location protocol where:
|
||
"1" =
|
||
indicates a 121.5 MHz auxiliary radio locating device
|
||
"0" =
|
||
indicates other or no auxiliary radio locating devices;
|
||
and in bits 84-85 for the user-location protocols as follows:
|
||
"00" =
|
||
no auxiliary radio locating device
|
||
"01" =
|
||
121.5 MHz auxiliary radio locating device
|
||
"10" =
|
||
maritime locating: 9 GHz Search and Rescue Radar Transponder (SART)
|
||
"11" =
|
||
other auxiliary radio-locating device(s).
|
||
A3.3.2.3
|
||
ELT(DT) Activation mechanism
|
||
This information is encoded in bits 107 and 108 for the ELT(DT) Location Protocol as defined in
|
||
section A3.3.8.3.
|
||
A3.3.2.4
|
||
ELT(DT) Altitude above sea level
|
||
This information is encoded in bits 109 to 112 for the ELT(DT) Location Protocol as defined in
|
||
section A3.3.8.3.
|
||
A3.3.2.5
|
||
ELT(DT) Encoded Location Status and PDF-2 rotating field indicator
|
||
This information is encoded in bits 113 and 114 for the ELT(DT) Location Protocol with the
|
||
following interpretation:
|
||
• “00”: PDF-2 rotating field indicator,
|
||
• “01”: encoded location in message is more than 60 seconds old, or the default
|
||
encoded position is transmitted,
|
||
• “10”: encoded location in message is greater than 2 seconds and equal to or
|
||
less than 60 seconds old,
|
||
• “11”: encoded location in message is current (i.e., the encoded location
|
||
freshness is less or equal to 2 seconds).
|
||
|
||
A-21
|
||
|
||
A3.3.2.6
|
||
RLS Data
|
||
Bits 109 and 110 Return Link Message (RLM) Request
|
||
Bits 111 and 112 Beacon Feedback (on receipt of RLM)
|
||
Bits 113 and 114 Return Link Service (RLS) Provider
|
||
A3.3.3
|
||
Test Location Protocols
|
||
The test protocol for all coding methods (i.e. "user" and "location" protocols, except for the ELT(DT)
|
||
and RLS location protocols) is encoded by setting bits 37-39 (protocol code) to "111". In addition, bit
|
||
40 is used to distinguish between the test format of the standard location protocols (bit 40 = "0") and
|
||
national location protocols (bit 40 = "1").
|
||
The ELT(DT) and RLS location protocols both have their own test protocols build into their protocol.
|
||
|
||
A-22
|
||
|
||
Figure A6: General Format of Long Message for Location Protocols
|
||
1
|
||
24→
|
||
|
||
|
||
27
|
||
36→
|
||
37
|
||
39 →
|
||
40 41
|
||
83→
|
||
|
||
|
||
86
|
||
106→
|
||
107
|
||
112 →
|
||
113
|
||
132→
|
||
133
|
||
144→
|
||
-----------
|
||
61 BITS
|
||
----------→
|
||
PDF-1
|
||
BCH-1
|
||
------
|
||
26 BITS
|
||
------→
|
||
PDF-2
|
||
BCH-2
|
||
|
||
|
||
F
|
||
O
|
||
R
|
||
M
|
||
A
|
||
T
|
||
C
|
||
O
|
||
U
|
||
N
|
||
T
|
||
R
|
||
Y
|
||
C
|
||
O
|
||
D
|
||
E
|
||
|
||
|
||
USER-LOCATION PROTOCOLS
|
||
(P=1)
|
||
Identification Data
|
||
(same as User Protocols)
|
||
See Figure A7
|
||
|
||
USER-LOCATION PROTOCOLS
|
||
Latitude / Longitude Data
|
||
(4 Minute Resolution)
|
||
See Figure A7
|
||
BIT & FRAME
|
||
SYNCHRONIZAT.
|
||
PATTERNS
|
||
&
|
||
P
|
||
R
|
||
O
|
||
T
|
||
O
|
||
C
|
||
O
|
||
L
|
||
F
|
||
L
|
||
A
|
||
G
|
||
S
|
||
|
||
|
||
STANDARD LOCATION PROTOCOLS
|
||
(P=0)
|
||
Identification & Position Data
|
||
(1/4 Degree Resolution)
|
||
See Figure A8
|
||
21-BIT BCH ERROR
|
||
CORRECTING CODE
|
||
STANDARD LOCATION PROTOCOLS
|
||
Latitude / Longitude
|
||
(4 Second Resolution)
|
||
+ Supplementary Data
|
||
See Figure A8
|
||
12-BIT BCH ERROR
|
||
CORRECTING
|
||
CODE
|
||
|
||
|
||
NATIONAL LOCATION PROTOCOLS
|
||
(P=0)
|
||
Identification & Position Data
|
||
(2 Minute Resolution)
|
||
See Figure A9
|
||
NATIONAL LOCATION PROTOCOLS
|
||
Latitude / Longitude
|
||
(4 Second Resolution)
|
||
+ Supplementary Data
|
||
See Figure A9
|
||
|
||
|
||
RLS LOCATION PROTOCOLS
|
||
(P=0)
|
||
Identification & Position Data
|
||
(30 Minute Resolution)
|
||
See Figure A10
|
||
RLS LOCATION PROTOCOLS
|
||
Latitude / Longitude
|
||
(4 Second Resolution)
|
||
+ Supplementary Data
|
||
See Figure A10
|
||
|
||
|
||
ELT(DT) LOCATION PROTOCOL
|
||
(P=0)
|
||
Identification & Position Data
|
||
(30 Minute Resolution)
|
||
See Figure A11
|
||
ELT(DT) LOCATION PROTOCOL
|
||
Latitude / Longitude
|
||
(4 Second Resolution)
|
||
+ Supplementary Data
|
||
or Aircraft Operator 3LD
|
||
See Figure A11
|
||
|
||
F= 1 PROTOCOL CODE
|
||
LONG MESSAGE FORMAT - 144 BITS→
|
||
P= 0 or 1 See Table A2
|
||
|
||
A-23
|
||
|
||
A3.3.4
|
||
User-Location Protocols (See Figure A7)
|
||
A3.3.4.1
|
||
These protocols (identified by F=1, P=1) provide for encoding latitude / longitude data
|
||
with resolution to 4 minutes in PDF-2. Beacon identification data shall be encoded in PDF-1 using
|
||
any of the user protocols defined in section 2, except the orbitography protocol and the national
|
||
user protocol which are specific to a particular application or a particular country.
|
||
A3.3.4.2
|
||
The protocol codes (bits 37 to 39) are defined in Table A2-A for user and user-location
|
||
protocols.
|
||
A3.3.4.3
|
||
The 26 bits available in PDF-2 are defined as follows:
|
||
bit 107:
|
||
encoded position data source
|
||
"0" = the encoded position data is provided by an external navigation device
|
||
"1" = the encoded position data is provided by an internal navigation device;
|
||
bits 108 to 119:
|
||
latitude data (12 bits) with 4 minute resolution, including:
|
||
• bit 108:
|
||
N/S flag (N=0, S=1)
|
||
• bits 109 to 115: degrees (0 to 90) in 1 degree increments
|
||
• bits 116 to 119: minutes
|
||
(0
|
||
to
|
||
56)
|
||
in
|
||
|
||
minute
|
||
increments
|
||
(default value of bits 108 to 119 = 0 1111111 0000); and
|
||
bits 120 to 132:
|
||
longitude data (13 bits) with 4 minute resolution including:
|
||
• bit 120: E/W flag (E=0, W=1)
|
||
• bits 121 to 128: degrees (0 to 180) in 1 degree increments
|
||
• bits 129 to 132: minutes
|
||
(0
|
||
to
|
||
56)
|
||
in
|
||
|
||
minute
|
||
increments
|
||
(default value of bits 120 to 132 = 0 11111111 0000).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
A-24
|
||
|
||
Figure A7: User-Location Protocol
|
||
1
|
||
24→
|
||
|
||
|
||
27
|
||
36→
|
||
37 |
|
||
|40
|
||
85→
|
||
39→|
|
||
83→|
|
||
86
|
||
106→
|
||
107
|
||
112→
|
||
113
|
||
132→
|
||
133
|
||
144→
|
||
------
|
||
61 BITS
|
||
-----→
|
||
PDF-1
|
||
BCH-1
|
||
------
|
||
26 BITS
|
||
-----→
|
||
PDF-2
|
||
BCH-2
|
||
|
||
|
||
F
|
||
O
|
||
R
|
||
M
|
||
A
|
||
T
|
||
C
|
||
O
|
||
U
|
||
N
|
||
T
|
||
R
|
||
Y
|
||
P
|
||
R
|
||
O
|
||
T
|
||
O
|
||
C
|
||
O
|
||
IDENTIFICATION DATA
|
||
POSITION DATA
|
||
(ALL USER-LOCATION PROTOCOLS)
|
||
BIT & FRAME
|
||
SYNCHRONIZ.
|
||
PATTERNS
|
||
&
|
||
P
|
||
R
|
||
C
|
||
O
|
||
D
|
||
E
|
||
L
|
||
C
|
||
O
|
||
D
|
||
MARITIME USER PROTOCOL
|
||
(MMSI OR RADIO CALL SIGN)
|
||
(PC=010)
|
||
21-BIT BCH ERROR
|
||
CORRECTING CODE
|
||
|
||
LATITUDE
|
||
LONGITUDE
|
||
12-BIT BCH
|
||
ERROR
|
||
CORRECTING
|
||
CODE
|
||
O
|
||
T
|
||
O
|
||
C
|
||
E
|
||
(PC)
|
||
RADIO CALL SIGN USER PROTOCOL
|
||
(PC=110)
|
||
|
||
|
||
O
|
||
L
|
||
F
|
||
AIRCRAFT NATIONALITY AND
|
||
REGISTRATION MARKINGS
|
||
(PC=001)
|
||
N
|
||
/
|
||
S
|
||
DEG
|
||
0 - 90
|
||
(1 deg.)
|
||
MIN
|
||
0 - 56
|
||
(4min)
|
||
E
|
||
/
|
||
W
|
||
DEG
|
||
0 - 180
|
||
(1 deg.)
|
||
MIN
|
||
0 - 56
|
||
(4min)
|
||
L
|
||
A
|
||
G
|
||
S
|
||
SERIAL USER PROTOCOL
|
||
(ELTs, PLBs, EPIRBs)
|
||
(PC=011)
|
||
TEST USER PROTOCOL
|
||
(PC=111)
|
||
84,85 = Homing 107 = Encoded Position Data source: 1= Internal, 0 = external
|
||
F=1 See See Figure A3 for details (except for the Test User Protocol – see section A2.6)
|
||
P=1 Table A2 of identification data
|
||
|
||
A-25
|
||
|
||
A3.3.5
|
||
Standard Location Protocols (see Figure A8)
|
||
A3.3.5.1
|
||
The standard location protocols, identified by the flags F=1, P=0 and the protocol
|
||
codes no. 1 to 4 of Table A2-B, have the following structure:
|
||
a)
|
||
PDF-1:
|
||
bits 37 to 40:
|
||
4-bit protocol code as defined in Table A2-B
|
||
bits 41 to 64:
|
||
24 bits of identification data
|
||
bits 65 to 85:
|
||
21 bits of encoded position data to 15 minute resolution;
|
||
b)
|
||
PDF-2:
|
||
bits 107 to 112:
|
||
4 fixed bits and 2 bits of supplementary data
|
||
bits 113 to 132
|
||
20-bit position offset ( latitude, longitude), to 4 second
|
||
resolution.
|
||
A3.3.5.2
|
||
The 24 bits of identification data (bits 41 to 64) can be used to encode:
|
||
a) (PC=0010) the last six digits of MMSI in binary form in bits 41 to 60 (20 bits), plus a 4-bit
|
||
specific beacon number (0 to 15) in bits 61 to 64, to distinguish between several EPIRBs
|
||
on the same ship;
|
||
b) (PC=0011) a 24-bit aircraft address (only one ELT per aircraft can be identified using
|
||
this protocol); or
|
||
c) (PC=01xx, see Note 1) a 24-bit unique serial identification including:
|
||
(i)
|
||
the 10-bit Cospas-Sarsat type approval certificate number of the beacon
|
||
(1 to 1,023) in bits 41 to 50, and a 14 bit serial number (1 to 16,383) in bits 51 to 64;
|
||
or
|
||
(ii)
|
||
a 15-bit aircraft operator designator (see Notes 1 & 2) in bits 41 to 55, and a 9-bit
|
||
serial number (1 to 511) assigned by the operator in bits 56 to 64.
|
||
d) (PC=1100) the last six digits of MMSI in binary form in bits 41 to 60 (20 bits), plus
|
||
four spare fixed bits, 61 to 64, set to “0000”.
|
||
________________
|
||
Notes: 1.
|
||
The last two bits of the protocol code (bits 39-40) are used as follows (see also Table A2):
|
||
00 ELT-serial
|
||
10 EPIRB-serial
|
||
01 ELT-aircraft operator designator
|
||
11 PLB-serial
|
||
2.
|
||
The aircraft operator designator (3 letters) can be encoded in 15 bits using a shortened form of the
|
||
modified-Baudot code (i.e.: all letters in the modified-Baudot code are coded in 6 bits, with the
|
||
first bit = "1". This first bit can, therefore, be deleted to form a 5-bit code)
|
||
|
||
A-26
|
||
|
||
A3.3.5.3
|
||
The 21 bits of position data in PDF-1 are encoded as follows:
|
||
a) bits 65 to 74:
|
||
latitude data (10 bits) providing 15 minute resolution, including:
|
||
• bit 65:
|
||
N/S flag (N=0, S=1)
|
||
• bits 66 to 74:
|
||
degrees (0 to 90) in 1/4 degree increments
|
||
(default value of bits 65 to 74 = 0 111111111); and
|
||
b) bits 75 to 85:
|
||
longitude data (11 bits) providing 15 minute resolution, including:
|
||
• bit 75:
|
||
E/W flag (E=0, W=1)
|
||
• bits 76 to 85:
|
||
degrees (0 to 180) in 1/4 degree increments
|
||
(default value of bits 75 to 85 = 0 1111111111).
|
||
A3.3.5.4
|
||
The 26 bits available in PDF-2 are defined as follows:
|
||
a)
|
||
bits 107 to 109:
|
||
="110" (fixed);
|
||
b) bit 110:
|
||
="1" (fixed);
|
||
c)
|
||
bit 111:
|
||
encoded position data source
|
||
"0" = the encoded position data is provided by an external navigation device
|
||
"1" = the encoded position data is provided by an internal navigation device;
|
||
d) bit 112:
|
||
121.5 MHz auxiliary radio locating device included in beacon (1 = yes,
|
||
0 = no); 121.5 MHz auxiliary radio locating devices are not authorised
|
||
for beacons coded with the ship security format
|
||
(i.e. when bits 37 – 40 = 1100);
|
||
e)
|
||
bits 113 to 122:
|
||
latitude with 4 second resolution:
|
||
• bit 113:
|
||
sign (0 = minus, 1 = plus)
|
||
• bits 114 to 118:
|
||
Minutes (0 to 30) in 1 minute increments\*
|
||
• bits 119 to 122:
|
||
Seconds (0 to 56) in 4 second increments
|
||
(default value of bits 113 to 122 = 1 00000 1111); and
|
||
f)
|
||
bits 123 to 132:
|
||
longitude with 4 second resolution:
|
||
• bit 123:
|
||
sign (0 = minus, 1 = plus)
|
||
• bits 124 to 128:
|
||
Minutes (0 to 30) in 1 minute increments\*
|
||
• bits 129 to 132:
|
||
Seconds (0 to 56) in 4 second increments
|
||
(default value of bits 123 to 132 = 1 00000 1111).
|
||
A3.3.5.5
|
||
The test protocol using the above format is encoded by setting bits 37-39 to "111" and
|
||
bit 40 to "0".
|
||
* A3.3.5 defines the coding scheme for all Standard Location Protocols, some newer beacons where the coarse position
|
||
in PDF-1 is always selected to be as close as possible to the actual position will have a maximum offset in PDF-2
|
||
of +/- 7 minutes 30 seconds, in which case bits 114, 115, 124 and 125 of the message will not be used and should be
|
||
permanently set to “0”.
|
||
|
||
A-27
|
||
|
||
Figure A8: Standard Location Protocols
|
||
1
|
||
24→
|
||
|
||
|
||
27
|
||
36→
|
||
37
|
||
40→|41
|
||
85→
|
||
|
|
||
86
|
||
106→
|
||
|
||
|
||
113
|
||
132→
|
||
133
|
||
144→
|
||
-----------
|
||
61 BITS
|
||
------------→
|
||
PDF-1
|
||
BCH-1
|
||
-------
|
||
26 BITS
|
||
--------→
|
||
PDF-2
|
||
BCH-2
|
||
|
||
|
||
F
|
||
O
|
||
R
|
||
PC
|
||
24 BITS
|
||
IDENTIFICATION DATA
|
||
21 BITS
|
||
LATITUDE
|
||
LONGITUDE
|
||
S
|
||
U
|
||
P
|
||
LATITUDE
|
||
LONGITUDE
|
||
M
|
||
A
|
||
C
|
||
O
|
||
|
||
|
||
P
|
||
L
|
||
|
||
|
||
T
|
||
&
|
||
U
|
||
N
|
||
T
|
||
00 10
|
||
MMSI
|
||
(last 6 digits, binary)
|
||
B.No
|
||
0 -15
|
||
LAT
|
||
LON
|
||
E
|
||
M
|
||
E
|
||
M
|
||
I
|
||
S
|
||
E
|
||
M
|
||
I
|
||
S
|
||
E
|
||
BIT & FRAME
|
||
SYNCHRONIZ
|
||
PATTERNS
|
||
P
|
||
R
|
||
R
|
||
Y
|
||
|
||
|
||
AIRCRAFT 24 BIT ADDRESS
|
||
N
|
||
DEG
|
||
E
|
||
DEG
|
||
21-BIT BCH ERROR
|
||
CORRECTING CODE
|
||
N
|
||
T
|
||
A
|
||
R
|
||
-
|
||
+
|
||
N
|
||
U
|
||
T
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
-
|
||
+
|
||
N
|
||
U
|
||
T
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
12-BIT BCH
|
||
ERROR
|
||
CORRECTING
|
||
CODE
|
||
O
|
||
T
|
||
C
|
||
O
|
||
|
||
|
||
S
|
||
0 - 90
|
||
W
|
||
0 - 180
|
||
Y
|
||
S
|
||
S
|
||
S
|
||
S
|
||
O
|
||
C
|
||
O
|
||
D
|
||
E
|
||
01 01 AIRCRAFT OPER.
|
||
DESIGNATOR
|
||
SERIAL No
|
||
1 - 511
|
||
D
|
||
A
|
||
0 - 30
|
||
0-56
|
||
0-30
|
||
0-56
|
||
L
|
||
|
||
|
||
(1/4 d.)
|
||
(1/4 d.)
|
||
T
|
||
A
|
||
(1min) (4s)
|
||
(1min) (4s)
|
||
F
|
||
L
|
||
A
|
||
G
|
||
01 10
|
||
|
||
C/S TA No
|
||
1 – 1023
|
||
SERIAL No
|
||
1 - 16383
|
||
|
||
|
||
11 00
|
||
MMSI
|
||
(last 6 digits, binary)
|
||
Fixed
|
||
|
||
|
||
107 = “1”
|
||
F=1
|
||
0100 ELT-Serial
|
||
108 = “1”
|
||
P=0
|
||
0110 EPIRB-Serial
|
||
109 = “0”
|
||
0111 PLB
|
||
110 = “1”
|
||
111 = Encoded Position Data Source: 1= int., 0 = ext.
|
||
1110 Test
|
||
112 = 121.5 MHz Homing: 1=Yes, 0 = No
|
||
|
||
A-28
|
||
|
||
A3.3.6
|
||
National Location Protocol (see Figure A9)
|
||
A3.3.6.1
|
||
The national location protocol, identified by the flags F=1, P=0 and the protocol codes
|
||
in series no. 4 of Table A2-B, has the following structure:
|
||
a)
|
||
PDF-1:
|
||
bits 37 to 40:
|
||
4-bit protocol code as defined in Table A2-B,
|
||
bits 41 to 58:
|
||
18-bit identification data consisting of a serial number
|
||
assigned by the appropriate national authority,
|
||
bits 59 to 85:
|
||
27 bits of position data to 2 minute resolution;
|
||
b)
|
||
PDF-2:
|
||
bits 107 to 112: 3 fixed bits set to "110", 1-bit additional data flag, describing the
|
||
use of bits 113 to 132, and 2 bits of supplementary data,
|
||
bits 113 to 126: 14-bit position offset ( latitude, longitude) to 4 second
|
||
resolution, or alternate national use, and
|
||
bits 127 to 132: 6 bits reserved for national use (additional beacon type
|
||
identification or other).
|
||
A3.3.6.2
|
||
The 27 bits of position data in PDF-1 are encoded as follows:
|
||
a)
|
||
bits 59 to 71:
|
||
latitude data (13 bits) with 2 minute resolution:
|
||
• bit 59:
|
||
N/S flag (N=0, S=1)
|
||
• bits 60 to 66:
|
||
degrees (0 to 90) in 1 degree increments
|
||
• bits 67 to 71:
|
||
minutes (0 to 58) in 2 minute increments
|
||
(default value of bits 59 to 71 = 0 1111111 00000); and
|
||
b)
|
||
bits 72 to 85:
|
||
longitude data (14 bits) with 2 minute resolution:
|
||
• bit 72:
|
||
E/W flag (E=0, W=1)
|
||
• bits 73 to 80:
|
||
degrees (0 to 180) in 1 degree increments
|
||
• bits 81 to 85:
|
||
minutes (0 to 58) in 2 minute increments
|
||
(default value of bits 72 to 85 = 0 11111111 00000).
|
||
|
||
A-29
|
||
|
||
A3.3.6.3
|
||
The 38 bits available in PDF-2 are defined as follows:
|
||
a)
|
||
bit 107 to 109:
|
||
="110" (fixed);
|
||
b)
|
||
bit 110:
|
||
additional data flag (1 = position data as described below in bits
|
||
113 to 132; 0 = other to be defined nationally);
|
||
c)
|
||
bits 111:
|
||
encoded position data source
|
||
"0" = the encoded position data is provided by an external navigation device
|
||
"1" = the encoded position data is provided by an internal navigation device;
|
||
d)
|
||
bit 112:
|
||
121.5 MHz auxiliary radio locating device included in beacon
|
||
(1 = yes, 0 = no);
|
||
e)
|
||
bits 113 to 119: if bit 110 = 1, latitude with 4 second resolution:
|
||
• bit 113:
|
||
sign (0 = minus, 1 = plus)
|
||
• bits 114 to 115: minutes (0 to 3) in 1 minute increments\*
|
||
• bits 116 to 119: seconds (0 to 56) in 4 second increments
|
||
(default value of bits 113 to 119 = 1 00 1111);
|
||
bits 113 to 119: if bit 110 = 0, national use;
|
||
f)
|
||
bits 120 to 126: if bit 110 = 1, longitude with 4 second resolution:
|
||
• bit 120:
|
||
sign (0 = minus, 1 = plus)
|
||
• bits 121 to 122: minutes (0 to 3) in 1 minute increments\*
|
||
• bits 123 to 126: seconds (0 to 56) in 4 second increments
|
||
(default value of bits 120 to 126 = 1 00 1111);
|
||
bits 120 to 126: if bit 110 = 0, national use; and
|
||
g)
|
||
bits 127 to 132: Additional beacon identification (national use)
|
||
(default value of bits 127 to 132 = 000000).
|
||
A3.3.6.4
|
||
The test protocol using the above format is encoded by setting bits 37-39 to "111" and
|
||
bit 40 to "1".
|
||
* A3.3.6 defines the coding scheme for all National Location Protocols, some newer beacons where the coarse position
|
||
in PDF-1 is always selected to be as close as possible to the actual position will have a maximum offset in PDF-2 of
|
||
+/- 1 minute, in which case bits 114 and 121 of the message will not be used and should be permanently set to “0”.
|
||
|
||
A-30
|
||
|
||
Figure A9: National Location Protocol
|
||
1
|
||
24→
|
||
|
||
|
||
27
|
||
36→
|
||
37
|
||
40→|41
|
||
85→
|
||
|
|
||
86
|
||
106→
|
||
|
||
|
||
113
|
||
132→
|
||
133
|
||
144→
|
||
------
|
||
61 BITS
|
||
-----→
|
||
PDF-1
|
||
BCH-1
|
||
------
|
||
26 BITS
|
||
-----→
|
||
PDF-2
|
||
BCH-2
|
||
|
||
|
||
F
|
||
O
|
||
R
|
||
M
|
||
18 BITS
|
||
IDENTI-
|
||
FICATION
|
||
27 BITS
|
||
LATITUDE
|
||
LONGITUDE
|
||
S
|
||
U
|
||
P
|
||
LATITUDE
|
||
LONGITUDE
|
||
A
|
||
T
|
||
C
|
||
O
|
||
P
|
||
R
|
||
|
||
|
||
P
|
||
L
|
||
|
||
|
||
N
|
||
A
|
||
BIT & FRAME
|
||
SYNCHRONIZ.
|
||
PATTERNS
|
||
&
|
||
P
|
||
R
|
||
O
|
||
T
|
||
O
|
||
C
|
||
O
|
||
L
|
||
F
|
||
L
|
||
A
|
||
G
|
||
U
|
||
N
|
||
T
|
||
R
|
||
Y
|
||
C
|
||
O
|
||
D
|
||
E
|
||
O
|
||
T
|
||
O
|
||
C
|
||
O
|
||
L
|
||
C
|
||
O
|
||
D
|
||
E
|
||
NATIONAL ID
|
||
NUMBER
|
||
N
|
||
S
|
||
D
|
||
E
|
||
G
|
||
R
|
||
E
|
||
E
|
||
S
|
||
0 - 90
|
||
(1 deg)
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0 - 58
|
||
(2 m)
|
||
E
|
||
W
|
||
D
|
||
E
|
||
G
|
||
R
|
||
E
|
||
E
|
||
S
|
||
0 - 180
|
||
(1 deg)
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0 - 58
|
||
(2m)
|
||
21-BIT BCH
|
||
ERROR
|
||
CORRECTING
|
||
CODE
|
||
E
|
||
M
|
||
E
|
||
N
|
||
T
|
||
A
|
||
R
|
||
Y
|
||
D
|
||
A
|
||
T
|
||
A
|
||
-
|
||
+
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0 - 3
|
||
(1m)
|
||
S
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
S
|
||
0 - 56
|
||
(4 s.)
|
||
-
|
||
+
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0 - 3
|
||
(1m)
|
||
S
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
S
|
||
0 - 56
|
||
(4 s.)
|
||
T
|
||
I
|
||
O
|
||
N
|
||
A
|
||
L
|
||
U
|
||
S
|
||
E
|
||
12-BIT BCH
|
||
ERROR
|
||
CORRECTING
|
||
CODE
|
||
107 = “1”
|
||
F=1 See 108 = “1”
|
||
P=0 Table A2 109 = “0”
|
||
1000 ELT 110 = Additional Data Flag: 1 = Position, 0 = Nat. Assignment
|
||
1010 EPIRB 111 = Encoded Position Data Source: 1 = Internal, 0 = external
|
||
1011 PLB 112 = 121.5 MHz Homing: 1= Yes, 0 = No
|
||
1111 Test
|
||
|
||
A-31
|
||
|
||
A3.3.7
|
||
RLS Location Protocol (see Figure A10)
|
||
A3.3.7.1
|
||
The RLS location protocol, identified by the flags F=1, P=0 and the protocol code in
|
||
series no. 7 of Table A2-B, has the following structure:
|
||
a)
|
||
PDF-1:
|
||
bits 37 to 40:
|
||
4-bit protocol code defined as 1101,
|
||
bits 41 to 42:
|
||
2-bit beacon type data set to “00” for ELT, “01” for EPIRB, “10”
|
||
for PLB, and “11” for Location Test Protocol except when bits 43 to
|
||
46 have the value “1111” in which case these bits indicate the
|
||
following; “00” First EPIRB on Vessel, “01” Second EPIRB on
|
||
Vessel, “10” PLB and “11” Location Test Protocol.
|
||
bits 43 to 46:
|
||
Set to “1111” indicate that this is an RLS Location Protocol coded
|
||
with an MMSI, and bits 41 to 42 and bits 47 to 66 have a different
|
||
use as defined above and below
|
||
bits 43 to 46:
|
||
Set to any combination of bits other than “1111” indicate that the RLS
|
||
Location Protocol is coded with either a TAC or National RLS and
|
||
Serial Number
|
||
bits 43 to 52:
|
||
10 bit truncated\*†‡ C/S RLS TAC number or National RLS Number
|
||
except when bits 43 to 46 are set to “1111”,
|
||
* The 10-bit RLS truncated TAC or National RLS number is the last 3 decimal numbers in the TAC number
|
||
data field, which allows a range of 1 to 948.
|
||
The RLS beacon TAC number 949 is reserved for type-approval testing.
|
||
The RLS beacon TAC number or National RLS number series are assigned as follows:
|
||
1000 series is reserved for EPIRBs (i.e. 1001 to 1948),
|
||
2000 series is reserved for ELTs (i.e. 2001 to 2948), and
|
||
3000 series is reserved for PLBs (i.e. 3001 to 3948).
|
||
These are represented in the RLS messages as bits 41 to 42 (except when bits 43 to 46 are set to “1111”)
|
||
indicating the beacon type series (EPIRB, ELT, or PLB) and a 10 bit (1-1024) TAC number which is added to
|
||
the series to encode the full TAC number. (e.g., TAC 1042 would be encoded as “01” for EPIRB in bits 41 to
|
||
42 representing 1nnn, where “nnn” is “042” determined by “0000101010” in bits 43 to 52, and form a binary
|
||
representation “00 0010 1010” of the decimal number “42”.
|
||
† The numbers 920 to 948 (i.e., National RLS Numbers 920 to 948) are set aside for National Use by
|
||
Competent Authorities. That is full National RLS Numbers 1920 to 1948 for EPIRBs, 2920 to 2948 for ELTs,
|
||
and 3920 to 3948 for PLBs.
|
||
‡ The numbers in the ranges x700 to x799 in the 1000, 2000 and 3000 series have been set aside for allocation
|
||
to special-use beacon models approved under letters of compatibility.
|
||
|
||
A-32
|
||
|
||
bits 53 to 66:
|
||
14-bit identification data consisting of a production serial number
|
||
(1 to 16,383) assigned by the manufacturer associated with a
|
||
C/S RLS TAC number (001 to 919), except when bits 43 to 46 are
|
||
set to “1111”,
|
||
or
|
||
bits 53 to 66:
|
||
14-bit identification data consisting of a Competent Authority
|
||
assigned serial number (1 to 16,383), associated with a National
|
||
RLS Number that has been allocated to an Administration by the
|
||
Cospas-Sarsat Programme (920 to 949\*), except when bits 43 to 46
|
||
are set to “1111”,
|
||
bits 47 to 66:
|
||
When bits 43 to 46 are set to “1111” then and only then, do these
|
||
bits provide the last six digits of the MMSI in binary form†
|
||
bits 67 to 85:
|
||
19 bits of position data to 30 minute resolution;
|
||
b)
|
||
PDF-2:
|
||
bits 107 & 108: 2 bits of supplementary data
|
||
bits 109 to 114: 6 bits reserved for RLS Data.
|
||
bits 115 to 132: 18-bit position offset ( latitude, longitude) to 4 second
|
||
resolution.
|
||
The 19 bits of position data in PDF-1 are encoded as follows:
|
||
a)
|
||
bits 67 to 75:
|
||
latitude data (9 bits) with 30 minute resolution, including:
|
||
• bit 67:
|
||
N/S flag (N=0, S=1)
|
||
• bits 68 to 75:
|
||
degrees (0 to 90) in 1/2 degree increments
|
||
(default value of bits 67 to 75 = 0 11111111); and
|
||
b)
|
||
bits 76 to 85:
|
||
longitude data (10 bits) with 30 minute resolution, including:
|
||
• bit 76:
|
||
E/W flag (E=0, W=1)
|
||
• bits 77 to 85:
|
||
degrees (0 to 180) in 1/2 degree increments
|
||
(default value of bits 76 to 85 = 0 111111111).
|
||
* TAC numbers 950 to 959 are currently unallocated.
|
||
† The full 9-digit MMSI is comprised of the Country Code in bits 27 to 36 providing the Flag State (MID) of the vessel
|
||
and bits 47 to 66 providing the unique 6-digit identity for the vessel or a 9-digit MMSI in the form 98MIDXXXX for
|
||
craft associated with a parent vessel with 98M in bits 27 to 36 and "IDXXXX" in bits 47 to 66.
|
||
|
||
A-33
|
||
|
||
A3.3.7.2
|
||
The 26 bits available in PDF-2 are defined as follows:
|
||
a)
|
||
bits 107 and 108
|
||
Supplementary Data
|
||
(1)
|
||
bits 107:
|
||
encoded position data source
|
||
"0" = the encoded position data is provided by an external navigation device
|
||
"1" = the encoded position data is provided by an internal navigation device;
|
||
(2)
|
||
bit 108:
|
||
121.5 MHz auxiliary radio locating device included in beacon
|
||
(1 = yes, 0 = no);
|
||
b)
|
||
bits 109 to 114:
|
||
RLS Data
|
||
(1) Bits 109-110: RLM Request
|
||
• bit 109: Capability to process RLM Type-1:
|
||
"1": Acknowledgement Type-1 (automatic acknowledgement) accepted by this
|
||
beacon,
|
||
"0": Acknowledgement Type-1 not requested and not accepted by this beacon;
|
||
• bit 110: Capability to process manually generated RLM (e.g., Type-2)\*:
|
||
"1": Manually generated RLM (such as Acknowledgement Type-2) accepted by
|
||
this beacon,
|
||
"0": Manually generated RLM (such as Acknowledgement Type-2) not requested
|
||
and not accepted by this beacon.
|
||
(2) Bits 111-112: Beacon feedback (acknowledging the reception of the RLM):
|
||
• bit 111: Feedback on RLM Type-1:
|
||
"1": Acknowledgement Type-1 (automatic acknowledgement) received by this
|
||
beacon,
|
||
"0": Acknowledgement Type-1 not (yet) received by this beacon;
|
||
• bit 112: Feedback on RLM Type-2 (or any other manually generated RLM) :
|
||
"1": RLM Type-2 received by this beacon,
|
||
"0": RLM Type-2 not (yet) received by this beacon.
|
||
(3) Bits 113-114: RLS Provider Identification:
|
||
* The condition bit 109 = “0” and bit 110 = “0” is an invalid condition; at least one of these two bits must always be a
|
||
“1”.
|
||
|
||
A-34
|
||
|
||
"01": GALILEO Return Link Service Provider
|
||
"10": GLONASS Return Link Service Provider\*
|
||
“11”: BDS Return Link Service Provider\*
|
||
"00": Spare (for other RLS providers)
|
||
c)
|
||
bits 115 to 123:
|
||
latitude with 4 second resolution:
|
||
• bit 115:
|
||
sign (0 = minus, 1 = plus)
|
||
• bit 116 to 119:
|
||
minutes (0 to 15) in 1 minute increments†
|
||
• bits 120 to 123: seconds (0 to 56) in 4 second increments
|
||
(default value of bits 115 to 123 = 1 0000 1111);
|
||
d)
|
||
bits 124 to 132:
|
||
longitude with 4 second resolution:
|
||
• bit 124:
|
||
sign (0 = minus, 1 = plus)
|
||
• bits 125 to 128: minutes (0 to 15) in 1 minute increments†
|
||
• bits 129 to 132: seconds (0 to 56) in 4 second increments
|
||
(default value of bits 124 to 132 = 1 0000 1111)
|
||
A3.3.7.3
|
||
Users should utilize the Return Link Service Location Test protocol identified with
|
||
bits 41-42 set to “11” described in section A3.3.7.1 when testing an RLS-capable beacon.
|
||
* Beacons shall not be coded with these coding options (except for the RLS location test protocol) until the GLONASS
|
||
or BDS RLS services are declared by the Cospas-Sarsat Council operational within the Cospas-Sarsat Programme.
|
||
Type approval certificates allowing these versions of RLS Location protocols will not be issued until the RLS service
|
||
provider has been approved for operational use in the System.
|
||
† Section A3.3.7 defines the coding scheme for the RLS Location Protocol. For these new beacons the coarse position
|
||
in PDF-1 is always selected to be as close as possible to the actual position and will have a maximum offset in PDF-
|
||
2 of +/- 15 minutes.
|
||
|
||
A-35
|
||
|
||
Figure A10: RLS Location Protocol
|
||
1
|
||
24→
|
||
|
||
|
||
27
|
||
36→
|
||
37
|
||
40→|41
|
||
85→
|
||
86
|
||
106→
|
||
|
||
|
||
115
|
||
132→
|
||
133
|
||
144→
|
||
61 BITS
|
||
PDF-1
|
||
BCH-1
|
||
26 BITS
|
||
PDF-2
|
||
BCH-2
|
||
|
||
|
||
BIT & FRAME
|
||
SYNCHRONIZ
|
||
.
|
||
PATTERNS
|
||
F
|
||
O
|
||
R
|
||
M
|
||
A
|
||
T
|
||
&
|
||
P
|
||
R
|
||
O
|
||
T
|
||
O
|
||
C
|
||
O
|
||
L
|
||
F
|
||
L
|
||
A
|
||
G
|
||
26 BITS
|
||
IDENTIFICATION
|
||
19 BITS
|
||
LATITUDE
|
||
LONGITUDE
|
||
S
|
||
U
|
||
P
|
||
L
|
||
E
|
||
M
|
||
E
|
||
N
|
||
T
|
||
A
|
||
R
|
||
Y
|
||
D
|
||
A
|
||
T
|
||
A
|
||
LATITUDE
|
||
LONGITUDE
|
||
C
|
||
O
|
||
P
|
||
R
|
||
|
||
|
||
U
|
||
N
|
||
T
|
||
R
|
||
Y
|
||
C
|
||
O
|
||
D
|
||
E
|
||
O
|
||
T
|
||
O
|
||
C
|
||
O
|
||
L
|
||
C
|
||
O
|
||
D
|
||
E
|
||
B
|
||
E
|
||
A
|
||
C
|
||
O
|
||
N
|
||
T
|
||
Y
|
||
P
|
||
E
|
||
RLS
|
||
TAC
|
||
or
|
||
NRN
|
||
or
|
||
RLS
|
||
ID
|
||
S N
|
||
E U
|
||
R M
|
||
I B
|
||
A E
|
||
L R
|
||
or
|
||
N
|
||
S
|
||
D
|
||
E
|
||
G
|
||
R
|
||
E
|
||
E
|
||
S
|
||
0 - 90
|
||
(1/2 deg)
|
||
E
|
||
W
|
||
D
|
||
E
|
||
G
|
||
R
|
||
E
|
||
E
|
||
S
|
||
0 - 180
|
||
(1/2 deg)
|
||
21-BIT BCH
|
||
ERROR
|
||
CORRECTING
|
||
CODE
|
||
-
|
||
+
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0 - 15
|
||
(1m)
|
||
S
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
S
|
||
0 - 56
|
||
(4 s.)
|
||
-
|
||
+
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0 - 15
|
||
(1m)
|
||
S
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
S
|
||
0 - 56
|
||
(4 s.)
|
||
12-BIT BCH ERROR
|
||
CORRECTING
|
||
CODE
|
||
Bits
|
||
43-46
|
||
‘1111’
|
||
Bits
|
||
47-66
|
||
Last 6 digits of
|
||
MMSI
|
||
If bits 43 to 46 = 1111 107 = Encoded Position Data Source: 1 = Internal, 0 = external
|
||
F=1 1101 “00” =ELT “00” First EPIRB 108 = 121.5 MHz Homing: 1= Yes, 0 = No
|
||
P=0 “01”=EPIRB “01” Second EPIRB 109 and 110 = Return Link Message (RLM) Request
|
||
“10”=PLB 111 and 112 = Beacon Feedback (on receipt of RLM)
|
||
“11”=RLS Location Test protocol 113 and 114 = Return Link Service (RLS) Provider
|
||
NRN – National RLS Number (see section A.3.3.7.1)
|
||
|
||
A-36
|
||
|
||
A3.3.8
|
||
ELT(DT) Location Protocol (see Figure A11)
|
||
A3.3.8.1
|
||
The ELT(DT) location protocol, identified by the flags F=1, P=0 and the protocol code in series no. 8
|
||
of Table A2-B, has the following structure:
|
||
a)
|
||
PDF-1:
|
||
bits 37 to 40:
|
||
4-bit protocol code defined as 1001;
|
||
bits 41 to 42:
|
||
2 bits for type of beacon identity set to “00” for Aircraft 24-bit address \*, “01” for
|
||
Aircraft operators designator and serial number†, “10” for TAC with serial
|
||
number†, and “11” reserved for future use;
|
||
bits 43 to 66:
|
||
24 bits of beacon identification data:
|
||
• (Bits 41 and 42 “00”) a 24-bit aircraft address (only one ELT per aircraft can be
|
||
identified using this protocol); or
|
||
• (Bits 41 and 42 “01”) a 15-bit aircraft operator designator‡ in bits 43 to 57, and
|
||
a 9-bit serial number (1 to 511) assigned by the operator in bits 58 to 66; or
|
||
• (Bits 41 and 42 “10”) a 10-bit Cospas-Sarsat type approval certificate number
|
||
of the beacon (1 to 1,023) in bits 43 to 52, and a 14-bit serial number (1 to
|
||
16,383) in bits 53 to 66; or
|
||
• (Bits 41 and 42 “11”) reserved for future use and shall not be used for beacon
|
||
coding.
|
||
or ELT(DT) Location Test protocol when bits 43 to 66 are encoded with either all
|
||
”0”s, or all “1”s;
|
||
* This coding is compliant with the mandatory data elements defined in ICAO document 10150, "Manual on the Functional Specifications
|
||
for the Location of an Aircraft in Distress Repository (LADR)" where bits 41 and 42 are set to “00” and the aircraft 24-bit address is
|
||
provided in PDF-1, and the 3LD designator of the aircraft operator is provided in the rotating PDF-2 field (when bits 113 and 114 are
|
||
set to “00” and bits 115 to 117 are set to “000” at the intervals described in section 2.2.1 of this document).
|
||
The LADR is a facility, that will be used by Cospas-Sarsat, to support ICAO requirements for autonomous location of an aircraft in
|
||
distress contained in Annex 6, Part I, section 6.18 to the Convention on International Civil Aviation.
|
||
† WARNING: These coding options are NOT compliant with the mandatory data elements defined in ICAO document 10150 (no
|
||
aircraft identifier is available) and the associated data cannot be stored in the LADR. Manufacturers wishing to comply with ICAO
|
||
GADSS requirements and use these coding options should first consult the relevant Administration’s aviation authorities for guidance,
|
||
prior to encoding beacons with these protocols.
|
||
‡ The aircraft operator designator (3 letters) can be encoded in 15 bits using a shortened form of the modified-Baudot code (i.e.: since
|
||
all letters in the modified-Baudot code are coded in 6 bits, with the most significant bit = "1", this first (most significant) bit can be
|
||
deleted to form a 5-bit code per letter).
|
||
|
||
A-37
|
||
|
||
bits 67 to 85: 19 bits of position data to 30 minute resolution;
|
||
b)
|
||
PDF-2:
|
||
bits 107 & 108: means of activation
|
||
bits 109 to 112: encoded altitude
|
||
bits 113 & 114
|
||
encoded location freshness or PDF-2 rotating field indicator
|
||
bits 115 to 132:
|
||
18-bit position offset ( latitude, longitude) to 4 second resolution or aircraft
|
||
operator 3LD.
|
||
A3.3.8.2
|
||
The 19 bits of position data in PDF-1 are encoded as follows:
|
||
a)
|
||
bits 67 to 75:
|
||
latitude data (9 bits) with 30 minute resolution, including:
|
||
• bit 67:
|
||
N/S flag (N=0, S=1)
|
||
• bits 68 to 75:
|
||
degrees (0 to 90) in 1/2 degree increments
|
||
(default value of bits 67 to 75 = 0 11111111); and
|
||
b)
|
||
bits 76 to 85:
|
||
longitude data (10 bits) with 30 minute resolution, including:
|
||
• bit 76:
|
||
E/W flag (E=0, W=1)
|
||
• bits 77 to 85:
|
||
degrees (0 to 180) in 1/2 degree increments
|
||
(default value of bits 76 to 85 = 0 111111111).
|
||
A3.3.8.3
|
||
The 26 bits available in PDF-2 are defined as follows:
|
||
a)
|
||
bits 107 and 108: means of activation
|
||
“00”: manual activation by the user
|
||
“01”: automatic activation by the beacon
|
||
“10”: automatic activation by external means
|
||
“11”: spare
|
||
If the beacon receives more than one triggering command, then the most recent triggering event is
|
||
indicated in the bits 107-108.
|
||
b)
|
||
bits 109 to 112: encoded altitude
|
||
“0000”: altitude is less than or equal to 400 m (1312 ft)
|
||
“0001”: altitude is greater than 400 m (1312 ft) up to and including 800 m (2625 ft)
|
||
“0010”: altitude is greater than 800 m (2625 ft) up to and including 1200 m (3937 ft)
|
||
“0011”: altitude is greater than 1200 m (3937 ft) up to and including 1600 m (5249 ft)
|
||
“0100”: altitude is greater than 1600 m (5249 ft) up to and including 2200 m (7218 ft)
|
||
|
||
A-38
|
||
|
||
“0101”: altitude is greater than 2200 m (7218 ft) up to and including 2800 m (9186 ft)
|
||
“0110”: altitude is greater than 2800 m (9186 ft) up to and including 3400 m
|
||
(11155 ft)
|
||
“0111”: altitude is greater than 3400 m (11155 ft) up to and including 4000 m
|
||
(13123 ft)
|
||
“1000”: altitude is greater than 4000 m (13123 ft) up to and including 4800 m
|
||
(15748 ft)
|
||
“1001”: altitude is greater than 4800 m (15748 ft) up to and including 5600 m
|
||
(18373 ft)
|
||
“1010”: altitude is greater than 5600 m (18373 ft) up to and including 6600 m
|
||
(21654 ft)
|
||
“1011”: altitude is greater than 6600 m (21654 ft) up to and including 7600 m
|
||
(24934 ft)
|
||
“1100”: altitude is greater than 7600 m (24934 ft) up to and including 8800 m
|
||
(28871 ft)
|
||
“1101”: altitude is greater than 8800 m (28871 ft) up to and including 10000 m
|
||
(32808 ft)
|
||
“1110”: altitude is greater than 10000 m (32808 ft)
|
||
“1111”: default value if altitude information is not available
|
||
c)
|
||
bits 113 & 114: encoded location freshness or PDF-2 rotating field indicator:
|
||
• “00”: PDF-2 rotating field indicator,
|
||
• “01”: encoded location in message is more than 60 seconds old, or the default encoded
|
||
position is transmitted,
|
||
• “10”: encoded location in message is greater than 2 seconds and equal to or less than
|
||
60 seconds old,
|
||
• “11”: encoded location in message is current (i.e., the encoded location freshness is less than
|
||
or equal to 2 seconds);
|
||
d)
|
||
bits 115 to 123: latitude with 4 second resolution:
|
||
• bit 115:
|
||
sign (0 = minus, 1 = plus)
|
||
• bit 116 to 119:
|
||
minutes (0 to 15) in 1 minute increments\*
|
||
• bits 120 to 123: seconds (0 to 56) in 4 second increments
|
||
(default value of bits 115 to 123 = 1 0000 1111);
|
||
e)
|
||
bits 124 to 132: longitude with 4 second resolution:
|
||
• bit 124:
|
||
sign (0 = minus, 1 = plus)
|
||
• bits 125 to 128: minutes (0 to 15) in 1 minute increments\*
|
||
* Section A3.3.8 defines the coding scheme for the ELT(DT) Location Protocol. For these new beacons the coarse position in PDF-1 is
|
||
always selected to be as close as possible to the actual position and will have a maximum offset in PDF-2 of +/- 15 minutes.
|
||
|
||
A-39
|
||
|
||
• bits 129 to 132: seconds (0 to 56) in 4 second increments
|
||
(default value of bits 124 to 132 = 1 0000 1111)
|
||
OR when bits 113 and 114 are set to “00”;
|
||
f)
|
||
bits 115 to 117: PDF-2 rotating field type
|
||
• 000: aircraft operator 3LD
|
||
• other combinations: spare;
|
||
g)
|
||
bits 118 to 132: when PDF-2 rotating field type is 000, then bits 118 to 132 indicate aircraft
|
||
operator 3LD\*, coded using the Modified Baudot Code in Table A3 (3 letters, each using 5 bits,
|
||
omitting the most significant bit in Table A3; if there is no 3LD for the aircraft operator, then the
|
||
3LD is coded as “ZGA”, i.e., bits 115 to 132 are set to 000 10001 01011 11000).
|
||
A3.3.8.4
|
||
Users should utilize the ELT(DT) Location Test protocol identified with bits 43-66 described in
|
||
section A3.3.8.1 when testing an ELT(DT).
|
||
A3.3.8.5
|
||
Cancellation message
|
||
In case of alert cancellation, a specific message shall be sent with the following bit assignment:
|
||
bits 37 to 40:
|
||
4-bit protocol code as defined as 1001;
|
||
bits 41 to 42:
|
||
2-bits for type of beacon identity;
|
||
bits 43 to 66:
|
||
24 bits of beacon identification data, or ELT(DT) Location Test protocol;
|
||
bits 67 to 75:
|
||
fixed sequence “1 11111010”;
|
||
bits 76 to 85:
|
||
fixed sequence “1 111111010”;
|
||
bits 86 to 106:
|
||
BCH-1;
|
||
bits 107 to 114:
|
||
fixed sequence “00111100”;
|
||
bits 115 to 123:
|
||
fixed sequence “0 1111 0000”;
|
||
bits 124 to 132:
|
||
fixed sequence “0 1111 0000”;
|
||
bits 133 to 144:
|
||
BCH-2.
|
||
\*3LD is a 3-Letter aircraft operator Designator from the list of "Designators for Aircraft Operating Agencies, Aeronautical Authorities
|
||
and Services" published by the International Civil Aviation Organization (ICAO) as document 8585.
|
||
|
||
A-40
|
||
|
||
Figure A11: ELT(DT) Location Protocol
|
||
1
|
||
24→
|
||
|
||
|
||
27
|
||
36→
|
||
37
|
||
40→|41
|
||
85→
|
||
|
|
||
86
|
||
106→
|
||
|
||
|
||
115
|
||
132→
|
||
133
|
||
144→
|
||
-----------
|
||
61 BITS
|
||
------------→
|
||
PDF-1
|
||
BCH-1
|
||
-------
|
||
26 BITS
|
||
--------→
|
||
PDF-2
|
||
BCH-2
|
||
BIT & FRAME
|
||
SYNCHRONIZ.
|
||
PATTERNS
|
||
|
||
|
||
F
|
||
O
|
||
R
|
||
M
|
||
A
|
||
T
|
||
&
|
||
P
|
||
R
|
||
O
|
||
T
|
||
O
|
||
C
|
||
O
|
||
L
|
||
F
|
||
L
|
||
A
|
||
G
|
||
C
|
||
O
|
||
U
|
||
N
|
||
T
|
||
R
|
||
Y
|
||
C
|
||
O
|
||
D
|
||
E
|
||
PC
|
||
26 BITS
|
||
IDENTIFICATION DATA
|
||
19 BITS
|
||
LATITUDE LONGITUDE
|
||
S
|
||
U
|
||
P
|
||
P
|
||
L
|
||
E
|
||
M
|
||
E
|
||
N
|
||
T
|
||
A
|
||
R
|
||
Y
|
||
D
|
||
D
|
||
A
|
||
T
|
||
A
|
||
LATITUDE
|
||
LONGITUDE
|
||
|
||
|
||
type of
|
||
beacon
|
||
identity
|
||
24-bit aircraft address or
|
||
TAC & serial number or
|
||
15-bit aircraft operator
|
||
designator or ELT(DT)
|
||
Location Test protocol
|
||
N
|
||
S
|
||
D
|
||
E
|
||
G
|
||
R
|
||
E
|
||
E
|
||
S
|
||
0 - 90
|
||
(1/2 deg)
|
||
E
|
||
W
|
||
D
|
||
E
|
||
G
|
||
R
|
||
E
|
||
E
|
||
S
|
||
0 - 180
|
||
(1/2 deg)
|
||
21-BIT BCH ERROR
|
||
CORRECTING CODE
|
||
-
|
||
+
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0 - 15
|
||
(1min)
|
||
S
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
S
|
||
0-56
|
||
(4s)
|
||
-
|
||
+
|
||
M
|
||
I
|
||
N
|
||
U
|
||
T
|
||
E
|
||
S
|
||
0-15
|
||
(1min)
|
||
S
|
||
E
|
||
C
|
||
O
|
||
N
|
||
D
|
||
S
|
||
0-56
|
||
(4s)
|
||
12-BIT BCH
|
||
ERROR
|
||
CORRECTING
|
||
CODE
|
||
+
|
||
or rotating field data (e.g., 3LD)
|
||
|
||
Bits 41 and 42 = indication of type of ELT(DT) beacon identity 107-108 = means of activation
|
||
F=1
|
||
109-112 = altitude
|
||
P=0
|
||
113-114 = encoded location freshness or PDF-2 rotating
|
||
field indicator
|
||
CANCELLATION MESSAGE
|
||
26 BITS
|
||
IDENTIFICATION DATA
|
||
FIXED SEQUENCE
|
||
BCH-1
|
||
F
|
||
I
|
||
X
|
||
E
|
||
D
|
||
FIXED SEQUENCE
|
||
BCH-2
|
||
|
||
67 - 75 = “1 1111 1010”
|
||
107 - 114 = “0011 1100”
|
||
F=1
|
||
76 - 85 = “1 1111 1101 0”
|
||
115 - 123 = “0 1111 0000”
|
||
P=0
|
||
124 - 132 = “0 1111 0000”
|
||
|
||
A-41
|
||
|
||
- END OF ANNEX A -
|
||
|
||
B-1
|
||
|
||
ANNEX B
|
||
BCH AND CRC CALCULATIONS
|
||
SAMPLE BOSE-CHAUDHURI-HOCQUENGHEM
|
||
ERROR-CORRECTING CODE CALCULATION
|
||
B1
|
||
SAMPLE 21-BIT BCH CODE CALCULATION
|
||
The error-correcting code used in the first protected field of all 406 MHz messages is a shortened
|
||
form of a (127,106) Bose-Chaudhuri-Hocquenghem (BCH) code. The shortened form (82,61)
|
||
consists of 61 bits of data followed by a 21-bit triple error-correcting code. The code is used to
|
||
detect and correct up to three errors in the entire 82-bit pattern (bits 25 through 106 of the
|
||
406-MHz message).
|
||
Note: For the purpose of error correction, all calculations shall be performed with the full length
|
||
code. Therefore, 45 zeros are placed before the 61 data bits to form the 106 bit pattern of the
|
||
(127,106) BCH code. These padding zeros do not affect the generation of the BCH code as
|
||
described below.
|
||
For the (82,61) BCH code, a generator polynomial g(X) (the same as for (127,106) BCH code) is
|
||
defined as follows:
|
||
g(X) = LCM (m1 (X) , m3 (X) , m5 (X))
|
||
where LCM = Least Common Multiple.
|
||
In the above case:
|
||
m1 (X) = X7 + X3 + 1
|
||
m3 (X) = X7 + X3 + X2 + X + 1
|
||
m5 (X) = X7 + X4 + X3 + X2 + 1
|
||
from which,
|
||
g(X) = m1 (X) m3 (X) m5 (X)
|
||
= X21 + X18 + X17 + X15 + X14 + X12 + X11+ X8 + X7 + X6 + X5 + X + 1
|
||
a determination of g(X) results in the following 22-bit binary number:
|
||
g(X) = 1001101101100111100011
|
||
To generate the BCH code, an information polynomial, m(x) is formed from the 61 data bits as
|
||
follows:
|
||
m(X) = b1 X 60 + b 2 X 59 + .... + b60 X + b61
|
||
where b1 is the first bit (i.e. format flag), and b61 is the last
|
||
bit of PDF-1.
|
||
|
||
B-2
|
||
|
||
m (X) is then extended to 82 bits by filling the least significant bits with 21 "0". The resulting
|
||
82-bit binary string is then divided by g(X) and the remainder, r(X), becomes the BCH code
|
||
(the quotient portion of the result of the module-2 binary division is discarded).
|
||
The above process may be clarified by the following example:
|
||
Message Format
|
||
Short Message
|
||
Protocol Flag
|
||
User Protocol
|
||
Country Code
|
||
366 (USA)
|
||
User Protocol Type
|
||
Serial
|
||
Beacon Type
|
||
Float free EPIRB
|
||
Manufacturer's ID
|
||
|
||
Sequence Number
|
||
|
||
Beacon Model Number
|
||
|
||
Production Run Number
|
||
|
||
National Use Bits
|
||
|
||
Homing
|
||
121.500 MHz
|
||
Emergency/National Use
|
||
Not Used
|
||
Beacon Activation
|
||
Automatic or Manual
|
||
for which:
|
||
Beacon 15 Hex ID: ADCD0 08004 40401 (bits 26-85)
|
||
Short Message:
|
||
56E68 04002 20200 96552 50 (bits 25-112)
|
||
Bits 25-112:
|
||
0101 0110 1110 0110 1000 0000 0100
|
||
0000 0000 0010 0010 0000 0010 0000
|
||
0000 1001 0110 0101 0101 0010 0101
|
||
|
||
The division* described above is shown in Figure B1 and results in a remainder of:
|
||
|
||
The most significant bit position of the remainder will always be a "0" and is deleted to obtain the
|
||
21-bit BCH code:
|
||
BCH Error-Correcting Code: 001011001010101001001
|
||
REFERENCE
|
||
An Introduction to Error Correcting Codes, Shu Lin, Prentice-Hall 1970
|
||
* Modulo 2 division prohibits a "borrow" in the subtraction portion of the long division
|
||
|
||
B-3
|
||
|
||
| | |
|
||
---->|<------------- Bits 25 - 85 ------------------------------>|<---Bits 86-106---->|
|
||
45’0’| (Data bits) | (21 "0"s) |
|
||
m(X)=0101011011100110100000000100000000000010001000000010000000001000000000000000000000
|
||
g(X)= 1001101101100111100011
|
||
|
||
|
||
22-bit remainder = 0001011001010101001001
|
||
| |
|
||
|<------ BCH ------>|
|
||
| (last 21 bits) |
|
||
Figure B1: Sample 21-Bit BCH Error-Correcting Code Calculation
|
||
|
||
B-4
|
||
|
||
B2
|
||
SAMPLE 12-BIT BCH CODE CALCULATION
|
||
The BCH error correcting code (bits 133-144) used in the second protected field of the long
|
||
message is capable of detecting and correcting up to two bit errors in the bits 107-144. The
|
||
generator polynomial used as a basis for this code is:
|
||
g(x) =
|
||
(1 + x + x6) (1 + x + x2 + x4+ x6)
|
||
=
|
||
(1 + x3 + x4 + x5 + x8 + x10 + x12)
|
||
An example of the 12-bit BCH code which protects the 38-bit second protected field (i.e., bits 107
|
||
through 144) is shown below for the user-location protocol. The position in this example is as
|
||
follows:
|
||
actual latitude:
|
||
4333.63' N
|
||
actual longitude:
|
||
001 28.85' E
|
||
latitude rounded to nearest 4' increment:
|
||
4332' N
|
||
longitude rounded to nearest 4' increment:
|
||
00128' E
|
||
binary message:
|
||
- Encoded Position Data Source is Internal
|
||
bit 107:
|
||
|
||
- North latitude
|
||
bit 108:
|
||
|
||
- Latitude 43
|
||
bits 109-115:
|
||
|
||
- Latitude 32'
|
||
bits 116-119:
|
||
|
||
- East longitude
|
||
bit 120:
|
||
|
||
- Longitude 1
|
||
bits 121-128:
|
||
|
||
- Longitude 28'
|
||
bits 129-132:
|
||
|
||
- BCH code
|
||
bits
|
||
133-144: (see Figure B2)
|
||
Placing the binary bits 107-132 in order gives:
|
||
10 0101 0111 0000 0000 0001 0111
|
||
and the BCH code is calculated as shown in Figure B2. The resultant 12-bit BCH code is:
|
||
0001 0101 0001
|
||
|
||
B-5
|
||
|
||
| | |
|
||
---->|<---Bits 107-132------->|<-133-144->|
|
||
25’0’| (Data bits) | (12 "0"s) |
|
||
m(X)=10010101110000000000010111000000000000
|
||
g(X)=1010100111001
|
||
|
||
|
||
13-bit remainder = 0000101010001
|
||
| |
|
||
|<---BCH-->|
|
||
| (12 bits)|
|
||
Figure B2: Sample 12-Bit BCH Error-Correcting Code Calculation
|
||
|
||
B-6
|
||
|
||
B3
|
||
SAMPLE Moffset CALCULATIONS AND CRC-CODE
|
||
FIGURE B3: SAMPLE MOFFSET CALCULATION
|
||
- END OF ANNEX B -
|
||
15 Hex ID: 193BFCE031BFDFF
|
||
CRC-polynomial : x
|
||
16+x
|
||
15+x
|
||
2+1
|
||
CRC-16(193BFCE031BFDFF) = 0xB380
|
||
and Moffset=BIN2DEC(CRC-16(193BFCE031BFDFF)) mod 60 = 52
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
C-1
|
||
|
||
ANNEX C
|
||
EXAMPLES OF RLS GNSS RECEIVER TIMING
|
||
The operation of the RLS GNSS Receiver is defined in section 4.5.7.2 of this document in. A set
|
||
of examples of RLS operation are provided in Table C1, which cover a range of conditions to
|
||
clarify the interpretation of the Moffset timing, and are summarized below:
|
||
1) UTC + Moffset of 59 minutes - No RLM received;
|
||
2) No UTC + Moffset of 1 minute - UTC acquired at 2:34 - RLM received at 4:07;
|
||
3) UTC + Moffset of 17 minutes - No RLM received;
|
||
4) UTC + Moffset of 20 minutes - RLM received at 2:29; and
|
||
5) UTC + Moffset of 11 minutes - RLM received at 0:45.
|
||
These examples are provided to ensure a common understanding of the expected functioning of
|
||
the Moffset capability and are intended to be used as the basis for the development test scenarios.
|
||
The above five examples are believed to cover all of the timing scenarios that can exist, between
|
||
the activation of the RLS GNSS Receiver and various values of Moffset, and specifically cover the
|
||
following situations:
|
||
• UTC acquired soon after beacon activated;
|
||
• UTC not acquired until sometime after the beacon is activated;
|
||
• no RLM received within the 6-hour RLS operational timeframe;
|
||
• GNSS timing changes between the Moffset timing and the regular GNSS receiver timing;
|
||
• correct occurrence of the first Moffset GNSS Receiver timing versus beacon activation
|
||
time; and
|
||
• ideal functioning of the RLS system.
|
||
|
||
C-2
|
||
|
||
Table C1:
|
||
Example Scenarios for RLS GNSS Timing
|
||
Description of GNSS and
|
||
Beacon Operation
|
||
Beacon
|
||
RLM
|
||
Attempt
|
||
Example 1
|
||
Example 2
|
||
UTC + Moffset 59 minutes,
|
||
No RLM received
|
||
No UTC + Moffset 1 minutes,
|
||
UTC acquired at 2:34,
|
||
RLM received at 4:07
|
||
Time at which Beacon
|
||
is Activated
|
||
0:00
|
||
0:17
|
||
Time of first RLM
|
||
Request transmission
|
||
|
||
0:01
|
||
0:18
|
||
GNSS Receiver first
|
||
30 minute on period
|
||
0:30
|
||
0:47\*
|
||
GNSS Receiver next turns on at
|
||
|
||
0:59
|
||
1:02
|
||
GNSS Receiver next turns off at
|
||
1:14
|
||
1:05
|
||
GNSS Receiver next turns on at
|
||
|
||
1:59
|
||
1:17
|
||
GNSS Receiver next turns off at
|
||
2:14
|
||
1:20
|
||
GNSS Receiver next turns on at
|
||
|
||
2:59
|
||
1:32
|
||
GNSS Receiver next turns off at
|
||
3:14
|
||
1:35
|
||
GNSS Receiver next turns on at
|
||
|
||
3:59
|
||
1:47
|
||
GNSS Receiver next turns off at
|
||
4:14
|
||
2:02
|
||
GNSS Receiver next turns on at
|
||
|
||
4:59
|
||
2:32
|
||
GNSS Receiver next turns off at
|
||
5:14
|
||
2:34†
|
||
GNSS Receiver next turns on at
|
||
|
||
5:59
|
||
3:01
|
||
GNSS Receiver next turns off at
|
||
6:00‡
|
||
3:16
|
||
GNSS Receiver next turns on at
|
||
|
||
4:01
|
||
GNSS Receiver next turns off at
|
||
4:07§
|
||
GNSS Receiver reverts to non-
|
||
RLS operation
|
||
6:00
|
||
4:07
|
||
Note that interleaved with the GNSS Receiver timings, the GNSS receiver also turns on in
|
||
accordance with section 4.5.5.4, as well in Examples 1, 3 and 4, but these GNSS 'on' periods are
|
||
omitted for clarity in the tables.
|
||
* Timing reverts to schedule per document C/S T.001, section 4.5.5.4.
|
||
† UTC acquired, back to RLS schedule
|
||
‡ Last ‘on’ period, 1-minute duration, as 6 hours have elapsed from beacon turn-on.
|
||
§ With no UTC reference, receiver reverts to document C/S T.001, section 4.5.5.4 timing, until UTC is obtained.
|
||
|
||
C-3
|
||
|
||
Table C1 (Continued): Example Scenarios for RLS GNSS Timing
|
||
Description of GNSS and
|
||
Beacon Operation
|
||
Beacon
|
||
RLM
|
||
Attempt
|
||
Example 3
|
||
Example 4
|
||
Example 5
|
||
UTC + Moffset
|
||
17 minutes,
|
||
No RLM received
|
||
UTC + Moffset
|
||
20 minutes,
|
||
RLM received at
|
||
2:29
|
||
UTC + Moffset
|
||
11 minutes,
|
||
RLM received at
|
||
0:45
|
||
Time at which Beacon
|
||
is Activated
|
||
0:58
|
||
0:14
|
||
0:40
|
||
Time of first RLM
|
||
Request transmission
|
||
|
||
0:59
|
||
0:15
|
||
0:41
|
||
GNSS Receiver first
|
||
30 minute on period
|
||
1:28
|
||
0:44
|
||
0:45\*
|
||
GNSS Receiver next turns on at
|
||
|
||
2:17
|
||
1:20
|
||
GNSS Receiver next turns off at
|
||
2:32
|
||
1:35
|
||
GNSS Receiver next turns on at
|
||
|
||
3:17
|
||
2:20
|
||
GNSS Receiver next turns off at
|
||
3:32
|
||
2:29†
|
||
GNSS Receiver next turns on at
|
||
|
||
4:17
|
||
GNSS Receiver next turns off at
|
||
4:32
|
||
GNSS Receiver next turns on at
|
||
|
||
5:17
|
||
GNSS Receiver next turns off at
|
||
5:32
|
||
GNSS Receiver next turns on at
|
||
|
||
6:17
|
||
GNSS Receiver next turns off at
|
||
6:32
|
||
GNSS Receiver next turns on at
|
||
|
||
‡
|
||
GNSS Receiver next turns off at
|
||
GNSS Receiver reverts to
|
||
non-RLS operation
|
||
6:32
|
||
2:29
|
||
0:45
|
||
- END OF ANNEX C-
|
||
* GNSS only ‘on’ for 4 min until RLM received, Moffset never needed.
|
||
† GNSS only ‘on’ for 9 min, until RLM received.
|
||
‡ 6 hours up at 6:58, so no seventh attempt is initiated for this case.
|
||
|
||
D-1
|
||
|
||
ANNEX D
|
||
RLS INFORMATION
|
||
Example of Information to be Included in the User Manual of an RLS-Capable Beacon
|
||
This beacon has the Return Link Service (RLS) feature. The RLS feature is an indication on the
|
||
beacon that confirms to the beacon user that the distress signal from an activated beacon has been
|
||
localised by the Cospas-Sarsat system and is being sent to the responsible search-and-rescue (SAR)
|
||
authorities. It does NOT mean that a search and rescue has yet been organized/launched, but only
|
||
confirms that the distress alert has been received by the Cospas-Sarsat System and is being routed
|
||
to the appropriate SAR agencies.
|
||
The RLS is designed to send an acknowledgment to the beacon user in less than 30 minutes from
|
||
beacon activation (actual acknowledgement times are typically much quicker). Alerting of the
|
||
distress to SAR authorities is independent of (and may occur before) the RLS acknowledgment
|
||
indication on the beacon. The RLS specification is described in the Galileo SAR Service Definition
|
||
Document:
|
||
(https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-SAR-SDD.pdf).
|
||
RLS is an optional function and may not be permitted in all countries or for all beacon types. You
|
||
may visit the web page Where Can I Buy an RLS-Enabled Beacon?
|
||
(https://cospas-sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase) to learn the most
|
||
recent information about national support for RLS.
|
||
Cospas-Sarsat strongly recommends that you appropriately register your beacon. It only is possible
|
||
to register a beacon in the registry operated by the country matching the “country code”
|
||
electronically programmed into the beacon (or the International Beacon Registration Database
|
||
(IBRD) (https://www.406registration.com/) if the country uses the IBRD for their registrations).
|
||
For example, it only is possible to register a beacon with a French country code in France’s national
|
||
registry. However, owners of Belgian-coded beacons must register in the IBRD. The country code
|
||
is encoded in the beacon’s unique identification number (UIN, also called Hex ID), which is used
|
||
to
|
||
register
|
||
the
|
||
beacon.
|
||
Visit
|
||
the
|
||
web
|
||
page
|
||
Beacon
|
||
Registration
|
||
Contacts
|
||
(https://www.406registration.com/countriessupported.aspx) to see where you can register your
|
||
beacon.
|
||
- END OF ANNEX D -
|
||
- END OF DOCUMENT-
|
||
|
||
Cospas-Sarsat Secretariat
|
||
1250 René-Lévesque Blvd. West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada
|
||
Telephone: +1 514 500 7999
|
||
Fax: +1 514 500 7996
|
||
Email: mail@406.org
|
||
Website: http://www.406.org |