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.
5044 lines
205 KiB
Markdown
5044 lines
205 KiB
Markdown
---
|
||
title: "T018: C/S T.018 - Issue 1 Rev.13"
|
||
description: "Official Cospas-Sarsat T-series document T018"
|
||
sidebar:
|
||
badge:
|
||
text: "T"
|
||
variant: "note"
|
||
# Extended Cospas-Sarsat metadata
|
||
documentId: "T018"
|
||
series: "T"
|
||
seriesName: "Technical"
|
||
documentType: "specification"
|
||
isLatest: true
|
||
issue: 1
|
||
revision: 13
|
||
documentDate: "October 2025"
|
||
originalTitle: "C/S T.018 - Issue 1 Rev.13"
|
||
---
|
||
|
||
> **📋 Document Information**
|
||
>
|
||
> **Series:** T-Series (Technical)
|
||
> **Version:** Issue 1 - Revision 13
|
||
> **Date:** October 2025
|
||
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)
|
||
|
||
---
|
||
|
||
SPECIFICATION FOR
|
||
SECOND-GENERATION COSPAS-SARSAT
|
||
406-MHz DISTRESS BEACONS
|
||
C/S T.018
|
||
Issue 1 – Revision 13
|
||
|
||
|
||
|
||
|
||
SPECIFICATION FOR SECOND-GENERATION COSPAS-SARSAT
|
||
406-MHz DISTRESS BEACONS
|
||
History
|
||
Issue
|
||
Revision
|
||
Date
|
||
Comments
|
||
|
||
|
||
Approved by CSC-57
|
||
|
||
|
||
Approved by CSC-58
|
||
|
||
|
||
Approved by CSC-59
|
||
|
||
|
||
Approved by CSC-60
|
||
|
||
|
||
Approved by CSC-61
|
||
|
||
|
||
Approved by CSC-62
|
||
|
||
|
||
Approved by CSC-63
|
||
|
||
|
||
Approved by CSC-64
|
||
|
||
|
||
Approved by CSC-65
|
||
|
||
|
||
Approved by CSC-66
|
||
|
||
|
||
Approved by CSC-67
|
||
|
||
|
||
Approved by CSC-69
|
||
|
||
|
||
Approved by CSC-71
|
||
|
||
|
||
Approved by CSC-73
|
||
|
||
|
||
TABLE OF CONTENTS
|
||
Page
|
||
History ....................................................................................................................................................... i
|
||
Table of Contents ...................................................................................................................................... ii
|
||
List of Figures
|
||
..................................................................................................................................... iv
|
||
List of Tables
|
||
..................................................................................................................................... iv
|
||
1.
|
||
Introduction ............................................................................................................1-1
|
||
1.1
|
||
Purpose ....................................................................................................................... 1-1
|
||
1.2
|
||
Scope .......................................................................................................................... 1-1
|
||
1.3
|
||
Type of Beacon .......................................................................................................... 1-2
|
||
1.4
|
||
Optional Features ....................................................................................................... 1-3
|
||
1.5
|
||
Additional Features .................................................................................................... 1-4
|
||
2.
|
||
Technical Requirements ........................................................................................2-1
|
||
2.1
|
||
Beacon Functional Elements ...................................................................................... 2-1
|
||
2.1.1
|
||
Transmitter Notional Functional Block Diagram ..........................................2-1
|
||
2.2
|
||
Digital Message Generator ......................................................................................... 2-2
|
||
2.2.1
|
||
Burst Transmission Interval ...........................................................................2-2
|
||
2.2.2
|
||
Total Transmission Time ...............................................................................2-4
|
||
2.2.3
|
||
Direct Sequence Spread Spectrum .................................................................2-4
|
||
2.2.4
|
||
Preamble ........................................................................................................2-6
|
||
2.2.5
|
||
Digital Message .............................................................................................2-6
|
||
2.2.6
|
||
Message Content ............................................................................................2-6
|
||
2.2.7
|
||
In-Phase (I) and Quadrature-Phase (Q) Components ....................................2-7
|
||
2.3
|
||
Modulator and 406 MHz Transmitter ........................................................................ 2-9
|
||
2.3.1
|
||
Transmitted Frequency ..................................................................................2-9
|
||
2.3.2
|
||
Spurious Emissions ......................................................................................2-10
|
||
2.3.3
|
||
Modulation and Waveform ..........................................................................2-10
|
||
2.3.4
|
||
Voltage Standing-Wave Ratio .....................................................................2-11
|
||
2.3.5
|
||
Maximum Continuous Transmission ...........................................................2-11
|
||
2.4
|
||
Transmitter Power Output ........................................................................................ 2-11
|
||
2.4.1
|
||
Transmitter Rise Time .................................................................................2-11
|
||
2.4.2
|
||
Effective Isotropic Radiated Power (EIRP) .................................................2-11
|
||
2.4.3
|
||
Antenna Characteristics ...............................................................................2-12
|
||
2.5
|
||
406 MHz Homing Transmitter ................................................................................. 2-14
|
||
3.
|
||
DIGITAL MESSAGE CONTENT .......................................................................3-1
|
||
3.1
|
||
Basic Structure ............................................................................................................ 3-1
|
||
3.2
|
||
Beacon Message Content – Main Field ...................................................................... 3-1
|
||
3.3
|
||
Beacon Message Content – Rotating Fields ............................................................... 3-7
|
||
|
||
|
||
3.4
|
||
Beacon Transmission Scheduling of Rotating Fields ............................................... 3-16
|
||
3.5
|
||
Beacon Message Content – Error Correcting Field .................................................. 3-17
|
||
3.6
|
||
Beacon Coding and Hex ID ...................................................................................... 3-18
|
||
3.7
|
||
Programming Adapters............................................................................................. 3-19
|
||
4.
|
||
ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS ...................4-1
|
||
4.1 General ....................................................................................................................... 4-1
|
||
4.2
|
||
Thermal Environment................................................................................................. 4-1
|
||
4.2.1
|
||
Operating Temperature Range .......................................................................4-1
|
||
4.2.2
|
||
Temperature Gradient ....................................................................................4-1
|
||
4.2.3
|
||
Thermal Shock ...............................................................................................4-1
|
||
4.3
|
||
Mechanical Environment ........................................................................................... 4-2
|
||
4.4
|
||
Other Environmental Requirements ........................................................................... 4-3
|
||
4.5
|
||
Operational Requirements .......................................................................................... 4-3
|
||
4.5.1
|
||
Duration of Continuous Operation ................................................................4-3
|
||
4.5.2
|
||
Other Operational Requirements ...................................................................4-3
|
||
4.5.3
|
||
Radio-Locating Signal (for Homing and on-Scene Locating) .......................4-3
|
||
4.5.4
|
||
Beacon Self-Test Mode .................................................................................4-4
|
||
4.5.5
|
||
Encoded Position Data ...................................................................................4-6
|
||
4.5.6
|
||
Beacon Activation........................................................................................4-12
|
||
4.5.7
|
||
Beacon Activation Cancellation Function ...................................................4-14
|
||
4.5.8
|
||
Verification of Registration .........................................................................4-15
|
||
4.5.9
|
||
RLS Functions .............................................................................................4-15
|
||
4.5.10 Battery Status Indication ..............................................................................4-18
|
||
4.5.11 Beacon Labelling .........................................................................................4-19
|
||
4.5.12 Beacon Instruction Manual ..........................................................................4-19
|
||
4.5.13 Beacon Data Requirements ..........................................................................4-19
|
||
4.5.14 External Power Source for ELT(DT)s .........................................................4-19
|
||
4.5.15 ELT(DT)s Specifically Designed to Withstand a Crash Impact ..................4-20
|
||
4.5.16 ELT(DT)s Combined with Automatic ELTs ...............................................4-22
|
||
4.5.17 RLS Type 3 TWC (message) Functionality ................................................4-24
|
||
APPENDIX A - LIST OF ACRONYMS........................................................................................ A-1
|
||
APPENDIX B - SAMPLE BOSE-CHAUDHURI-HOCQUENGHEM ERROR-
|
||
CORRECTING CODE AND 23 HEX ID CALCULATIONs ........................... B-1
|
||
B.1
|
||
Sample 48-Bit BCH Code Calculation ...................................................................... B-1
|
||
B.2
|
||
Sample 23 Hex ID Calculation .................................................................................. B-6
|
||
APPENDIX C - BEACON ENCODED LOCATION CODING ................................................... C-1
|
||
C.1
|
||
ENCODED LOCATION PROTOCOL .................................................................... C-1
|
||
C.2
|
||
Summary ................................................................................................................... C-1
|
||
C.3
|
||
Default Values in Position Data ................................................................................ C-1
|
||
C.4
|
||
Definition of Location Data Fields ............................................................................ C-2
|
||
|
||
|
||
C.4.1
|
||
Encoded Location field ................................................................................. C-2
|
||
C.4.2
|
||
Encoded Location Data (1) ............................................................................ C-2
|
||
C.5
|
||
Instructions for converting Latitudes and Longitudes to a Binary Number .............. C-3
|
||
APPENDIX D - EXAMPLE OF LINEAR FEEDBACK SHIFT REGISTER (LFSR)
|
||
IMPLEMENTATION ........................................................................................... D-1
|
||
APPENDIX E - BIT ASSIGNMENT NUMBERS ........................................................................ E-1
|
||
APPENDIX F - MOFFSET CALCULATIONS AND CRC CODE SAMPLE ................................ F-1
|
||
APPENDIX G - EXAMPLES OF RLS GNSS RECEIVER TIMING ....................................... G-1
|
||
APPENDIX H - RLS INFORMATION ........................................................................................ H-1
|
||
APPENDIX I - BASIC BEACON PROGRAMMING GUIDANCE ............................................ I-1
|
||
LIST OF FIGURES
|
||
Figure 2-1: Notional DSSS-OQPKS Transmitter Functional Block Diagram .....................................2-2
|
||
Figure 2-2: Linear Feedback Shift Register ..........................................................................................2-5
|
||
Figure 2-3: Burst general structure .......................................................................................................2-7
|
||
Figure 2-4: I and Q Component Message Structure .............................................................................2-8
|
||
Figure 2-5: Spurious emission mask ...................................................................................................2-10
|
||
Figure 2-6: OQPSK modulation illustration .......................................................................................2-11
|
||
Figure 2-7: Ideal Antenna Pattern .......................................................................................................2-12
|
||
Figure 3-1: Message content bits ..........................................................................................................3-1
|
||
Figure 4-1: Temperature Gradient ........................................................................................................4-2
|
||
Figure 4-2: RF\#4 bit assignment representation with the FLAM in the case where the bit 14 (Answer
|
||
Format Flag) is 0 (Short) ............................................................................................4-29
|
||
Figure 4-3: RF\#4 bit assignment representation with the FLAM in the case where the bit 14 (Answer
|
||
Format Flag) is 1 (Long) ............................................................................................4-29
|
||
Figure B-1: Sample 48-Bit BCH Error-Correcting Code Calculation ................................................. B-5
|
||
Figure D-1: Example of LSFR with the generation of the 64 first chips of the normal I-component . D-2
|
||
Figure F-1: Example of calculation of Moffset ....................................................................................... F-1
|
||
|
||
|
||
LIST OF TABLES
|
||
Table 2.1: Transmission Schedule ........................................................................................................2-4
|
||
Table 2.2: PRN Sequence Initialization Values ....................................................................................2-6
|
||
Table 2.3: Logic to Signal Level Assignment .......................................................................................2-6
|
||
Table 2.4: Bit to PRN Sequence Assignment .......................................................................................2-9
|
||
Table 2.5: Required EIRP ...................................................................................................................2-12
|
||
Table 3.1: Minimum Requirement main field in the beacon message (transmitted in every burst) ....3-2
|
||
Table 3.2: Modified Baudot Code.........................................................................................................3-7
|
||
Table 3.3: C/S G.008 Objective Requirements Rotating Field (\#0) .....................................................3-8
|
||
Table 3.4: ELT(DT) In-Flight Emergency Rotating Field (\#1) ..........................................................3-10
|
||
Table 3.5: RLS Type 1 Automatic and Type 2 Manual Acknowledgment Rotating Field (\#2) .........3-11
|
||
Table 3.6: National Use Rotating Field (\#3) .......................................................................................3-12
|
||
Table 3.7: RLS Type 3 TWC (Message) Rotating Field (\#4) .............................................................3-13
|
||
Table 3.8: Spare Rotating Fields (for future use) (#5 - #14) ...............................................................3-15
|
||
Table 3.9: Cancellation Message Rotating Field (\#15) .......................................................................3-15
|
||
Table 3.10: Rotating Field Transmission Conditions .........................................................................3-16
|
||
Table 3.11: Hex ID Contents ..............................................................................................................3-18
|
||
Table 4.1: Expected Stand-alone ELT(DT) Behaviour ......................................................................4-12
|
||
Table 4.2: Expected Crash Survivable ELT(DT) Behaviour ..............................................................4-20
|
||
Table 4.3: Expected ELT(DT) Combined with Automatic ELT Behaviour .......................................4-22
|
||
|
||
1-1
|
||
|
||
1.
|
||
INTRODUCTION
|
||
1.1
|
||
Purpose
|
||
The purpose of this document is to define the minimum requirements to be used for the development and
|
||
manufacture of Second Generation 406 MHz Emergency Locator Transmitters (ELTs), Emergency
|
||
Position-Indicating Radio Beacons (EPIRBs), and Personal Locator Beacons (PLBs). In this document,
|
||
the term ELT indicates an aviation distress beacon, an EPIRB a maritime distress beacon, and a PLB a
|
||
distress beacon for personal use.
|
||
Specifications that are critical to the Cospas-Sarsat System are defined in detail. Specifications which
|
||
could be developed by the national authorities are identified in more general terms.
|
||
1.2
|
||
Scope
|
||
This document contains the minimum requirements that apply to Cospas-Sarsat 406 MHz distress
|
||
beacons. It is divided into the following sections:
|
||
a) Section 2 gives the technical requirements applicable to all types of beacons. When met,
|
||
these requirements will enable the beacons to provide the intended service in terms of
|
||
location probability and accuracy and will not disturb the system operation.
|
||
b) Section 3 deals with the beacon message content. Basic message structure as well as the
|
||
assignment and meaning of the available data bits are defined in this section.
|
||
c) Section 4 defines a set of environmental and operational requirements. These
|
||
requirements are not intended to be exhaustive and may be complemented by more
|
||
detailed national or international standards (e.g., RTCA standards for ELTs). However,
|
||
they represent the minimum environmental and operational performance requirements
|
||
for a 406 MHz beacon to be compatible with the Cospas-Sarsat System.
|
||
d) Appendix A provides a list of acronyms used in this document.
|
||
e) Appendix B provides a sample Bose-Chaudhuri-Hocquenghem error-correcting code
|
||
calculation.
|
||
f) Appendix C provides an example of beacon encoded location coding.
|
||
g) Appendix D provides an example of the first 64 bits of a Linear Feedback Shift Register
|
||
(LFSR) Implementation.
|
||
h) Appendix E provides a map of the BIT assignment numbers.
|
||
i) Appendix F provides an Moffset calculation and CRC code sample.
|
||
|
||
1-2
|
||
|
||
1.3
|
||
Type of Beacon
|
||
There are four different types of Cospas-Sarsat 406 MHz beacons; Emergency Locator Transmitters
|
||
(ELTs), Emergency Position Indicating Radio Beacons (EPIRBs), Personal Locator Beacons (PLBs) and
|
||
Ship Security Alert System (SSAS) Beacons. This standard does not address requirements for Second
|
||
Generation SSAS Beacons.
|
||
In addition to the four different types of beacon there are up to three Classes of operating temperature
|
||
range for 406 MHz beacons as follows:
|
||
Class 0:
|
||
-55°C to +70°C
|
||
Class 1:
|
||
-40°C to +55°C
|
||
Class 2:
|
||
-20°C to +55°C
|
||
Any type of beacon can be supplied with a Class 0, Class 1 or Class 2 operating temperature range.
|
||
Unless otherwise stated herein this specification applies to all types and classes of 406 MHz beacons
|
||
identified in this section apart from SSAS beacons.
|
||
Emergency Locator Transmitters (ELTs)
|
||
Are designed for aviation distress purposes and are available as the following types; Automatic Fixed
|
||
(ELT (AF)), Automatic Portable (ELT (AP)), Survival (ELT (S)), Automatic Deployable (ELT (AD)),
|
||
and Distress Tracking ELT (ELT (DT)).
|
||
Automatic Fixed (ELT (AF))
|
||
This type of ELT is intended to be permanently attached to the aircraft before and after a crash and is
|
||
designed to aid SAR teams in locating a crash site.
|
||
Automatic Portable (ELT (AP))
|
||
This type of ELT is intended to be rigidly attached to the aircraft before a crash, but readily removable
|
||
from the aircraft after a crash. It functions as an ELT (AF) during the crash sequence. If the ELT does
|
||
not employ an integral antenna, the aircraft-mounted antenna may be disconnected and an auxiliary
|
||
antenna connected in its place. This type of ELT is intended to aid SAR teams in locating the crash site
|
||
or survivor(s).
|
||
Survival (ELT (S))
|
||
This type of ELT is intended to survive the crash forces, and then to be generally manually activated
|
||
by survivors. There are two sub categories of ELT(S) Category A which is buoyant and designed to
|
||
operate when floating in water and Category B which is non buoyant and may be manually or
|
||
automatically activated. This type of ELT is intended to aid SAR teams in locating survivor(s).
|
||
|
||
1-3
|
||
|
||
Automatic Deployable (ELT(AD))
|
||
This type of ELT is intended to be rigidly attached to the aircraft before a crash and automatically
|
||
deployed after the crash sensor has determined that a crash has occurred. This type of ELT should float
|
||
in water and is intended to aid SAR teams in locating the crash site.
|
||
Distress Tracking (ELT (DT))
|
||
This is a specific type of ELT designed to be activated prior to a crash and to function in compliance
|
||
with the ICAO GADSS* requirements for the Location of an Aeroplane in Distress, aimed at
|
||
establishing, to a reasonable extent, the location of an accident site within a 6 NM radius. It may be
|
||
activated automatically upon detection of a distress condition while in-flight or it may also be activated
|
||
manually.
|
||
Emergency Position Indicating Radio Beacons (EPIRBs)
|
||
Are designed for maritime distress purposes and are available as Float free and Non Float Free types of
|
||
EPIRB.
|
||
Float Free EPIRB
|
||
This type of EPIRB is intended to float free of the vessel on which it is fitted if the vessel sinks, in which
|
||
case it will automatically activate, it can also be manually activated.
|
||
Non Float Free EPIRB
|
||
This type of EPIRB is intended to be manually released from its mounting bracket and then either
|
||
manually activated or dropped in the water so that it will then activate automatically. Some national
|
||
administrations permit the use of manually activated EPIRBs only without the automatic activation in
|
||
water feature.
|
||
Personal Locator Beacons (PLBs)
|
||
Are designed for use by persons in distress who may be on land, in the air or at sea.
|
||
1.4
|
||
Optional Features
|
||
Beacons may contain optional features that are defined in this specification.
|
||
Encoded location capability is optional, however in the case of ELT (DT) devices intended for in-flight
|
||
automatic activation the inclusion of a GNSS capability is mandatory.
|
||
All types of beacons (except current ELT(DT)s) may also be provided with the Return Link Service
|
||
capabilities (e.g., RLS Type 1 automatic acknowledgement and/or RLS Type 3 two-way communication
|
||
(message) service capability).
|
||
All types of beacons may be provided with one or more additional radio-locating transmitters for Homing
|
||
and On-scene Locating purposes.
|
||
* See ICAO Convention on International Civil Aviation Annex 6, Part 1.
|
||
|
||
1-4
|
||
|
||
1.5
|
||
Additional Features
|
||
Beacons may contain additional functionality that may change the transmitted 406 MHz satellite
|
||
signal or affect other beacon parameters such as operating lifetime. For example, a beacon may
|
||
contain a flashing strobe light that while it probably has no effect on the transmitted signal, would reduce
|
||
the battery life.
|
||
Any additional functionality that is not defined in this specification shall not adversely degrade the
|
||
performance of the beacon to the extent that it no longer complies with this specification.
|
||
- END OF SECTION 1 -
|
||
|
||
2-1
|
||
|
||
2.
|
||
TECHNICAL REQUIREMENTS
|
||
2.1
|
||
Beacon Functional Elements
|
||
This section defines requirements for the functional elements of spread-spectrum 406 MHz distress
|
||
beacons.
|
||
2.1.1
|
||
Transmitter Notional Functional Block Diagram
|
||
This section contains a notional functional diagram which describes the features which are described
|
||
in greater detail by later sections of this document.
|
||
Figure 2-1 illustrates a notional Direct Sequence Spread Spectrum - Offset QPSK (DSSS-OQPSK)
|
||
high level transmitter functional block diagram which may be used to better understand one possible
|
||
implementation of the beacon signal design. In this figure:
|
||
•
|
||
D(t) is the linear bit stream for each beacon burst running at 300 bits/second.
|
||
•
|
||
D(t) is split into parallel bit streams Ib(t) and Qb(t) made up of odd and even bits from D(t)
|
||
running at 150 bps each
|
||
•
|
||
A Linear Feedback Shift Register (LFSR) function produces the two different chipping
|
||
segments Ci(t) and Cq(t) using the common generator polynomial G(X). Each chipping
|
||
segment runs at 38,400 chips/second. Each of Ci(t) and Cq(t) is produced by the LFSR
|
||
function using the specified unique I or Q channel LFSR initialization, and is reproduced
|
||
identically for each beacon burst for a given beacon mode of operation.
|
||
•
|
||
Ib(t) and Qb(t) are separately mixed with their respective different chipping segments. The
|
||
resultant on each channel can change state every chip period.
|
||
•
|
||
The resultant of the mixing on the Q component is then delayed by ½ chip period.
|
||
•
|
||
Both I and Q channels may then be low pass filtered (if necessary) and modulated onto
|
||
cosine and sine sinusoids.
|
||
•
|
||
The two modulated sinusoids are then summed.
|
||
•
|
||
The summation resultant is amplified, band pass filtered (if necessary), and then
|
||
transmitted as the outgoing beacon burst signal S(t).
|
||
Because the I and Q resultants are offset by ½ chip period from each other, when summed, the
|
||
resulting signal S(t) is bounded to a maximum phase shift of 90 degrees to help minimize amplitude
|
||
envelope variation.
|
||
|
||
2-2
|
||
|
||
Figure 2-1: Notional DSSS-OQPKS Transmitter Functional Block Diagram
|
||
2.2
|
||
Digital Message Generator
|
||
The digital message generator will key the modulator and transmitter so that the message defined
|
||
in section 3 is transmitted. This section describes the structure of the proposed signal.
|
||
2.2.1
|
||
Burst Transmission Interval
|
||
From beacon activation a total of 6 initial transmissions shall be made separated by fixed\*
|
||
5s +0 /-0.2s intervals. The first transmission shall commence within 5 seconds of beacon activation†,
|
||
except for EPIRBs, where it shall commence within 8 seconds of beacon activation.
|
||
The beacon shall then transmit 59 bursts at nominally 30 second intervals. The time between the start
|
||
of two successive transmissions (TR) shall be randomized with uniform (flat) distribution around the
|
||
stated nominal value, so that intervals between the start of two successive transmissions are randomly
|
||
distributed over ± 5 seconds. The standard deviation over the 59 successive bursts of TR shall be
|
||
greater than 2.5 seconds. The minimum value of TR observed over the 59 successive bursts shall be
|
||
* In this context, “fixed” refers to a repetition period which may vary within the tolerances allocated, and that no
|
||
deliberate randomization within this range is required.
|
||
† Beacon activation is defined as the point in time at which the initiation of the activation event of the beacon occurs.
|
||
E.g., the activation events include pressing of the “ON” button, water sensor immersion, the start of a shock, or
|
||
deformation.
|
||
|
||
|
||
|
||
2-3
|
||
|
||
between 25.0 and 25.2 seconds, the maximum value of TR observed over the 59 successive bursts
|
||
shall be between 34.8 and 35.0 seconds.
|
||
Transmissions shall then occur at nominally 120 second intervals. The time between the start of two
|
||
successive transmissions (TR) shall be randomized with uniform (flat) distribution around the stated
|
||
nominal value, so that intervals between the start of two successive transmissions are randomly
|
||
distributed over ± 5 seconds. The standard deviation over the first 50 successive bursts of TR shall be
|
||
greater than 2.5 seconds. The minimum value of TR observed over the 50 successive bursts shall be
|
||
between 115.0 and 115.2 seconds, the maximum value of TR observed over the 50 successive bursts
|
||
shall be between 124.8 and 125.0 seconds.
|
||
For ELT DT transmission the first transmission shall commence within 5 seconds of beacon
|
||
activation. From beacon activation a total of 24 initial transmissions shall be made separated by fixed\*
|
||
5 seconds + 0.0 / - 0.2 intervals. These transmissions shall be followed by 18 transmissions separated
|
||
by fixed 10 seconds + 0.0 / - 0.2. After the first 42 transmissions, ELT (DT) transmissions shall
|
||
continue at nominal intervals of 28.5 seconds until the end of the ELT (DT) operating lifetime. The
|
||
time between the start of two successive transmissions (TR) shall be randomized with uniform (flat)
|
||
distribution around the stated nominal value, so that intervals between the start of two successive
|
||
transmissions are randomly distributed over ± 1.5 seconds. The standard deviation over the first 73
|
||
successive bursts of TR shall be greater than 0.8 seconds. The minimum value of TR observed over
|
||
the 73 successive bursts shall be between 27.0 and 27.2 seconds, the maximum value of TR observed
|
||
over the 73 successive bursts shall be between 29.8 and 30.0 seconds.
|
||
For RLS Type 3 two-way communication (TWC) (message) capable beacons, from beacon
|
||
activation a total of 6 initial transmissions shall be made separated by fixed 5s +0 /-0.2s intervals.
|
||
The first transmission shall commence within 5 seconds of beacon activation, except for EPIRBs,
|
||
where it shall commence within 8 seconds of beacon activation.
|
||
The beacons with RLS Type 3 TWC functionality shall then transmit 119 bursts at nominally 30
|
||
second intervals. The time between the start of two successive transmissions shall be randomized
|
||
with uniform distribution around the stated nominal value, so that intervals between the start of
|
||
two successive transmissions are randomly distributed over ± 5 seconds.
|
||
Transmissions shall then occur at nominally 120 second intervals. The time between the start of
|
||
two successive transmissions (TR) shall be randomized with uniform (flat) distribution around
|
||
the stated nominal value, so that intervals between the start of two successive transmissions are
|
||
randomly distributed over ± 5 seconds.
|
||
The transmission schedule is summarized in Table 2.1.
|
||
* In this context, “fixed” refers to a repetition period which may vary within the tolerances allocated, and that no
|
||
deliberate randomization within this range is required.
|
||
|
||
2-4
|
||
|
||
Table 2.1: Transmission Schedule
|
||
IAMSAR Stage
|
||
Nominal Time from
|
||
Activation
|
||
Transmission Nominal
|
||
Repetition Interval
|
||
Randomization
|
||
Initial
|
||
0 to 30* Seconds
|
||
5 Seconds
|
||
|
||
Action / Planning
|
||
30* Seconds to
|
||
30 minutes
|
||
30 Seconds
|
||
± 5 Seconds
|
||
30 minutes +
|
||
120 Seconds
|
||
± 5 Seconds
|
||
ELT (DT)
|
||
0 to 120 Seconds
|
||
5 Seconds
|
||
|
||
120 to 300 Seconds
|
||
10 Seconds
|
||
|
||
300 Seconds +
|
||
28.5 Seconds
|
||
± 1.5 Seconds
|
||
RLS Type 3 Two-
|
||
Way
|
||
Communication
|
||
(Message) service
|
||
0 to 30* Seconds
|
||
5 Seconds
|
||
|
||
30* Seconds to
|
||
60 minutes
|
||
30 Seconds
|
||
± 5 Seconds
|
||
60 minutes +
|
||
120 Seconds
|
||
± 5 Seconds
|
||
2.2.2
|
||
Total Transmission Time
|
||
The total transmission time of each burst, measured at the 90 percent power points, shall be 1000 ms
|
||
±1 ms.
|
||
2.2.3
|
||
Direct Sequence Spread Spectrum
|
||
The digital message shall be spread using two truncated segments of a common PRN (Pseudo-
|
||
Random Noise) maximum length sequence (m-sequence) producing symbols known as "chips".
|
||
These sequence segments shall be deterministic and must be known by the receiver.
|
||
The two truncated spreading PRN segments shall:
|
||
a) be applied separately to the full duration of each beacon burst transmission with one
|
||
segment applied to the in-phase (I) component and the other applied to the quadrature (Q)
|
||
component of the signal;
|
||
b) be transmitted as separate odd and even bits, starting with 1 as the first bit. Odd bits are
|
||
transmitted through the I channel and even bits the Q channel. For each bit, 256 chips are
|
||
taken from the PRN sequence such that a 0 bit is represented by the non-inverted sequence
|
||
and a 1 by the inverted sequence, equivalent to an exclusive-OR operation (XOR). The I
|
||
and Q signal components are spread separately, each by a factor of 256 (with half-chip
|
||
offset as shown in section 2.3.3). Then when the I and Q channels are combined the overall
|
||
spreading factor is 128 chips/bit.
|
||
c) be generated by a method equivalent to a Linear Feedback Shift Register (LFSR) using
|
||
the same generator polynomial G(x) = X23 + X18 +1 (see Figure 2-2);
|
||
d) be generated in matched pairs for the I and Q components defined in Table 2.2 for each
|
||
beacon mode;
|
||
* For EPIRBs this value is 33 seconds.
|
||
|
||
2-5
|
||
|
||
e) be truncated to the first 38,400 chips of the m-sequence generated using the prescribed
|
||
initialization values for each of the I and Q components with a 1/2 chip period delay
|
||
imposed on the Q component relative to the I component (refer to section 2.3.3);
|
||
f)
|
||
be applied to both I and Q components for the full one second duration of each beacon
|
||
burst transmission including preamble, information bits, and error correction bits, to give
|
||
a chipping rate of 38,400 chips/second for each component (see 2.3.1.2 for further details);
|
||
and
|
||
g) be identical for each beacon burst transmission for any given burst mode.
|
||
Note that this spreading scheme method in fact allows for multiple possible non-overlapping matched
|
||
I and Q component chipping segment pairs, with each segment in each pair truncated to 38,400 chips.
|
||
The number of possible segments, 218, is determined by dividing the full m-sequence length for the
|
||
generator polynomial, by the truncated segment length, ((223)-1)/38,400 = 218 segments.
|
||
Non-overlapping pairs of segments can be selected from this set of 218 segments.
|
||
X22
|
||
X21
|
||
X17
|
||
X20
|
||
X19
|
||
X18
|
||
X16
|
||
...
|
||
X1
|
||
X0
|
||
+
|
||
+
|
||
Data in
|
||
Linear Feedback Shift Register for X23+X18+1:
|
||
(1) X0 Ꚛ data output
|
||
(2) X0 Ꚛ X18→ temp
|
||
(3) Shift Xn→ Xn-1 Ɐ n
|
||
(4) temp→ X22
|
||
Figure 2-2: Linear Feedback Shift Register
|
||
The beacon shall be able to generate multiple PRN sequences segments, such as normal mode and
|
||
self-test mode, according to Table 2.2. In order to generate these PRN sequences segments, the
|
||
beacon may use a LFSR with multiple initialization values for PRN sequence segment generation.
|
||
Table 2.2 provides the generator polynomial initialization LFSR values for I and Q components for
|
||
beacon normal mode operation and for beacon self-test mode operation. In this table, registers are
|
||
labelled from 0 to 22. The registers shift from left to right the output from register 0. For clarity, the
|
||
feedback taps to be XOR’d are indicated in the table and match with the characteristic polynomial. The
|
||
output chip is taken from register 0. The table also provides the first 64 chips in the order of generation
|
||
from the LFSR. The 64 chip binary sequence has been displayed in hexadecimal format as
|
||
demonstrated in the example below the table with the leftmost chip in sequence being the first output.
|
||
The LFSR implementation (with associated initialization) leads to the correct generation of the whole
|
||
38 400 chips sequence, which can be verified to a high degree of confidence by confirming a perfect
|
||
match of the first 64 chips given in Table 2.2.
|
||
|
||
2-6
|
||
|
||
Table 2.2: PRN Sequence Initialization Values
|
||
Register
|
||
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||
XOR
|
||
|
||
1 Output chip sequence
|
||
Register Initial Setting
|
||
1st
|
||
64th
|
||
Normal I
|
||
|
||
|
||
0 0 0 0 0 0 0 0 0 0 1 → 8000
|
||
|
||
4212 84A1
|
||
Normal Q
|
||
|
||
|
||
0 0 1 1 1 1 1 1 1 0 0 →
|
||
3F83 58BA D030 F231
|
||
Self Test I
|
||
|
||
|
||
0 0 1 1 1 1 1 0 0 0 0 →
|
||
0F93 4A4D 4CF3 028D
|
||
Self Test Q
|
||
|
||
|
||
0 0 1 0 0 1 0 1 0 0 0 → 1497 3DC7 16CD E124
|
||
An example of the generation of the 64 first chips of the normal I-component is given in Appendix D.
|
||
The correspondence between the logic level of the chips used to modulate the signal and the signal
|
||
level is given in Table 2.3:
|
||
Table 2.3: Logic to Signal Level Assignment
|
||
Logic Level
|
||
Signal Level
|
||
|
||
-1.0
|
||
|
||
+1.0
|
||
2.2.4
|
||
Preamble
|
||
The initial 166.7 ms of the transmitted signal shall consist of the combination of the first 6400 chips
|
||
of the two PRN code segments (each segment 38,400 chips long for the entire burst) used to spread
|
||
the I and Q message components as illustrated in Figure 2-3. There will be no useful information
|
||
encoded on either the I or Q components during the preamble. I and Q component information bits
|
||
shall all be set to ‘0’ during the preamble.
|
||
2.2.5
|
||
Digital Message
|
||
The remaining 833.3 ms of the transmitted signal shall contain a 250-bit message and will be at a
|
||
nominal bit rate of 300 bps.
|
||
2.2.6
|
||
Message Content
|
||
The content of the 250 bit message is defined in section 3.
|
||
The 250 bit message is composed of two parts:
|
||
a) the useful message: 202 bits containing the information transmitted by the beacon.
|
||
b) the error correction bits: 48 bits BCH(250,202) containing bits used for error correction
|
||
at reception.
|
||
|
||
2-7
|
||
|
||
Preamble
|
||
Correcting bits
|
||
Useful message
|
||
166.7 ms
|
||
673.3 ms
|
||
160 ms
|
||
1s
|
||
Figure 2-3: Burst general structure
|
||
2.2.7
|
||
In-Phase (I) and Quadrature-Phase (Q) Components
|
||
The odd bits of the 250-bit message are used to generate the in-phase (I) component of the message,
|
||
while the even bits are used to generate the quadrature-phase (Q) component of the message. The bit
|
||
rate for each channel will nominally be 150 bits/sec.
|
||
Each component starts with a 6400 chip preamble described in section 2.2.4 and is spread with the
|
||
PRN code segment described in section 2.2.3 as shown in Figure 2-4.
|
||
|
||
2-8
|
||
|
||
Figure 2-4: I and Q Component Message Structure\*
|
||
* The 50 bits included in the preamble contain no data and are set to “0”
|
||
|
||
|
||
|
||
2-9
|
||
|
||
The preamble and any bits allocated as ‘0’ are represented by the PRN sequence, and bits allocated
|
||
as ‘1’ are sent as the PRN sequence inverted for the duration of the bit as shown in Table 2.4. This is
|
||
the method of modulating data onto the PRN sequence.
|
||
Table 2.4: Bit to PRN Sequence Assignment
|
||
Bit
|
||
PRN Sequence
|
||
|
||
Inverted
|
||
|
||
Normal
|
||
2.3
|
||
Modulator and 406 MHz Transmitter
|
||
2.3.1
|
||
Transmitted Frequency
|
||
The following sections define the frequency stability requirements for the Carrier Frequency and the
|
||
Chip Rate. The specifications for the carrier frequency and the chip rate may be decoupled by using
|
||
separate oscillators.
|
||
2.3.1.1
|
||
Carrier Frequency Offset/Drift over aging, thermal, shock and vibration
|
||
a) Long Term Stability Requirement
|
||
The carrier frequency tolerance shall be 406.05 MHz ±1200 Hz over 5 years or the
|
||
manufacturers’ declared beacon maintenance period\*, whichever is greater; and
|
||
b) Short Term Stability Requirement
|
||
This requirement applies throughout the operating temperature range and during
|
||
situations of temperature shock.
|
||
The maximum allowable carrier frequency variation shall be 7.4 ppb when measured
|
||
over 166.7 msec within the burst.
|
||
2.3.1.2
|
||
Chip Rate Accuracy and Variation
|
||
The average chip rate shall be 38 400 ± 0.6 chips/s.
|
||
The variation of the chip rate shall be ± 0.6 chips/s².
|
||
These values shall be met both when measuring over the preamble and on the entire burst.
|
||
* The beacon maintenance should include validation of the frequency stability of the beacon.
|
||
|
||
2-10
|
||
|
||
2.3.2
|
||
Spurious Emissions
|
||
The in-band spurious emissions shall not exceed the levels specified by the signal mask in Figure 2-5,
|
||
when measured in a 100 Hz resolution bandwidth.
|
||
Figure 2-5: Spurious emission mask
|
||
Furthermore, out of band emissions must be limited to less than 1% of the total transmitted power\*.
|
||
2.3.3
|
||
Modulation and Waveform
|
||
The RF modulation is Offset Quadrature Phase Shift Keying (OQPSK). The PRN sequences for the
|
||
in-phase (I) and quadrature (Q) components of the signal are defined in section 2.2.3. The chips of
|
||
the I and Q components shall have an average offset of half a chip period ± 1% of the chip period
|
||
over the entire burst with I leading Q by one-half a chip period. In the constellation diagram shown
|
||
below, it can be seen that this will limit the phase-change to no more than 90° at a time. The peak to
|
||
peak amplitude of the I and Q components shall be on average within 15% of each other over the
|
||
entire burst. The Error Vector Magnitude (EVM) of the constellation points away from ideal,
|
||
measured at symbol level, shall be less than 2.5 % when measured over the entire burst.
|
||
Acceptable types of filters that may be used to produce an output waveform include half-sine (i.e.,
|
||
IEEE 802.15.4, Section 12.2.6), or root-raised cosine ([0.8 +/- TBD] roll-off factor may be used). If
|
||
other output filters are being considered for use, the Cospas-Sarsat Secretariat must be consulted in
|
||
advance so that they can consult with the Parties regarding the filter’s acceptability.
|
||
The figure below illustrates the OQPSK modulation mid-burst including the one-half chip delay on
|
||
the Q channel. In this figure, T represents the chip period.
|
||
* The 1% out of band emission is extracted from the recommendation ITU-R SM.1541-4, article 1.153
|
||
|
||
|
||
|
||
2-11
|
||
|
||
In-Phase
|
||
Component
|
||
(I)
|
||
Quadrature
|
||
Component
|
||
(Q)
|
||
T
|
||
T/2
|
||
Figure 2-6: OQPSK modulation illustration
|
||
2.3.4
|
||
Voltage Standing-Wave Ratio
|
||
The modulator and 406 MHz transmitter shall be able to meet all requirements within this standard
|
||
at any VSWR between 1:1 and 3:1, and shall not be damaged by any load from open circuit to short
|
||
circuit.
|
||
2.3.5
|
||
Maximum Continuous Transmission
|
||
The distress beacon shall be designed to limit any inadvertent continuous 406 MHz transmission to a
|
||
maximum of 45 seconds.
|
||
2.4
|
||
Transmitter Power Output
|
||
2.4.1
|
||
Transmitter Rise Time
|
||
The transmitter RF output power shall not exceed -10 dBm prior to 25 ms before the commencement
|
||
of, or 25 ms after the end of, any 406 MHz burst. Power output rise time shall be less than 0.5 ms
|
||
measured between the 10% and 90% power points. Preamble content shall be transmitted during the
|
||
power rise time. Power output fall time shall be less than 0.5 ms between the 90% and the 10% power
|
||
points.
|
||
Between 25 ms after the end of any 406 MHz burst until 25 ms before the commencement of the next
|
||
406 MHz burst the power level in the 406.0 to 406.1 MHz frequency band shall not exceed -10 dBm.
|
||
2.4.2
|
||
Effective Isotropic Radiated Power (EIRP)
|
||
Power output is defined in terms of EIRP, not power into a 50-ohm load. Required EIRP varies with
|
||
elevation angle according to the table below. Greater than 65% of measured EIRP values shall meet
|
||
the limits shown. In addition, 90% of the measured EIRP values shall meet the limits shown at
|
||
|
||
2-12
|
||
|
||
elevation angles below 55 degrees, except for ELT(DT)s, or ELTs used in combination with
|
||
automatic deployable flight recorders.
|
||
Table 2.5: Required EIRP
|
||
Elevation
|
||
(°)
|
||
|
||
|
||
Max dBm 45
|
||
|
||
|
||
Min dBm
|
||
|
||
|
||
The horizontal (azimuth) antenna pattern should be substantially omnidirectional and shall remain
|
||
within the minimum and maximum values of EIRP provided in the above table.
|
||
Power output shall be maintained within the above limits throughout the minimum operating lifetime
|
||
of the beacon at any temperature throughout the operating temperature range. Changes in beacon
|
||
output power due to for example temperature and operation over the beacons minimum lifetime when
|
||
operating into a 50-ohm test load shall be taken into account during determination of compliance with
|
||
the minimum and maximum EIRP limits.
|
||
2.4.3
|
||
Antenna Characteristics
|
||
Antenna polarization shall be either circular (RHCP) or linear. Antenna pattern should be
|
||
hemispherical and should include coverage at high elevation angles, subject to the EIRP limits given
|
||
in section 2.4.2 (effective isotropic radiated power). An ideal antenna pattern is shown below for
|
||
illustration purposes.
|
||
Remote antennas or detachable antennas shall always be approved with a beacon.
|
||
The following different types of antenna may be specified for use with a 406 MHz beacon:
|
||
External Antenna
|
||
An antenna that is external to the casing of the beacon and that is permanently attached to the beacon
|
||
and that cannot be removed by the user.
|
||
|
||
|
||
Example
|
||
antenna
|
||
min
|
||
max
|
||
Figure 2-7: Ideal Antenna Pattern
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
2-13
|
||
|
||
Detachable Antenna
|
||
An antenna that is external to the casing of the beacon and that is attached directly to the beacon by
|
||
such means as an RF connector without any intermediate cable which can be removed and replaced
|
||
by the user.
|
||
Detachable antennas when measured directly at the antenna feed point shall achieve a VSWR not
|
||
greater than 1.5:1 referred to 50Ω.
|
||
Internal Antenna
|
||
An antenna that is contained within the case of the beacon where the user has no access to the antenna.
|
||
Remote Antenna
|
||
An antenna that is external to the casing of the beacon and which is remote from the beacon, being
|
||
attached to it by means of an RF cable. The antenna and the RF cable may be permanently attached
|
||
to the beacon (in this case the type and length of the antenna cable is fixed and is as supplied by the
|
||
beacon manufacturer) or one or both parts (antenna or cable) may be varied by the user or the installer
|
||
(in this case the type and length of the antenna cable may vary).
|
||
In either case, remote antennas, when measured directly at the antenna feed point, shall achieve a
|
||
VSWR not greater than 1.5:1 referred to 50Ω.
|
||
Remote Antenna without an Integrated Cable
|
||
In this configuration (e.g., an ELT installed in an aircraft) there may be more than one type of
|
||
approved antenna and the length and type of cable between the antenna and beacon may vary.
|
||
The characteristic impedance and minimum and maximum loss of the antenna feed cable shall be
|
||
specified by the beacon manufacturer. The combined beacon, antenna and cable shall meet the EIRP
|
||
requirements in section 2.4.2 (effective isotropic radiated power) when operating with the minimum
|
||
and maximum stated cable loss between the antenna and the beacon.
|
||
Remote Antenna with an Integrated Cable
|
||
In this configuration (e.g., a military PLB with a body worn antenna) the antenna and cable
|
||
combination is fixed and supplied by the beacon manufacturer (although there maybe more than one
|
||
approved combination for different applications) and the length and type of cable between the antenna
|
||
and beacon cannot be changed.
|
||
This combination utilising a specific manufacturer supplied integrated antenna cable shall be tested
|
||
with that cable.
|
||
All antennas and cabling arrangements to be approved with a beacon shall be specified by the
|
||
manufacturer and shall meet all the requirements of section 2.4.
|
||
|
||
2-14
|
||
|
||
2.5
|
||
406 MHz Homing Transmitter
|
||
The distress beacon may transmit a 406 MHz Homing signal as defined in this section\*. However
|
||
ELT (DT)s are not required to provide a 406-MHz homing signal.
|
||
- END OF SECTION 2 -
|
||
* A CW unmodulated 406-MHz homing and on-scene locating signal is under development with details to be provided
|
||
in a future update to T.018 and will be centered at 406.050 MHz, ± 2 kHz, at a power level, repetition rate, and pulse
|
||
width to be determined.
|
||
|
||
3-1
|
||
|
||
3.
|
||
DIGITAL MESSAGE CONTENT
|
||
3.1
|
||
Basic Structure
|
||
The digital message which is transmitted by the 406 MHz beacon consists of:
|
||
a) 202 information bits; and
|
||
b) 48 bits for BCH (250,202) error correction.
|
||
The 202 information bits are further divided into:
|
||
•
|
||
154 bits within the main data field (transmitted in every burst),
|
||
•
|
||
48 bits within a rotating data field (may be 1 of 16 different content types).
|
||
Message content structure is shown in Figure 3-1 below. Data transmission starts with bit 1, the
|
||
left-hand (most significant) bit of the 154 bit main field.
|
||
202 information bits
|
||
48 error correction bits
|
||
154 bit main field
|
||
48 bit rotating field
|
||
48 bit BCH field
|
||
Main Message
|
||
Spare
|
||
|
||
…
|
||
|
||
|
||
…
|
||
|
||
|
||
….……
|
||
|
||
|
||
…………….
|
||
|
||
|
||
Figure 3-1: Message content bits
|
||
3.2
|
||
Beacon Message Content – Main Field
|
||
The main field provides for the minimum requirements of document C/S G.008 using sub-fields as
|
||
shown in Table 3.1 below. Note: additional coding guidance is included in Appendix I.
|
||
Unless stated otherwise all sub-fields are separately binary encoded, with the Least Significant Bit to the
|
||
right (i.e., the highest numbered bit in that particular message field).
|
||
|
||
3-2
|
||
|
||
Table 3.1: Minimum Requirement main field in the beacon message
|
||
(transmitted in every burst)
|
||
C/S
|
||
G.008
|
||
reqmt
|
||
Para.
|
||
Description
|
||
Number
|
||
of bits
|
||
Bit
|
||
numbers
|
||
in
|
||
message
|
||
Content
|
||
3.7.1a
|
||
TAC Number
|
||
|
||
1-16
|
||
(MSB=1)
|
||
16-bit TAC # (0 to 65,535)*†
|
||
3.7.1a
|
||
Serial Number
|
||
|
||
17-30
|
||
14-bit serial number (0 to 16,383)\*
|
||
3.7.1a
|
||
Country code
|
||
|
||
31-40
|
||
(MSB=
|
||
31)
|
||
A three-digit decimal country code number (0 to 999).
|
||
Allowable Country codes are those provided in the
|
||
International Telecommunication Union (ITU) Maritime
|
||
Identification Digit (MID) country code list available on
|
||
the ITU website:
|
||
(https://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/mid
|
||
.aspx).
|
||
3.7.1d
|
||
Status of homing
|
||
device
|
||
|
||
|
||
On beacon activation a ‘1’ indicates that the beacon is
|
||
equipped with at least one homing signal and a ‘0’
|
||
indicates that the beacon is not equipped with any
|
||
homing signals or that they have been deliberately
|
||
disabled. Once the homing signal in the beacon has been
|
||
activated, a ‘1’ indicates that at least one homing device
|
||
is functional and transmitting. A ‘0’ indicates that no
|
||
homing device is functional, or it has been deliberately
|
||
disabled.
|
||
RLS function(s)
|
||
|
||
|
||
A ‘0’ indicates a beacon without RLS capability or with
|
||
this capability disabled.
|
||
A ‘1’ indicates a beacon with RLS capability enabled
|
||
(e.g., RLS Type-1 automatic acknowledgement, RLS
|
||
Type-2 manual acknowledgement, or RLS Type 3 two-
|
||
way communication (message) service).
|
||
N/A
|
||
Test Protocol
|
||
|
||
|
||
A ‘0’ indicates normal beacon operation. A ‘1’ indicates
|
||
a Test Protocol message for non-operational use.
|
||
Selection of test protocol is not an end-user capability.
|
||
* The TAC and serial number combination shall be unique (see section 3.6).
|
||
† TAC value range 65,521 - 65,535 is reserved for System beacons (e.g., reference and QMS beacons, calibration
|
||
beacon, simulators, etc.) – See document C/S T.022.
|
||
|
||
3-3
|
||
|
||
C/S
|
||
G.008
|
||
reqmt
|
||
Para.
|
||
Description
|
||
Number
|
||
of bits
|
||
Bit
|
||
numbers
|
||
in
|
||
message
|
||
Content
|
||
3.7.1g
|
||
Encoded GNSS
|
||
location
|
||
|
||
|
||
(MSB=
|
||
45, 52,
|
||
68, 76)
|
||
|
||
45-51
|
||
52-66
|
||
|
||
68-75
|
||
76-90
|
||
Location* is provided to 3.4 m resolution max in the
|
||
following order:
|
||
N/S flag (N=0, S=1);
|
||
Degrees (0 to 90) in 1-degree increments;
|
||
Decimal parts of a degree (0.5 to 0.00003);
|
||
(Default value of bits = 0 1111111
|
||
000001111100000).
|
||
If the beacon does not have encoded location
|
||
capability†, then these bits shall be set to the following
|
||
default value:
|
||
Bits = 1 1111111 000001111100000.
|
||
E/W flag (E=0, W=1);
|
||
Degrees (0 to 180) in 1-degree increments;
|
||
Decimal parts of a degree (0.5 to 0.00003);
|
||
(Default value of bits = 0 11111111
|
||
111110000011111).
|
||
If the beacon does not have encoded location
|
||
capability†, then these bits shall be set to the following
|
||
default value:
|
||
Bits = 1 11111111 111110000011111.
|
||
3.7.1h
|
||
Vessel ID
|
||
|
||
91-93
|
||
A three-digit binary field identifier is first transmitted to
|
||
identify the following message content:
|
||
000 - No aircraft or maritime identity (may be defined
|
||
for national use‡; default content for bits 94-137 is all
|
||
0’s);
|
||
001 – Maritime MMSI and/or AIS Identity;
|
||
010 – Radio call sign;
|
||
011 – Aircraft Registration Marking (Tail Number);
|
||
100 – Aircraft aviation 24 Bit Address;
|
||
101 – Aircraft operator and serial number;
|
||
110 – Spare;
|
||
111 – Reserved for System Testing (may contain
|
||
* All position information is encoded as degrees and decimal parts of a degree, or as fractions of these units to be as
|
||
close as possible to the actual position. Latitude and longitude data are rounded off (i.e. not truncated) to the available
|
||
resolution. All rounding shall follow normal rounding conventions, for example with a resolution of 4, 0.000 to 1.999
|
||
shall be rounded down to 0 and 2.000 to 3.999 shall be rounded up to 4.
|
||
† If a beacon model has an external navigation input capability but is installed in a configuration in which a navigation
|
||
signal will never be supplied to the interface (i.e., an ELT in a GA aircraft which cannot supply the navigation signal
|
||
to the beacon), then this (no capability) is the preferred default that should be used under those circumstances.
|
||
However, if the external navigation connection in the installed configuration is uncertain, then the alternate default
|
||
(no position available at this time) should be used.
|
||
‡ The information contained in this field shall be static even when defined for national use, otherwise the 23-Hex ID
|
||
will be affected, and such a beacon would need to be considered under of letter of compatibility (LoC).
|
||
|
||
3-4
|
||
|
||
C/S
|
||
G.008
|
||
reqmt
|
||
Para.
|
||
Description
|
||
Number
|
||
of bits
|
||
Bit
|
||
numbers
|
||
in
|
||
message
|
||
Content
|
||
Vessel ID
|
||
(continued)
|
||
|
||
|
||
94-123
|
||
124-137
|
||
94-137
|
||
additional information; default content for bits 94-137 is
|
||
all 0’s)\*.
|
||
This is followed by the vessel or aircraft identity. The
|
||
following coding schemes are permitted:
|
||
1 - Maritime Mobile Service Identity:
|
||
A unique ship station identity in the format
|
||
M1I2D3X4X5X6X7X8X9 where MID indicates the flag
|
||
state of the vessel and XXXXXX is the unique vessel
|
||
number in accordance with ITU-R M.585 Annex 1
|
||
Section 1 encoded as a 9-digit number in binary format
|
||
or for Craft Associated with a Parent Ship a unique
|
||
identification in the format 98MIDXXXX where MID
|
||
represents the administration having jurisdiction over the
|
||
identity for the craft associated with a parent ship and
|
||
XXXX represents a unique number assigned by the
|
||
administration for that craft in accordance with ITU-R
|
||
M.585 Annex 1 Section 5 encoded as a 9-digit number in
|
||
binary format. If no MMSI is available, then insert the
|
||
default decimal number 000111111.
|
||
AIS Identity:
|
||
If the beacon includes an AIS transmitter, then its
|
||
identity is inserted in the message here (Note that
|
||
depending on the type of beacon and national coding
|
||
regulations the MMSI preceding this identity may
|
||
contain default data). The Freeform Maritime Identity
|
||
for
|
||
the
|
||
AIS
|
||
transmitter
|
||
has
|
||
the
|
||
format
|
||
9172A3X4X5Y6Y7Y8Y9† in accordance with ITU-R
|
||
M.585 Annex 2 Section 2 where only the last 4 digits
|
||
(Y6Y7Y8Y9) are encoded here as a number in binary
|
||
format. If there is no AIS device, then insert the default
|
||
binary number 10101010101010 (10922).
|
||
2 - Radio call sign:
|
||
Is encoded using the modified-Baudot code shown in
|
||
Table 3.2. This code enables 7 characters to be encoded
|
||
using 42 bits (6x7=42), 94 to 135 (1 to 42 within the
|
||
field). Two bits (136 and 137 (43 and 44 within the
|
||
field)) are spare and shall be coded as 00. The modified-
|
||
* This value is invalid when the test protocol flag, bit-43, is set to ‘0’.
|
||
† The “A” represents the device type (e.g., 0 = AIS SART, 2 = MOB, and 4 = EPIRB) and “XX” represents the
|
||
manufacturers ID, and “YYYY” is a manufacturer assigned serial number associated with the device.
|
||
|
||
3-5
|
||
|
||
C/S
|
||
G.008
|
||
reqmt
|
||
Para.
|
||
Description
|
||
Number
|
||
of bits
|
||
Bit
|
||
numbers
|
||
in
|
||
message
|
||
Content
|
||
Vessel ID
|
||
(continued)
|
||
|
||
|
||
94-137
|
||
94-137
|
||
Baudot characters will be left justified with a modified-
|
||
Baudot space (100100) being used where no character
|
||
exists. If no Radio call sign is available, then insert a
|
||
series of 7 spaces (100100).
|
||
3 - Aircraft Registration Marking*:
|
||
Is encoded using the modified-Baudot code shown in
|
||
Table 3.2. This code enables 7 characters to be encoded
|
||
using 42 bits (6x7=42), 94 to 135 (1 to 42 within the
|
||
field). Two bits (136 and 137 (43 and 44 within the
|
||
field)) are spare and shall be coded as 00. The modified-
|
||
Baudot characters will be right justified with a modified-
|
||
Baudot space (100100) being used where no character
|
||
exists. If no Aircraft Registration Mark is available, then
|
||
insert a series of 7 spaces (100100).
|
||
4 – Aviation 24 Bit Address†:
|
||
Shall either be encoded as a 24-Bit Binary Number,
|
||
followed by 20 spare bits all of which are coded as 0 or
|
||
shall be encoded as a 24-Bit Binary Number, followed
|
||
by the 3-letter aircraft operator designator‡. The 3 letters
|
||
are encoded using the modified-Baudot code shown in
|
||
Table 3.2‡ (3x5 = 15 Bits) followed by 5 spare bits all of
|
||
which are coded as 0. If there is no 24-Bit Address, then
|
||
bits 94-117 shall all be coded as 0. If there is no 3LD for
|
||
the aircraft operator, then the 3LD is coded as “ZGA”,
|
||
i.e., bits 118 to 137 are set to 10001 01011 11000 00000.
|
||
* WARNING: These coding schemes when used in an ELT(DT) (i.e., bits 138-140 are '011’), are NOT compliant with
|
||
the mandatory data elements defined in ICAO document 10150 (either no 3LD aircraft operator (for 3 - Aircraft
|
||
Registration Marking) or no aircraft identifier is available (for 5 - Aircraft operator and serial number)) and the
|
||
associated data cannot be stored in the LADR. Manufacturers wishing to comply with ICAO GADSS requirements
|
||
and use these coding options should consult the relevant Administration’s aviation authorities for guidance prior to
|
||
coding a beacon with these coding options.
|
||
† This coding (when the aircraft 24-bit address and the 3LD designator of the aircraft operator are provided in the
|
||
"Vessel ID" field) is compliant with the mandatory data elements defined in ICAO document 10150, "Manual on the
|
||
Functional Specifications for the Location of an Aircraft in Distress Repository (LADR)".
|
||
The LADR is a facility, that will be used by Cospas-Sarsat, to support ICAO requirements for autonomous location
|
||
of an aircraft in distress contained in Annex 6, Part I, section 6.18 to the Convention on International Civil Aviation.
|
||
‡ A 3-letter aircraft operator designator (3LD) from the list of "Designators for Aircraft Operating Agencies,
|
||
Aeronautical Authorities and Services" published by the International Civil Aviation Organization (ICAO) as
|
||
document 8585.
|
||
|
||
3-6
|
||
|
||
C/S
|
||
G.008
|
||
reqmt
|
||
Para.
|
||
Description
|
||
Number
|
||
of bits
|
||
Bit
|
||
numbers
|
||
in
|
||
message
|
||
Content
|
||
|
||
94-137
|
||
5 - Aircraft operator and serial number*:
|
||
A 3-letter aircraft operator designator†. The 3 letters are
|
||
encoded using the modified-Baudot code shown in
|
||
Table 3.2* (3x5 = 15 Bits). If there is no Aircraft
|
||
operator specified then the 3LD is coded as “ZGA”, i.e.,
|
||
bits 94 to 108 are set to 10001 01011 11000.
|
||
Followed by a serial number (in the range of 1 up to
|
||
4095) as designated by the aircraft operator, encoded in
|
||
binary, with the least significant bit on the right (12 Bits).
|
||
If there is no serial number then bits 109 to 120 shall all
|
||
be coded as 0. The remaining 17 Bits are spare and shall
|
||
follow the above 27 Bits and be encoded all as 1’s.
|
||
Beacon Type†
|
||
|
||
138-140
|
||
“000” ELT (excludes ELT(DT));
|
||
“001” EPIRB;
|
||
“010” PLB;
|
||
“011” ELT(DT);
|
||
“111” System beacon; and
|
||
“100”, “101”, “110” spare.
|
||
Spare bits
|
||
|
||
141-154
|
||
These bits are all set to binary 1.
|
||
For a cancellation message, these bits are all set to 0.
|
||
TOTAL BITS
|
||
IN EACH
|
||
BURST
|
||
|
||
To be transmitted in each burst.
|
||
* The aircraft operator designator (3 letters) can be encoded in 15 bits using a shortened form of the modified-Baudot
|
||
code (i.e.: all letters in the modified-Baudot code are coded in 6 bits, with the first bit = "1". This first bit can, therefore,
|
||
be deleted to form a 5-bit code).
|
||
† These bits always indicate the type of beacon (ELT, EPIRB, PLB, ELT(DT)), as certified, or a System beacon,
|
||
regardless of the vessel ID coded into the beacon.
|
||
|
||
3-7
|
||
|
||
Table 3.2: Modified Baudot Code
|
||
Letter
|
||
Code\*
|
||
MSB LSB
|
||
Letter
|
||
Code
|
||
MSB LSB
|
||
Letter
|
||
Code
|
||
MSB LSB
|
||
A
|
||
|
||
N
|
||
|
||
( )†
|
||
|
||
B
|
||
|
||
O
|
||
|
||
(-)‡
|
||
|
||
C
|
||
|
||
P
|
||
|
||
/
|
||
|
||
D
|
||
|
||
Q
|
||
|
||
|
||
E
|
||
|
||
R
|
||
|
||
|
||
F
|
||
|
||
S
|
||
|
||
|
||
G
|
||
|
||
T
|
||
|
||
|
||
H
|
||
|
||
U
|
||
|
||
|
||
I
|
||
|
||
V
|
||
|
||
|
||
J
|
||
|
||
W
|
||
|
||
|
||
K
|
||
|
||
X
|
||
|
||
|
||
L
|
||
|
||
Y
|
||
|
||
|
||
M
|
||
|
||
Z
|
||
|
||
|
||
3.3
|
||
Beacon Message Content – Rotating Fields
|
||
The objective requirements of document C/S G.008 are provided in rotating fields as detailed below.
|
||
During every transmission burst the beacon shall transmit 1 of the 16 types of rotating field content.
|
||
The type of field content selected for transmission shall be in accordance with the rotating field
|
||
scheduling requirements – see section 3.4. The 16 types of rotating field content are listed below.
|
||
0. C/S G.008 Objective Requirements (except national use and spares)
|
||
1. ELT(DT) In-flight Emergency (to allow more accurate time parameters)
|
||
2. RLS Type 1 Automatic and Type 2 Manual Acknowledgment (for RLS messages)
|
||
3. National Use (to allow national administrations to define for their use)
|
||
4. RLS Type 3 Two-way Communication (to support TWC messages)
|
||
5. Spare (for future use)
|
||
6. Spare (for future use)
|
||
7. Spare (for future use)
|
||
8. Spare (for future use)
|
||
9. Spare (for future use)
|
||
10. Spare (for future use)
|
||
11. Spare (for future use)
|
||
12. Spare (for future use)
|
||
13. Spare (for future use)
|
||
14. Spare (for future use)
|
||
15. Cancellation Message
|
||
* MSB: most significant bit,
|
||
LSB: least significant bit
|
||
† Space
|
||
‡ Hyphen
|
||
|
||
3-8
|
||
|
||
Detailed content of rotating fields \#0 through \#4, and \#15 are shown in the tables below.
|
||
Unless stated otherwise all sub-fields of every rotating field are separately binary encoded, with the Least
|
||
Significant Bit to the right (i.e., the highest numbered bit in that particular message field).
|
||
Table 3.3: C/S G.008 Objective Requirements Rotating Field (\#0)
|
||
C/S G.008
|
||
Section
|
||
Sub-field
|
||
Description
|
||
Number
|
||
of bits
|
||
Bit
|
||
numbers in
|
||
message
|
||
Content
|
||
Rotating
|
||
field
|
||
Identifier
|
||
|
||
155-158 in
|
||
message (1-
|
||
4 in rotating
|
||
field)
|
||
0000 – G.008 Objective Requirements.
|
||
4.3.1a
|
||
Elapsed
|
||
Time
|
||
since activation
|
||
|
||
159-164 in
|
||
message (5-
|
||
10 in
|
||
rotating
|
||
field)
|
||
0 to 63 hours in one-hour steps (actual time since
|
||
activation shall be truncated, not rounded e.g., between
|
||
1 hour and 2 hours after activation shall be encoded as
|
||
1 hour). If the beacon is turned off and on again (even
|
||
quickly) this field shall be reset to zero. If the time is
|
||
greater than 63 hours, the value shall be set to 63.
|
||
4.3.1b
|
||
Time from last
|
||
encoded location
|
||
|
||
165-175 in
|
||
message
|
||
(11-21 in
|
||
rotating
|
||
field)
|
||
0 to 2046 minutes (34 hours and 6 minutes) in one-minute
|
||
steps (actual time since last location shall be truncated, not
|
||
rounded e.g., between 34 minutes and 35 minutes after
|
||
activation shall be encoded as 34 minutes). Every time
|
||
that a new / updated encoded location is obtained this field
|
||
shall be reset to zero. Time is calculated from when the
|
||
location was obtained not when it was transmitted. If the
|
||
time is greater than 2046 minutes, the value shall be set to
|
||
2046. If the beacon has not yet obtained a location from
|
||
the GNSS receiver or is not equipped with encoded
|
||
location capability, then this field should be set to 2047 as
|
||
a default value.
|
||
4.3.1c
|
||
Altitude
|
||
of
|
||
Encoded
|
||
location
|
||
|
||
176-185 in
|
||
message
|
||
(22-31 in
|
||
rotating
|
||
field)
|
||
Altitudes of ≤-400 metres to 15952 metres in steps of 16
|
||
metres (where altitudes ≤-400m are encoded as all zeros,
|
||
-384 metres is encoded as 0000000001 and sea level
|
||
would be encoded as 0000011001). Heights shall be
|
||
rounded to the nearest 16 metre step, not truncated. If the
|
||
height is greater than 15952 metres, the height shall be
|
||
considered as 15952 metres and encoded as 1111111110.
|
||
If altitude is not available (e.g., there is no location data or
|
||
only a 2D fix is available) then this field shall be encoded
|
||
as all 1’s.
|
||
|
||
3-9
|
||
|
||
C/S G.008
|
||
Section
|
||
Sub-field
|
||
Description
|
||
Number
|
||
of bits
|
||
Bit
|
||
numbers in
|
||
message
|
||
Content
|
||
4.3.1d
|
||
Dilution
|
||
of
|
||
Precision
|
||
|
||
186-193 in
|
||
message
|
||
(32-39 in
|
||
rotating
|
||
field)
|
||
The value of HDOP of the encoded location shall be
|
||
reported (first 4 bits) followed by the value of VDOP on
|
||
the following basis:
|
||
0000 = DOP <= 1;
|
||
0001 = DOP > 1 and <= 2;
|
||
0010 = DOP > 2 and <= 3;
|
||
0011 = DOP > 3 and <= 4;
|
||
0100 = DOP > 4 and <= 5;
|
||
0101 = DOP > 5 and <= 6;
|
||
0110 = DOP > 6 and <= 7;
|
||
0111 = DOP > 7 and <= 8;
|
||
1000 = DOP > 8 and <= 10;
|
||
1001 = DOP > 10 and <= 12;
|
||
1010 = DOP > 12 and <= 15;
|
||
1011 = DOP > 15 and <= 20;
|
||
1100 = DOP > 20 and <= 30;
|
||
1101 = DOP > 30 and <= 50;
|
||
1110 = DOP > 50;
|
||
1111 = DOP Not Available.
|
||
4.3.1f
|
||
Automated/Man
|
||
ual
|
||
Activation
|
||
notification
|
||
|
||
194-195 in
|
||
message
|
||
(40-41 in
|
||
rotating
|
||
field)
|
||
Report the activation method of the beacon as follows:
|
||
|
||
Manual Activation by user;
|
||
|
||
Automatic Activation by the beacon;
|
||
|
||
Automatic Activation by external means; and
|
||
|
||
Spare.
|
||
4.3.1g
|
||
Remaining
|
||
battery capacity
|
||
|
||
196-198 in
|
||
message
|
||
(42-44 in
|
||
rotating
|
||
field)
|
||
The remaining battery capacity in the beacon compared to
|
||
its initial capacity shall be reported as follows:
|
||
|
||
<= 5% remaining;
|
||
|
||
> 5% and <= 10% remaining;
|
||
|
||
> 10% and <= 25% remaining;
|
||
|
||
> 25% and <= 50% remaining;
|
||
|
||
> 50% and <= 75% remaining;
|
||
|
||
> 75% and <= 100% remaining;
|
||
|
||
Reserved for future use; and
|
||
|
||
Battery Capacity Not Available or Not Provided.
|
||
Not in C/S
|
||
G.008
|
||
GNSS status
|
||
|
||
199-200 in
|
||
message
|
||
(45-46 in
|
||
rotating
|
||
field)
|
||
This field reports the status of the GNSS receiver used to
|
||
provide the encoded location as follows:
|
||
|
||
No Fix, or not available;
|
||
|
||
2D location only;
|
||
|
||
3D location; and
|
||
|
||
Reserved for future use.
|
||
Spare
|
||
|
||
201-202 in
|
||
message
|
||
(47-48 in
|
||
rotating
|
||
field)
|
||
00.
|
||
TOTAL
|
||
Bits in Rotating
|
||
Field
|
||
|
||
3-10
|
||
|
||
Table 3.4: ELT(DT) In-Flight Emergency Rotating Field (\#1)
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
Rotating
|
||
field
|
||
Identifier
|
||
|
||
155-158 in
|
||
message (1-4 in
|
||
rotating field)
|
||
0001 In-Flight Emergency.
|
||
4.3.1b
|
||
Time
|
||
of
|
||
last
|
||
encoded location
|
||
|
||
159-175 in
|
||
message (5-21
|
||
in rotating field)
|
||
Time rounded to nearest second (17 bits):
|
||
Time ‘sssss’ where ‘00001’ indicates a time of
|
||
00:00:01 UTC and ‘86399’ indicates a time of
|
||
23:59:59 UTC). If UTC time is not available or
|
||
the time is more than 24 hours old, then this field
|
||
shall be encoded as all ones.
|
||
Altitude of
|
||
Encoded
|
||
Location
|
||
|
||
176-185 in
|
||
message (22-31
|
||
in rotating field)
|
||
Altitudes of ≤-400 metres to 15952 metres in
|
||
steps of 16 metres (where altitudes ≤-400m are
|
||
encoded as all zeros, -384 metres is encoded as
|
||
0000000001 and sea level would be encoded as
|
||
0000011001). Heights shall be rounded to the
|
||
nearest 16 metre step, not truncated. If the height
|
||
is greater than 15952 metres, the height shall be
|
||
considered as 15952 metres and encoded as
|
||
1111111110.
|
||
If altitude is not available, e.g., there is no
|
||
location data or only a 2D fix is available, then
|
||
this field shall be encoded as all ones.
|
||
Triggering event
|
||
|
||
186-189 in
|
||
message (32-35
|
||
in rotating field)
|
||
0001 – Manual activation by the crew;
|
||
0100 – G-switch/Deformation Activation;
|
||
1000 – Automatic Activation from Avionics or
|
||
Triggering System\*.
|
||
If multiple triggers occur these bits shall always
|
||
indicate the latest event.
|
||
All other bit combinations – spare.
|
||
GNSS Status
|
||
|
||
190-191 in
|
||
message (36-37
|
||
in rotating field)
|
||
This field reports the status of the GNSS receiver
|
||
used to provide the encoded location as follows:
|
||
00 Not Fix;
|
||
01 2D location only;
|
||
10 3D location; and
|
||
11 Spare.
|
||
Remaining
|
||
battery capacity
|
||
|
||
192-193 in
|
||
message (38-39
|
||
in rotating field)
|
||
The remaining battery capacity in the beacon
|
||
compared to its initial capacity shall be reported
|
||
as follows:
|
||
00 ≤ 33% remaining;
|
||
01 > 33% and ≤ 66% remaining;
|
||
10 > 66% remaining; and
|
||
11 Battery capacity not available or Not Provided
|
||
Spare
|
||
|
||
194-202 in
|
||
message (40-48
|
||
in rotating field)
|
||
All 0’s.
|
||
TOTAL
|
||
|
||
* Trigger in compliance with EUROCAE document ED-237.
|
||
|
||
3-11
|
||
|
||
Table 3.5: RLS Type 1 Automatic and Type 2 Manual Acknowledgment Rotating Field (\#2)
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
Rotating
|
||
field
|
||
identifier
|
||
|
||
155-158 in
|
||
message (1-4 in
|
||
rotating field)
|
||
bit 1-4:
|
||
“0010”.
|
||
Unassigned
|
||
|
||
159-160 in
|
||
message (5-6 in
|
||
rotating field)
|
||
bit 5-6:
|
||
All 0’s.
|
||
Beacon
|
||
RLS
|
||
Capability
|
||
|
||
161-166 in
|
||
message (7-12
|
||
in rotating field)
|
||
bit 7 - Capability to process automatically
|
||
generated Acknowledgement RLM Type-1:
|
||
"1":
|
||
Acknowledgement
|
||
Type-1 (automatic
|
||
acknowledgement) accepted by this beacon; and
|
||
"0": Acknowledgement Type-1 not requested
|
||
and not accepted by this beacon.
|
||
bit 8 - Capability to process manually generated
|
||
RLM (e.g., Acknowledgment Type-2):
|
||
"1": Manually generated RLM (such as
|
||
Acknowledgement Type-2) accepted by this
|
||
beacon; and
|
||
"0": Manually generated RLM (such as
|
||
Acknowledgement Type-2) not requested and
|
||
not accepted by this beacon.
|
||
Note: The condition bit 7 = “0” and bit 8 = “0” is
|
||
an invalid condition; at least one of these two bits
|
||
must always be a “1”.
|
||
bit 9-12 – Reserved for future use and to be set
|
||
to all “0’s”.
|
||
RLS
|
||
Provider
|
||
Identification
|
||
|
||
167-169 in
|
||
message (13-15
|
||
in rotating field)
|
||
bit 13-15:
|
||
"001": GALILEO Return Link Service Provider;
|
||
"010":
|
||
GLONASS\*
|
||
Return
|
||
Link
|
||
Service
|
||
Provider; and
|
||
“011”: BDS* Return Link Service Provider.
|
||
Other combinations: Spares (for other possible
|
||
RLS providers)
|
||
Beacon Feedback
|
||
(acknowledgement
|
||
of RLM reception)
|
||
|
||
170-191 in
|
||
message (16-37
|
||
in rotating field)
|
||
If RLS Provider Identification = 001 (bit 13-15)
|
||
bit 16 – RLM Type I Feedback:
|
||
"0": Type 1 not (yet) received; and
|
||
"1": Type 1 received.
|
||
bit 17 – RLM Type 2 Feedback:
|
||
“0”: Type 2 not (yet) received; and
|
||
“1”: Type 2 received.
|
||
* Beacons shall not be coded with these coding options (except for the RLS test coded beacons) until the GLONASS
|
||
or BDS RLS services are declared by the Cospas-Sarsat Council as operational within the Cospas-Sarsat Programme.
|
||
Type approval certificates allowing these versions of the RLS coding will not be issued until the RLS provider has
|
||
been approved for operational use in the System.
|
||
|
||
3-12
|
||
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
bit 18-37 – RLM:
|
||
if (bit 16 = 1 and bit 17=0):
|
||
Copy of bits 61-80 of the short RLM in the Open
|
||
Service Signal in Space (section 5.2 of OS SIS
|
||
ICD* and section 3.2.1 of Galileo SAR SDD†).
|
||
if (bit 16 = 0 and bit 17=1):
|
||
Reserved for future use, currently an invalid
|
||
condition.
|
||
if (bit 16 = 0 and bit 17 = 0):
|
||
Then bits 18-37 all = “0”.
|
||
if (bit 16 = 1 and bit 17 = 1):
|
||
Reserved for future use, currently an invalid
|
||
condition.
|
||
If RLS Provider Identification is not 001:
|
||
Reserved and bits 16-37 shall all be set to “0”.
|
||
Unassigned
|
||
|
||
192-202 in
|
||
message (38-48
|
||
in rotating field)
|
||
All 0’s
|
||
TOTAL
|
||
|
||
Table 3.6: National Use Rotating Field (\#3)
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
Rotating
|
||
field
|
||
identifier
|
||
|
||
155-158 in
|
||
message (1-4 in
|
||
rotating field)
|
||
0011.
|
||
4.3.1.i
|
||
National use
|
||
|
||
159-202 in
|
||
message (5-48 in
|
||
rotating field)
|
||
As defined by national administrations
|
||
Default content all 0’s.
|
||
TOTAL
|
||
|
||
* European GNSS (Galileo) Open Service Signal In Space Interface Control Document (OS SIS ICD v1.3), December 2016.
|
||
† European GNSS (Galileo) SAR/GALILEO Service Definition Document (GALILEO SAR SDD Issue 2.0), January
|
||
2020.
|
||
|
||
3-13
|
||
|
||
Table 3.7: RLS Type 3 TWC (Message) Rotating Field (\#4)
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
Rotating
|
||
field
|
||
identifier
|
||
|
||
155-158 in
|
||
message (1-4 in
|
||
rotating field)
|
||
bit 1-4:
|
||
“0100”.
|
||
TWC
|
||
Provider
|
||
Identification
|
||
|
||
159-161 in the
|
||
message (5-7 in
|
||
rotating field)
|
||
bits 5-7:
|
||
"001": GALILEO* Return Link Service
|
||
Provider;
|
||
"010": GLONASS† Return Link Service
|
||
Provider; and
|
||
“011”: BDS* Return Link Service Provider.
|
||
Other combinations: Spares (for other possible
|
||
RLS providers)
|
||
Dataset
|
||
Version
|
||
ID
|
||
|
||
162-166 in the
|
||
message (8-12
|
||
in rotating field)
|
||
bits 8-12:
|
||
TWC Message Dataset versioning‡
|
||
Default value 00000
|
||
The dataset version inserted here shall
|
||
correspond to the dataset version number that is
|
||
being used by the beacon at that time. If the
|
||
Database is subsequently updated then this field
|
||
shall also be updated to reflect the version
|
||
number of the updated dataset now being used
|
||
by the beacon.
|
||
RLM Type 3 TWC
|
||
Acknowledgement
|
||
|
||
167 in the
|
||
message (13 in
|
||
rotating field)
|
||
bit 13:
|
||
“0”: RLM Type3 TWC Acknowledgement not
|
||
(yet) received; and
|
||
“1”: RLM Type-3 TWC Acknowledgement
|
||
received.
|
||
Note: Once the first RLM Type-3 TWC
|
||
acknowledgement is received by the beacon, this
|
||
bit should remain set to “1” for the remaining
|
||
period of activation.
|
||
Answer
|
||
Format
|
||
Flag
|
||
|
||
168 in the
|
||
message (14 in
|
||
rotating field)
|
||
bit 14: This bit defines the answer format (i.e.,
|
||
Short or Long) of TWC Messages in bits 16 to
|
||
48.
|
||
“0”: is the short answer format in which there
|
||
are three 11-bit slots which each contain a 7-bit
|
||
Question/Instruction ID and 4-bit Answer ID
|
||
* Galileo L1 navigation message is described in European GNSS (Galileo) Open Service Signal In Space Interface
|
||
Control Document (OS SIS ICD version TBC).
|
||
† Beacons shall not be coded with these coding options (except for the RLS test coded beacons) until the GLONASS
|
||
or BDS RLS services are declared by the Cospas-Sarsat Council as operational within the Cospas-Sarsat Programme.
|
||
Type approval certificates allowing these versions of the RLS coding will not be issued until the RLS provider has
|
||
been approved for operational use in the System.
|
||
‡ TWC message database versions are available at [document C/S TBD].
|
||
|
||
3-14
|
||
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
“1”: is the long answer format in which a 22-bit
|
||
slot contains a 7-bit Question ID and 15-bit
|
||
Answer(s) ID, followed by a single 11-bit slot
|
||
which contain a 7-bit Question/Instruction ID
|
||
and 4-bit Answer ID
|
||
Spare
|
||
|
||
169 in the
|
||
message (15 in
|
||
rotating field)
|
||
bit 15:
|
||
Spare bit.
|
||
Default content 0
|
||
TWC Messages
|
||
|
||
170-202 in the
|
||
message (16-48
|
||
in rotating field)
|
||
If bit 14 in the rotating field = 0 (short
|
||
format):
|
||
bits 16-22:
|
||
7 bits dedicated to question or instruction 1
|
||
Default value 0000000.
|
||
bits 23-26:
|
||
4 bits allocated to answer.
|
||
Default value (0000) is for the
|
||
acknowledgement to question or instruction 1.
|
||
bits 27-33:
|
||
7 bits dedicated to question or instruction 2
|
||
Default value 0000000.
|
||
bits 34-37:
|
||
4 bits allocated to answer.
|
||
Default value (0000) is for the
|
||
acknowledgement to question or instruction 2.
|
||
If bit 14 in rotating field = 1 (long format):
|
||
bits 16-22:
|
||
7 bits dedicated to question 1
|
||
Default value 0000000
|
||
bits 23-37:
|
||
15 bits allocated to answer(s).
|
||
Default value (00000 00000 00000) is for the
|
||
acknowledgement to the long format question or
|
||
instruction 1.
|
||
Independently of bit 14’s value:
|
||
bits 38-44:
|
||
7 bits dedicated to question or instruction 3 for
|
||
the short format or question or instruction 2 for
|
||
the long format.
|
||
Default value 0000000.
|
||
bits 45-48:
|
||
4 bits allocated to answer.
|
||
Default value (0000) is for the
|
||
acknowledgement to question or instruction 3
|
||
|
||
3-15
|
||
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
for the short format or question or instruction 2
|
||
for the long format.
|
||
[The dataset is defined in document C/S TBD]
|
||
TOTAL
|
||
|
||
Table 3.8: Spare Rotating Fields (for future use) (#5 - #14)
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers in
|
||
message
|
||
Content
|
||
Rotating field
|
||
identifier
|
||
|
||
155-158 in
|
||
message (1-4 in
|
||
rotating field)
|
||
0101 to 1110 inclusive.
|
||
4.3.1.h
|
||
Spares
|
||
|
||
159-202 in
|
||
message (5-48
|
||
in rotating field)
|
||
Default content all 0’s.
|
||
TOTAL
|
||
|
||
Table 3.9: Cancellation Message Rotating Field (\#15)
|
||
C/S
|
||
G.008
|
||
section
|
||
Sub-field
|
||
Description
|
||
# Bits
|
||
Bit numbers
|
||
in message
|
||
Content
|
||
Rotating field
|
||
Identifier
|
||
|
||
155-158 in
|
||
message (1-4
|
||
in rotating
|
||
field)
|
||
1111.
|
||
Fixed
|
||
|
||
159-200 in
|
||
message (5-46
|
||
in rotating
|
||
field)
|
||
Set to all 1’s.
|
||
Method of
|
||
deactivation
|
||
|
||
201-202 in
|
||
message (47-
|
||
48 in rotating
|
||
field)
|
||
00 Spare;
|
||
10 Manual De-Activation by user;
|
||
01 Automatic De-Activation by external means;
|
||
and
|
||
11 Spare.
|
||
TOTAL
|
||
|
||
3-16
|
||
|
||
3.4
|
||
Beacon Transmission Scheduling of Rotating Fields
|
||
Unless dictated otherwise by national or international regulations beacons shall transmit the rotating
|
||
fields indicated below when making the following transmissions:
|
||
Table 3.10: Rotating Field Transmission Conditions
|
||
Type of Beacon
|
||
Self-Test
|
||
Transmission
|
||
Normal
|
||
Transmission
|
||
Cancellation
|
||
Message
|
||
All Beacons except
|
||
ELT(DT)s, Beacons with
|
||
RLS Functionality (Type
|
||
1, 2 and/or 3) and National
|
||
Use Beacons
|
||
G.008 Objective
|
||
Requirements Field
|
||
\#0
|
||
G.008 Objective
|
||
Requirements Field
|
||
\#0
|
||
Cancellation
|
||
Message Field \#15
|
||
ELT(DT)s
|
||
(see Note 2)
|
||
In-Flight Emergency
|
||
Field \#1
|
||
In-Flight Emergency
|
||
Field \#1
|
||
Cancellation
|
||
Message Field \#15
|
||
Beacons with RLS Type 1
|
||
Automatic
|
||
Acknowledgement
|
||
Functionality
|
||
(see Note 3)
|
||
RLS Field \#2
|
||
RLS Field \#2
|
||
alternating with
|
||
G.008 Field \#0
|
||
Cancellation
|
||
Message Field \#15
|
||
National Use Beacons
|
||
(see Note 4)
|
||
National Use Field
|
||
\#3
|
||
Field \#3 and Field \#0
|
||
on a schedule set by
|
||
the relevant national
|
||
authority
|
||
Cancellation
|
||
Message Field \#15
|
||
Beacons with RLS Type-3
|
||
TWC (message) Functionality
|
||
(see Note 5)
|
||
TWC Field \#4
|
||
TWC Field \#4
|
||
alternating with G.008
|
||
Field \#0
|
||
Cancellation Message
|
||
Field \#15
|
||
[Beacons with combined RLS
|
||
Functionality (see Note 6)]
|
||
[RLS Field \#2 and/or
|
||
TWC Field \#4]
|
||
[TWC Fields \#2 and/or
|
||
\#4 alternating with
|
||
G.008 Field \#0
|
||
TWC Field \#4 to have
|
||
priority in TWC mode]
|
||
[Cancellation Message
|
||
Field \#15]
|
||
Notes
|
||
1. All beacons always transmit the Main 154 Bit Message Field in every burst before transmitting a
|
||
Rotating Field as defined above.
|
||
2. ELT(DT)s cannot include RLS (e.g., Type 1, Type 2, Type 3, etc.) functionality and therefore
|
||
always transmit Rotating Field \#1
|
||
3. Beacons with RLS Type 1 automatic acknowledgement functionality always transmit Field \#2 in
|
||
the first and subsequent odd numbered bursts and Field \#0 in the second and subsequent even
|
||
numbered bursts
|
||
|
||
3-17
|
||
|
||
4. National Use ELT(DT) Beacons shall transmit Field \#3 and Field \#1 on a schedule set by the
|
||
relevant national authority. National Use Beacons with RLS Functionality shall transmit the
|
||
selected fields, Field \#4, Field \#3, Field \#2 and Field \#0 on a schedule set by the relevant national
|
||
authority. During a self-test all types of National Use beacons always transmit Field \#3.
|
||
5. Beacons with RLS Type 3 TWC (message) functionality will transmit Field \#4 in the first and
|
||
subsequent odd numbered bursts and Field \#0 in the second and subsequent even numbered bursts.
|
||
6. Beacons with combined RLS functionality which may be specified in the future.
|
||
3.5
|
||
Beacon Message Content – Error Correcting Field
|
||
A sample of the BCH Error-correcting Code Calculation is provided in Appendix B.
|
||
|
||
3-18
|
||
|
||
3.6
|
||
Beacon Coding and Hex ID
|
||
The manufacturer shall program a unique combination of TAC Number and Serial Number into every
|
||
beacon before it leaves their factory. The TAC Number and Serial Number shall not be capable of
|
||
being deleted from that beacon. Only approved devices shall be allowed to temporarily modify the
|
||
Country Code, TAC, Serial Number and Vessel ID in the transmitted message (e.g., a programming
|
||
adapter (see section 3.7)). If a unit is destroyed or recycled at the end of its life, the unique combination
|
||
of TAC Number and Serial Number used in that beacon shall not be used in another beacon.
|
||
Beacon coding methods are defined in section 3.1 of this specification. Specific operational requirements
|
||
that impact beacon coding, such as the encoding of position data, are defined in section 4 of this
|
||
specification.
|
||
The 23 hexadecimal characters that uniquely identify each 406 MHz beacon are called the beacon
|
||
23 Hex ID. This is never transmitted by the beacon as such, rather it is generated locally by the SAR
|
||
ground segment hardware and generated during beacon manufacture in order to apply identity labels
|
||
to the beacon by extracting the bits shown below from the beacon data.
|
||
The 23 Hex ID is composed as follows:
|
||
Table 3.11: Hex ID Contents
|
||
23 Hex ID Bit
|
||
No Bits
|
||
Reference to Bits in Message
|
||
Data Content
|
||
|
||
|
||
n/a
|
||
Fixed Binary ‘1’
|
||
2 to 11
|
||
|
||
31-40
|
||
C/S Country Code
|
||
|
||
|
||
n/a
|
||
Fixed Binary ‘1’
|
||
|
||
|
||
n/a
|
||
Fixed Binary ‘0’
|
||
|
||
|
||
n/a
|
||
Fixed Binary ‘1’
|
||
15 to 30
|
||
|
||
1-16
|
||
C/S TAC No
|
||
31 to 44
|
||
|
||
17-30
|
||
Beacon Serial Number
|
||
|
||
|
||
Test Protocol Flag
|
||
46 to 48
|
||
|
||
91-93
|
||
Aircraft / Vessel ID Type
|
||
49 to 92
|
||
|
||
94-137
|
||
Aircraft / Vessel ID
|
||
Total
|
||
|
||
23 Hex
|
||
Notes
|
||
1) Fixing bits 1, 12, 13 and 14 of the 23 Hex ID to ‘1101’ ensures that the 23 Hex ID cannot duplicate a
|
||
First Generation Beacon 15 Hex ID.
|
||
2) The first 60 bits of the 23 Hex ID comprising the C/S Country Code, C/S TAC Number, Beacon Serial
|
||
Number, Test Protocol Flag, Fixed Bits 1, 12, 13 and 14 and the first part of the Aircraft / Vessel ID
|
||
together form a unique subset of the 23 Hex ID which form an SGB 15 Hex ID which is required for
|
||
certain services, such as the Return Link Service. That is a unique SGB 15 Hex ID which may be
|
||
obtained by simply truncating the 23 Hex ID and ignoring the last 8 Hex characters.
|
||
|
||
3-19
|
||
|
||
3.7
|
||
Programming Adapters
|
||
If a manufacturer chooses to offer an optional Programming Adapter with a particular Beacon Model
|
||
(as defined in C/S T.021 section 1.3) then it shall comply with the requirements in this section.
|
||
A Programming Adapter shall only be capable of functioning with one particular Beacon Model;
|
||
separate Beacon Models shall require the use of a different Programming Adapter. The mechanism
|
||
used to prevent the use of a Programming Adapter with a model for which it was not designed shall be
|
||
defined by the beacon manufacturer and may include physically keying of the adaptors, use of model
|
||
recognition functionality, or other suitable design features.
|
||
Each Programming Adapter shall be given its own unique Serial Number by the beacon manufacturer.
|
||
The manufacturer shall program a unique combination of TAC Number and Serial Number into every
|
||
Programming Adapter before it leaves their factory. The TAC Number and Serial Number shall not be
|
||
capable of being deleted from that Programming Adapter or being overwritten by any means. If a unit
|
||
is destroyed or recycled at the end of its life, the unique combination of TAC Number and Serial
|
||
Number used in that Programming Adapter shall not be used in another Programming Adapter.
|
||
All data stored in a Programming Adapter shall be in non-volatile memory.
|
||
A Programming Adapter shall be capable of having a Country Code and Vessel ID programmed into
|
||
it, which may be capable of being changed and overwritten.
|
||
Every Programming Adapter shall be labelled in accordance with Section 4.5.11.
|
||
When a beacon connected to a Programming Adapter is activated, it shall continue to transmit in its
|
||
message the ID supplied from the Programming Adapter for the duration of the beacon activation, even
|
||
if the adapter subsequently becomes disconnected/disassociated from the beacon. When next activated
|
||
(unless the Programming Adapter or another Programming Adapter has been reconnected / connected
|
||
to the beacon in the meantime), it shall transmit the beacon’s own unique TAC Number and Serial
|
||
Number and the Country Code and Vessel ID. If a Programming Adapter is connected to an activated
|
||
beacon, then the beacon shall ignore the Programming Adapter and continue to transmit the beacons
|
||
own identity, until the beacon is deactivated and subsequently reactivated with the Programming
|
||
Adapter connected, at which time it will then transmit the identity in the Programming Adapter.
|
||
- END OF SECTION 3 –
|
||
|
||
4-1
|
||
|
||
4.
|
||
ENVIRONMENTAL AND OPERATIONAL REQUIREMENTS
|
||
4.1
|
||
General
|
||
SGBs shall function with the MEOSAR system such that 406 MHz transmissions from a beacon can
|
||
be correctly detected, located, and decoded by a MEOLUT when the beacon is operated in nominal
|
||
beacon configuration(s) and under nominal System conditions. An ELT(DT) shall also provide valid
|
||
2D and altitude data.
|
||
As explained in section 1.2, the environmental and operational requirements defined in this section are
|
||
not intended to be exhaustive. They are minimum requirements, which may be complemented by
|
||
national or international standards.
|
||
4.2
|
||
Thermal Environment
|
||
4.2.1
|
||
Operating Temperature Range
|
||
Three standard classes of operating temperature range are defined, inside which all of the
|
||
requirements within this specification shall be met:
|
||
Class 0:
|
||
-55°C to +70°C
|
||
Class 1:
|
||
-40°C to +55°C
|
||
Class 2:
|
||
-20°C to +55°C
|
||
4.2.2
|
||
Temperature Gradient
|
||
All of the requirements within this specification, shall be met when the beacon is subjected to the
|
||
temperature gradient shown in Figure 4.1.
|
||
4.2.3
|
||
Thermal Shock
|
||
All of the requirements within this specification shall be met, for measurements beginning 5 seconds
|
||
after simultaneously activating the beacon and applying a rapid thermal shock of 50 °C within the
|
||
specified operating temperature range of the beacon within 1 minute. Subsequently, all requirements
|
||
shall continue to be met for a minimum period of two hours.
|
||
|
||
4-2
|
||
|
||
NOTES:
|
||
Tmax = + 70°C (Class 0 beacon)
|
||
Tmax = + 55°C (Class 1 & 2 beacons)
|
||
Tmin = - 55°C (Class 0 beacon)
|
||
Tmin = - 40°C (Class 1 beacon)
|
||
Tmin = - 20°C (Class 2 beacon)
|
||
tstart
|
||
= test start time
|
||
tstop
|
||
= test stop time
|
||
ton
|
||
= beacon turn-on time after 2 hour “cold soak”
|
||
tmeas = start time of frequency stability measurement (ton + 0 min)
|
||
A\*
|
||
= 7°C/hour for Class 0 (45°C/hour for ELT(DT))
|
||
A\*
|
||
= 5°C/hour for Class 1 and Class 2 (33°C/hour for ELT(DT))
|
||
α
|
||
= For ELT(DT)s this time is reduced on the down-ramp test to
|
||
one (1) hour.
|
||
SLOPE = +A* °C/h
|
||
SLOPE = -A* °C/h
|
||
TIME
|
||
tmeas
|
||
2hα
|
||
2h
|
||
2h
|
||
1h
|
||
Tmin
|
||
TEMPERATURE (°C)
|
||
ton
|
||
Twarm-up = 0 min
|
||
Tmax
|
||
tstart
|
||
tstop
|
||
Figure 4-1: Temperature Gradient
|
||
4.3
|
||
Mechanical Environment
|
||
Beacons should be submitted to vibration and shock tests consistent with their intended use. These
|
||
requirements should be defined by national authorities, preferably using internationally-recognized
|
||
standards such as RTCA/DO-204 for ELTs.
|
||
|
||
4-3
|
||
|
||
4.4
|
||
Other Environmental Requirements
|
||
Other environmental requirements such as humidity tests, altitude tests, over/under pressure tests,
|
||
waterproofness tests, sand and dust tests, fluids susceptibility tests, etc., may be defined by national
|
||
authorities, preferably using internationally-recognized standards.
|
||
4.5
|
||
Operational Requirements
|
||
4.5.1
|
||
Duration of Continuous Operation
|
||
The minimum duration of continuous operation shall be at least 24 hours* at any temperature
|
||
throughout the specified operating temperature range.
|
||
For ELT(DT)s, at the end of the 370-minute period, the ELT(DT) shall continue transmitting on the
|
||
same schedule as before the 370-minute limit was reached until the ELT(DT) is either deactivated,
|
||
or runs out of battery life. Minimum duration of continuous operation requirements for Crash
|
||
Survivable ELT(DT)s can be found in section 4.5.15.5 and for Combined ELT(DT)s in section
|
||
4.5.16.7.
|
||
4.5.1.1 Battery Replacement Interval
|
||
The beacon battery replacement interval shall be declared by the beacon manufacturer. At the
|
||
end of the battery replacement interval the beacon shall continue to meet the required duration of
|
||
continuous operation as defined in 4.5.1 after accounting for all losses in battery capacity over
|
||
the declared battery replacement interval at ambient temperatures plus a safety factor of 65%
|
||
applied to all losses, except the loss due to self-discharge.
|
||
4.5.2
|
||
Other Operational Requirements
|
||
Other operational requirements such as installation and maintenance methods, remote monitoring,
|
||
activation methods on planes or boats, etc. may be defined by national authorities.
|
||
4.5.3
|
||
Radio-Locating Signal (for Homing and on-Scene Locating)
|
||
The distress beacon may transmit a 406 MHz Radio-Locating signal as defined in section 2.5.
|
||
ELT(DT)s are not required to provide a Radio-Locating signal.
|
||
The transmission of the 406 MHz satellite signal shall take precedence over any Radio-Locating
|
||
Signals. Homing signal types should be momentarily interrupted, delayed, rescheduled, or eliminated
|
||
according to the relevant standard for each type, in order to ensure that homing signals are not
|
||
transmitted at the same time as the 406-MHz signal to satellites.
|
||
* For installations meeting IMO GMDSS requirements, a minimum operating lifetime of 48 hours (EPIRB) and 168 hours
|
||
(for Float Free VDR capsules) at any temperature throughout the specified operating temperature range is necessary. The
|
||
minimum operating lifetime for an ELT (DT) to meet the ICAO GADSS requirement at any temperature throughout
|
||
the specified operating temperature range shall be 370 Minutes. This duration is based on the ICAO standards for
|
||
Extended Diversion Time Operations (EDTO) and the maximum diversion time capability of existing aircraft types,
|
||
as of April 2018.
|
||
|
||
4-4
|
||
|
||
The distress beacon may transmit other radio-locating signals in compliance with appropriate national
|
||
or international standards. The inclusion of any Radio-Locating Signals within a beacon and the
|
||
prioritization of these Radio-Locating Signals is the responsibility of the appropriate national or
|
||
international bodies. The status of the radio-locating transmissions (e.g., operational or
|
||
non-operational) shall be monitored before each beacon satellite transmission and shall be encoded
|
||
in the beacon message as indicated in section 3.2.
|
||
Any such radio-locating device must satisfy all the national performance standards applicable to
|
||
radio-locating devices at the selected frequency.
|
||
Radio-Locating Signals shall not begin transmissions for at least 30 seconds (in order for the as
|
||
equipped status to be transmitted) but shall begin transmission within 5 minutes maximum after
|
||
beacon activation, except (if applicable) AIS signals which shall not be delayed for longer than
|
||
1 minute after beacon activation.
|
||
4.5.4
|
||
Beacon Self-Test Mode
|
||
In the self-test mode beacons shall transmit a 406-MHz signal with digital message encoded in
|
||
accordance with section 3. The content of the self-test message shall always provide the beacon
|
||
ID as defined in section 3.6, except when a Programming Adapter is attached to the beacon, in
|
||
which case it shall comply with section 3.7. The transmitted message shall be spread by a specific
|
||
sequence defined in section 2.2.3.
|
||
The self-test mode or GNSS self-test mode shall not be used for the purposes of repetitive
|
||
automated interrogation of the beacon status. A beacon (e.g., ELT(DT)) may contain a different
|
||
test mode that can be used for repetitive automated interrogation of its status, but operation of the
|
||
beacon in this different test mode shall not result in the transmission of a 406-MHz signal or other
|
||
radio locating signals (if applicable) nor interfere with the normal operation of the beacon.
|
||
4.5.4.1 Nominal Beacon Self-Test Mode
|
||
All beacons shall include a self-test mode of operation, which shall include a Verification of
|
||
Registration function as detailed in section 4.5.8.
|
||
The complete self-test transmission shall be limited to one 406 burst at full power and one burst
|
||
of each radio-locating signal at full power with a maximum duration of 3 sec each regardless of
|
||
the duration of activation of the self-test control. The radiolocating signals shall be transmitted
|
||
first in order of ascending frequency followed lastly by the 406 MHz satellite signal.
|
||
The self-test mode shall be activated by either a separate switch to that used to activate the beacon
|
||
or cancel transmissions; or a separate switch position of the beacon activation switch.
|
||
The duration of the self-test cycle shall not exceed 15 seconds.
|
||
The self-test function shall perform an internal check and provide a distinct indication that:
|
||
a) the self-test mode has been initiated within 2 seconds of activation;
|
||
|
||
4-5
|
||
|
||
b) RF power is being emitted at 406 MHz and the radio locating frequencies, if applicable;
|
||
and
|
||
c) the internal check has passed successfully within 15 seconds of activation; or
|
||
d) any of the items a), b) or c) has failed the self-test within 15 seconds of activation;
|
||
e) for RLS Type 1 automatic acknowledgment capable beacons an indication if the beacon
|
||
has RLS functionality enabled; and
|
||
f) for RLS Type 3 TWC (message) capable beacons an indication if the beacon has RLS
|
||
Type 3 TWC (message) functionality enabled.
|
||
The content of the encoded position data field of the self-test message shall be the default values
|
||
specified in section 3.
|
||
The beacon shall be designed to ensure an automatic termination of the self-test mode
|
||
immediately after completion of the self-test cycle and indication of the self-test results.
|
||
4.5.4.2 GNSS Beacon Self-Test Mode
|
||
In addition to the mandatory regular self-test, beacons may optionally include a GNSS self-test
|
||
mode.
|
||
ELT(DT) beacons shall include a GNSS self-test mode resulting in a single burst transmission.
|
||
Beacons which provide for the transmission of an encoded position in a GNSS self-test message
|
||
shall:
|
||
a) activate the GNSS self-test mode via a distinct operation from the normal self-test mode,
|
||
but the GNSS self-test mode may be activated via the same self-test switch(es) or
|
||
operation provided that it shall require a separate, deliberate action by the user that
|
||
would limit the likelihood of inadvertent GNSS self-test activation, and shall not result
|
||
in more than a single self-test burst regardless of the duration of activation of the GNSS
|
||
self-test control;
|
||
b) provide for that in the case of internal GNSS receivers powered by the primary* beacon
|
||
battery the number of GNSS self-tests shall be limited by the beacon design to prevent
|
||
inadvertent battery depletion;
|
||
c) provide a distinct indication that the GNSS self-test is underway and to register
|
||
successful completion or failure of the GNSS self-test;
|
||
d) provide, for beacons with internal navigation devices powered by the primary beacon
|
||
battery, a separate distinct indication that the limited number of GNSS self-test
|
||
opportunities have been attained;
|
||
e) ensure that the duration of the GNSS self-test is limited to a maximum time duration set
|
||
by the manufacturer, noting that:
|
||
- in the case where the beacon fails to encode the location into the 406 MHz message
|
||
within this time limit the GNSS self-test shall cease, the beacon shall indicate a
|
||
* The primary battery is the battery which is powering the 406 MHz function.
|
||
|
||
4-6
|
||
|
||
GNSS self-test failure and may transmit a single self-test burst with default location
|
||
data (as described in Section 3),
|
||
- in the case where the beacon encodes the location into the 406 MHz message within
|
||
this time limit the GNSS self-test shall cease at that time (or before the time limit is
|
||
reached), indicate a GNSS self-test pass and transmit a single self-test burst
|
||
containing the valid location data; and
|
||
f) for beacons that provide a GNSS self-test using both the internal navigation device and
|
||
the external navigation interface:
|
||
-
|
||
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.
|
||
4.5.5
|
||
Encoded Position Data\*
|
||
4.5.5.1 General
|
||
Beacon position data, obtained from a navigation device internal, integral† or external to the
|
||
beacon, shall be encoded in the beacon message, if available. Beacons that do not provide
|
||
encoded position data shall indicate this within the message and shall transmit default location
|
||
data as defined in section 3. Beacons capable of encoding position data shall comply with all the
|
||
appropriate parts of section 4.5.5.
|
||
•
|
||
Section 4.5.5.2 applies to all beacons with an internal navigation device except
|
||
ELT(DT)s
|
||
•
|
||
Section 4.5.5.3 applies only to ELT(DT)s which must always include an internal
|
||
navigation device
|
||
•
|
||
Section 4.5.5.4 applies to all beacons (including ELT(DT)s) which include an external
|
||
navigation device input.
|
||
Thus, for example if an EPIRB has an internal navigation device and an external navigation
|
||
device input then it shall comply with both sections 4.5.5.2 and 4.5.5.4.
|
||
All times are measured since beacon activation unless specified otherwise.
|
||
Encoded position message content shall be as defined in section 3.
|
||
ELT (DT)s shall incorporate an internal navigation device and may incorporate an interface to
|
||
an external navigation device. The initial position transmitted in the first burst may be obtained
|
||
* ELTs carried to satisfy the requirements of ICAO Annex 6, Parts I, II and III shall operate in accordance with ICAO
|
||
Annex 10.
|
||
† An integral navigation device is a part of the beacon system but may be separate to the beacon transmitter and shall
|
||
comply with the performance requirements of an internal navigation device.
|
||
|
||
4-7
|
||
|
||
from either the internal navigation device or from the external navigation device input.
|
||
Subsequently all future positions shall only be obtained from the internal navigation device.
|
||
The transmission in the beacon message of this external source of position is only subsequently
|
||
allowed if the internal GNSS receiver is not able to produce a valid encoded position less than 1
|
||
second before the burst. If position data is available from both sources, within 1 second before
|
||
the burst, then the location produced by the internal GNSS receiver has the priority over the
|
||
external source of data\*.
|
||
Operation or failure of an internal or external navigation device providing position data to the
|
||
beacon shall not degrade other aspects of beacon performance.
|
||
4.5.5.2
|
||
Internal Navigation Device
|
||
An internal navigation device shall be capable of global operation and should conform to an
|
||
applicable international standard.
|
||
An internal navigation device shall incorporate self-check features to ensure that erroneous
|
||
position data is not encoded into the beacon message. The self-check features shall prevent
|
||
position data from being encoded into the beacon message unless minimum performance criteria
|
||
are met. These criteria could include the proper internal functioning of the device, the presence
|
||
of a sufficient number of navigation signals, and sufficient quality of the signals.
|
||
Internal navigation device cold start shall be forced at every beacon activation. Cold start refers
|
||
to the absence of time dependent or position dependent data in memory, which might affect the
|
||
acquisition of the GNSS position.
|
||
With a clear view of the sky the distance between the static horizontal position provided by the
|
||
navigation device, at the time of the position update, and the actual navigation device static
|
||
position shall not exceed 30 m 95% of the time. The distance between the static vertical position
|
||
(altitude) provided by the navigation device, at the time of the position update, and the actual
|
||
navigation device static position shall not exceed 50 m 95% of the time.
|
||
The objective should be to provide a position with low geometric dilution of precision, however
|
||
if the only position available (whether this be 2D or 3D) has a high dilution of precision then this
|
||
position should be provided rather than being discarded in favour of not providing a position at
|
||
all.
|
||
The encoded position data shall be provided in a format compatible with the International
|
||
Terrestrial Reference System (ITRS) and its reference frames (ITRF) such as the WGS 84 or
|
||
GTRF. The difference between the chosen format and the ITRF shall not exceed 10 cm.
|
||
* The internal navigation device or even the entire ELT(DT) may be powered by an external source prior to its activation
|
||
in order to comply with this requirement, but must be powered solely by the ELT(DT)’s internal power source
|
||
immediately after activation of the ELT(DT). The ELT(DT) shall have its own integral or internal power source.
|
||
However, when available, the ELT(DT) may use aircraft electrical power source during transmission after its
|
||
activation. ELT(DT) system minimum duration of continuous operation shall however be demonstrated with the
|
||
ELT(DT) own internal/integral power source.
|
||
|
||
4-8
|
||
|
||
The navigation device shall provide an indication of the potential error of each provided position
|
||
in terms of Horizontal Dilution of Precision (HDOP) and Vertical Dilution of Precision (VDOP)
|
||
and shall encode the respective DOP values in the message in accordance with section 3.3.
|
||
The navigation device shall provide the following additional information for each provided
|
||
position whether it has no Fix or was operating in 2D or 3D Mode and shall encode this data in
|
||
the message in accordance with section 3.3. If a valid 3D location (including height) is available
|
||
then this shall be transmitted, however if a 3D location is not available but a valid 2D location is
|
||
then this shall be transmitted instead. In this instance when the location changes from 3D to 2D
|
||
(or No Fix) the altitude shall be reset to the default value until such time as a 3D fix with altitude
|
||
is available.
|
||
First provision of encoded location within a transmitted message shall occur no later than the first
|
||
burst after 2 minutes from beacon activation with a 95% probability, with a clear view of the sky.
|
||
The Internal navigation device shall operate continuously during the initial 30 minutes period
|
||
following beacon activation. During this period the beacon shall acquire fresh position
|
||
information immediately prior to every transmission burst unless this becomes impractical due
|
||
to navigation signal constraints.
|
||
During the first 30 minutes after beacon activation the location transmitted by the beacon shall
|
||
always be the latest information provided by the navigation device. This applies even if the
|
||
quality of the location has become worse. The navigation device shall provide an updated
|
||
location at least every 1 second and the update immediately prior to the next scheduled
|
||
transmission burst shall be encoded and transmitted by the beacon within 1 second of receipt.
|
||
After the first 30 minutes, the navigation device shall make subsequent attempts to obtain an
|
||
initial location, or an updated location, as applicable, at least every 15 minutes from the end of
|
||
the last update attempt, for the remainder of the manufacturer declared minimum operating
|
||
lifetime of the beacon\*. Whenever an updated location is obtained, it shall be encoded into the
|
||
next available beacon message to be transmitted.
|
||
Whenever the beacon has fresh encoded location data at the start of a burst, this shall be indicated
|
||
within the message by zeroing the “time from last encoded location” field as required by section
|
||
3.3.
|
||
If no position is available, then the beacon shall transmit either default position data (if it has no
|
||
position) or the last received position until such time as a fresh position is available. In addition,
|
||
the beacon shall compute the elapsed time since the last position update (or since activation) to
|
||
an accuracy of 10 seconds and provide this in the transmitted message to a resolution of the
|
||
nearest minute as required by section 3.3.
|
||
Each location update attempt shall require the navigation device to be operational for a period of
|
||
at least 90 seconds or until a valid location has been obtained whichever is shortest.
|
||
* For EPIRBs used as the float-free recording medium for VDRs, after at least 48 hours, the update rate can be extended
|
||
to a maximum of once every 60 minutes for the remainder of the operating lifetime if required.
|
||
|
||
4-9
|
||
|
||
4.5.5.2.1
|
||
ELTs with an Internal Navigation Device Powered Externally Prior to Activation
|
||
If an internal navigation device cold start is forced upon application of external power to the internal
|
||
navigation device, and does not cold start upon beacon activation, then the requirements of this section
|
||
apply.
|
||
For ELTs with externally powered internal navigation devices, which are continuously operational
|
||
prior to beacon activation, and are designed to obtain and update position data from an internal GNSS
|
||
receiver and retain position data in the beacon memory, prior to the beacon activation, the internal
|
||
navigation device cold start shall be forced on each initial power up of the internal navigation device.
|
||
To facilitate the provision of position data prior to activation, the ELT shall attempt to update the
|
||
position retained in memory from the internal navigation device at intervals of no longer than 1
|
||
second. If, after ELT activation, current navigation data is not available, then the ELT shall transmit
|
||
its first and subsequent 406-MHz messages with the last position available prior to ELT activation (as
|
||
retained in beacon memory for this purpose) until a new position is available.
|
||
The ELT shall not use external power to power the internal navigation device once activated.
|
||
After activation the beacon shall only be powered by the internal battery, apart from external interfaces
|
||
to/from the beacon approved for use with the beacon (e.g., Remote Control Panel, ARINC interface,
|
||
etc.).
|
||
4.5.5.3
|
||
Internal Navigation Device ELT(DT)s only
|
||
An internal navigation device shall be capable of global operation and should conform to an
|
||
applicable international standard.
|
||
An internal navigation device shall incorporate self-check features to ensure that erroneous
|
||
position data is not encoded into the beacon message. The self-check features shall prevent
|
||
position data from being encoded into the beacon message unless minimum performance criteria
|
||
are met. These criteria could include the proper internal functioning of the device, the presence
|
||
of a sufficient number of navigation signals, and sufficient quality of the signals.
|
||
The ELT (DT) navigation system shall be cold-started on initial power-up (ELT(DT) in ARMED
|
||
mode see section 4.5.6.1) but shall not be cold started if the ELT(DT) is subsequently activated
|
||
or between ELT(DT) transmissions. Cold start refers to the absence of time dependent or position
|
||
dependent data in memory, which might affect the acquisition of the GNSS position.
|
||
With a clear view of the sky the distance between the static horizontal position provided by the
|
||
navigation device, at the time of the position update, and the actual navigation device static
|
||
position shall not exceed 30 m 95% of the time. The distance between the static vertical position
|
||
(altitude) provided by the navigation device, at the time of the position update, and the actual
|
||
navigation device static position shall not exceed 50 m 95% of the time. The objective should be
|
||
to provide a position with low geometric dilution of precision, however if the only position
|
||
available (whether this be 2D or 3D) has a high dilution of precision then this position should be
|
||
provided rather than being discarded in favour of not providing a position at all.
|
||
|
||
4-10
|
||
|
||
The encoded position data shall be provided in a format compatible with the International
|
||
Terrestrial Reference System (ITRS) and its reference frames (ITRF) such as the WGS 84 or
|
||
GTRF. The difference between the chosen format and the ITRF shall not exceed 10 cm.
|
||
The navigation device shall provide the following additional information for each provided
|
||
position whether it has no Fix or was operating in 2D or 3D Mode and shall encode this data in
|
||
the message in accordance with section 3.3. If a valid 3D location (including height) is available
|
||
then this shall be transmitted, however if a 3D location is not available but a valid 2D location is
|
||
then this shall be transmitted instead. In this instance when the location changes from 3D to 2D
|
||
(or No Fix) the altitude shall be reset to the default value until such time as a 3D fix with altitude
|
||
is available.
|
||
First provision of encoded location within a transmitted message shall occur within 5 seconds\*
|
||
after ELT(DT) activation with a 95% probability, with a clear view of the sky. If, after the
|
||
ELT(DT) activation, current navigation data is not available, then the ELT(DT) shall transmit its
|
||
first and subsequent 406-MHz messages with the last position available prior to the ELT(DT)
|
||
activation (which shall be retained in beacon memory for this purpose). The position provided in
|
||
the transmitted message shall also contain the UTC time that relates to when the position was
|
||
obtained in accordance with Table 3.4 “Time of Last Encoded Location” (to an accuracy of 1
|
||
second), until either navigation data becomes available or 24 hours has elapsed. To facilitate the
|
||
provision of position data prior to activation, the ELT(DT) shall attempt to update the position
|
||
retained in memory from either the internal navigation device or the external navigation input at
|
||
intervals of no longer than 2 seconds. If no position was available prior to the ELT(DT)
|
||
activation, or if 24 hours have elapsed without an updated position becoming available, the
|
||
ELT(DT) shall transmit the default position until such time, as navigation data becomes available
|
||
from an internal GNSS receiver or, if applicable, from an external navigation device.
|
||
The Internal navigation device shall operate continuously during the initial 30 minutes period
|
||
following beacon activation, subsequently each location update attempt prior to every 406 MHz
|
||
transmission shall require the navigation device to be operational for a period of at least 15
|
||
seconds or until a valid location has been obtained whichever is shortest. If the internal navigation
|
||
device fails to provide a location during the two location update attempts immediately previous
|
||
to the current location update attempt, then the current update attempt shall be extended to a
|
||
minimum duration of 25 seconds scheduled immediately prior to the next planned location
|
||
update. After the first hour following beacon activation, the internal navigation device shall also
|
||
be operational for a period of at least 180 seconds once every hour thereafter, to ensure that the
|
||
device can download any necessary navigation message updates.
|
||
ELT(DT)s shall attempt to acquire fresh position information prior to every 406 MHz
|
||
transmission (unless this becomes impractical due to navigation signal constraints) for the entire
|
||
operating lifetime of the ELT (DT) and shall encode the latest position obtained within less than
|
||
1 second prior to each burst into that transmission. If an updated position is not available within
|
||
1 second immediately prior to every 406 MHz transmission, then the ELT(DT) shall transmit the
|
||
latest position that it has, unless this position is more than 24 hours old, in which case it shall
|
||
revert to transmitting the default position until such time as an updated position is available.
|
||
* The ELT(DT)’s internal navigation device or even the entire ELT(DT) may be powered by an external source prior
|
||
to its activation in order to comply with this requirement.
|
||
|
||
4-11
|
||
|
||
ELT (DT)s shall provide the UTC time of the last encoded location to an accuracy and resolution
|
||
of 1 second and provide this in the transmitted message as required by section 3.3, Table 3.4. If
|
||
UTC is not available for an encoded location, or if the time of the last encoded location is over
|
||
24 hours old then the ELT(DT) shall transmit default data.
|
||
4.5.5.4
|
||
External Navigation Device Input
|
||
It is recommended that beacons, which are designed to accept data from an external navigation
|
||
device, be compatible with an applicable international standard, such as the IEC Standard on
|
||
Digital Interfaces (IEC Publication 61162) and that any difference between the ITRS and the
|
||
datum employed by the receiver should be less than 10 cm. The input should be able to provide
|
||
all relevant position data as required by sections 3.2 and 3.3, this includes horizontal position,
|
||
vertical position (altitude), time of this position to an accuracy of 1 second, HDOP, VDOP and,
|
||
No Fix or 2D or 3D operating. Examples of suitable Maritime IEC 61162-1 sentences to achieve
|
||
this objective include GNS and GSA and Aviation ARINC 429 labels to achieve this objective
|
||
include Label 101, 102, 310, 311 etc. The beacon user manual shall include details of the
|
||
acceptable interfaces.
|
||
In addition to providing horizontal position and altitude the external navigation input shall
|
||
provide an indication of the potential error of each provided position in terms of Horizontal
|
||
Dilution of Precision (HDOP) and Vertical Dilution of Precision (VDOP) and shall encode the
|
||
respective DOP values in the message in accordance with section 3.3, except for ELT(DT)s
|
||
transmitting Rotating Field \#1 as this field does not include provision for HDOP or VDOP.
|
||
The external navigation input shall indicate for each provided position whether it has no Fix or
|
||
was operating in 2D or 3D Mode and the beacon shall encode this data in the message in
|
||
accordance with section 3.3. If a valid 3D location (including height) is available then this shall
|
||
be transmitted, however if a 3D location is not available but a valid 2D location is then this shall
|
||
be transmitted instead.
|
||
In static conditions the distance between the horizontal position provided by the external
|
||
navigation input, at the time of the position update, and the position transmitted by the beacon
|
||
shall not exceed 20 m. The distance between the vertical position (altitude) provided by the
|
||
external navigation input, at the time of the position update, and the position transmitted by the
|
||
beacon shall not exceed 40 m.
|
||
First provision of encoded location within a transmitted message shall occur within 5 seconds
|
||
with navigation data available at the external navigation device input.
|
||
During the first 30 minutes after beacon activation the location transmitted by the beacon shall
|
||
always be the latest information provided by the external navigation input. This applies even if
|
||
the quality of the location has become worse. The external navigation input shall provide an
|
||
updated location at least every 1 second and the update immediately prior to the next scheduled
|
||
transmission burst shall be encoded and transmitted by the beacon within 1 second of receipt.
|
||
After the first 30 minutes, the beacon shall access the external navigation input prior to every
|
||
transmission and shall encode the position, if available, into the next transmitted burst. Whenever
|
||
the beacon has fresh encoded location data at the start of a burst, this shall be indicated within
|
||
the message by zeroing the “time from last encoded location” field (except for ELT(DT)s) as
|
||
|
||
4-12
|
||
|
||
required by section 3.3, Table 3.3. ELT(DT)s shall include the UTC time of the last encoded
|
||
location as required by section 3.3, Table 3.4.
|
||
If no position is available, then the beacon shall transmit either default position data (if it has no
|
||
position) or the last received position until such time as a fresh position is available. In addition,
|
||
the beacon shall compute (except for ELT(DT)s) the elapsed time since the last position update
|
||
(or since activation) to an accuracy of 10 seconds and provide this in the transmitted message to
|
||
a resolution of the nearest minute as required by section 3.3, Table 3.3.
|
||
If a beacon designed to operate with an external position source is installed in a configuration
|
||
which does not supply any or all of the expected GNSS data (e.g., position, status, etc.), then the
|
||
beacon should transmit default data for all of the missing data items. Note: This could occur in
|
||
the installation of an ELT in an aircraft which cannot provide any or all of the expected GNSS
|
||
data due to limitations of the installation.
|
||
4.5.6
|
||
Beacon Activation
|
||
Beacons shall have a means of manual activation and deactivation and may optionally also include
|
||
means of automatic activation (for ELT (DT)s see section 4.5.6.1 below).
|
||
The beacon shall be designed to prevent inadvertent activation.
|
||
Within 1 second after activation, the beacon shall provide a visual indication that it has been activated.
|
||
For beacons which can be remotely activated, there shall be an indicator on both the remote activation
|
||
device and the beacon.
|
||
The beacon (except ELT(DT)s) shall track time since activation to an accuracy of 10 minutes and
|
||
provide this in appropriate transmitted messages to a resolution of the nearest one hour as required
|
||
by section 3.3.
|
||
After activation the beacon shall commence transmissions in accordance with section 2.2.1, thereafter
|
||
the beacon shall not transmit more frequently than the minimum burst transmission interval (as
|
||
defined in section 2.2.1) regardless of the duration of activation of any controls or the activation of
|
||
any combination of controls. Once activated and transmitting, the activation of any control other than
|
||
the ‘Off’, ‘Reset’ or ‘Cancellation’ controls shall not stop the beacon from transmitting.
|
||
4.5.6.1 ELT(DT) Modes of Operation
|
||
ELT(DT)s shall allow for automatic and manual means of activation. All ELT(DT)s shall
|
||
include a means of receiving information from the aircraft to determine whether the ELT(DT) is
|
||
on the ground or in the air and shall take this status into account when activated. ELT(DT)s shall
|
||
also have means of deactivation by the same means of activation which shall be followed by a
|
||
cancellation message sequence.
|
||
Standalone ELT(DT)s (i.e., those that do not comply with either sections 4.5.15 or 4.5.16) should
|
||
function as follows. National Administrations or Aviation Authorities may define additional
|
||
functionality.
|
||
Table 4.1: Expected Stand-alone ELT(DT) Behaviour
|
||
|
||
4-13
|
||
|
||
Activation Criteria
|
||
Activation Means
|
||
Manual
|
||
Avionics
|
||
On-Ground
|
||
406 Distress Tracking
|
||
(DT) sequence and
|
||
121.5 optional if
|
||
available
|
||
Avionics Activation
|
||
Disabled
|
||
In-Air
|
||
406 DT sequence only
|
||
preferred
|
||
121.5 optional if
|
||
available
|
||
406 DT sequence only
|
||
If the beacon is activated in one aircraft state (e.g., in-flight) and the aircraft transitions to another
|
||
state (e.g., on-ground) while the beacon is still transmitting, the beacon transmission
|
||
characteristics should behave as indicated for the new aircraft state as per the table above.
|
||
Consequently:
|
||
•
|
||
If the ELT(DT) has been automatically activated by the triggering system\*, it shall
|
||
only be de-activated by the same means.
|
||
•
|
||
If the ELT(DT) has been automatically activated by the beacon sensors†, it shall only
|
||
be deactivated by manually resetting the beacon.
|
||
•
|
||
If the ELT(DT) has been manually activated (i.e., from the cockpit), it shall only be
|
||
manually de-activated.
|
||
•
|
||
If the ELT(DT) has been activated by any combination of activation means, it can
|
||
only be de-activated once each activation means has been deactivated.
|
||
•
|
||
Bits 186 to 189 of the ELT(DT) message shall indicate the most recent means of
|
||
activation. If one means of activation is removed but others remain then Bits 186 to 189
|
||
shall revert to indicating the previous most recent means of activation.
|
||
Thus, an ELT(DT) shall as a minimum have the following modes of operation:
|
||
OFF – The complete ELT(DT) (and any related components) is/are unpowered
|
||
ARMED – The ELT(DT) or some parts of it may if required be powered up, such that
|
||
when it is activated by an automatic triggering system‡ or manually, it can start
|
||
transmitting within 5 seconds and meet the requirements in this specification for
|
||
ELT(DT)s including the provision of encoded location in the first burst. However, until
|
||
the ELT(DT) is activated there are no outputs from the ELT(DT) at all (e.g., no 406 MHz
|
||
or Homing Signal transmissions)
|
||
ON – The ELT(DT) has been either activated by an automatic triggering system and/or
|
||
has been manually activated and is transmitting 406 MHz signals in full compliance with
|
||
the ELT(DT) requirements in this specification.
|
||
* For example, triggered by an external source in compliance with EUROCAE ED-237.
|
||
† For example, triggered by G-switch / deformation.
|
||
‡ For example, triggered in compliance with EUROCAE ED-237 or by G-switch / deformation.
|
||
|
||
4-14
|
||
|
||
RESET – The ELT(DT) is deactivated and ceases transmitting distress alerts and instead
|
||
transmits a sequence of cancellation messages as defined by Section 4.5.7. Upon
|
||
completion of the cancellation message sequence, the ELT(DT) reverts to the ARMED
|
||
condition. The ELT(DT) can only be deactivated as defined above.
|
||
4.5.7
|
||
Beacon Activation Cancellation Function
|
||
The beacon shall include a beacon activation cancellation function. This shall be a separate function
|
||
from the on/off capability of the beacon for all beacons except ELT(AD), ELT(AF), and ELT(DT).
|
||
The cancellation function shall be protected from inadvertent activation and shall be triggered by two
|
||
simple and independent actions that provide confidence in intentional cancellation action by the user.
|
||
The beacon shall provide an indication of the transmission of cancellation messages.
|
||
When the beacon is deactivated with the cancellation function, the beacon shall transmit the first
|
||
cancellation messages within 5 seconds, and transmit a total of 10 identical cancellation messages at
|
||
intervals of 10 seconds ±0.5 seconds, after which time the beacon shall cease transmitting. In the case
|
||
the beacon is activated (e.g., triggered) during the cancellation sequence, the beacon shall terminate
|
||
the cancellation transmission sequence and reinitiate the alert sequence per section 2.2.1 (unless
|
||
otherwise specified in this section).
|
||
In the case of an RLS Type 3 TWC beacon, if the user selects and confirms to cancel the alert from
|
||
the question/answer dataset, then the beacon activation cancellation function shall be automatically
|
||
triggered.
|
||
When the beacon activation cancellation function is initiated it shall comply with section 3.4,
|
||
Table 3.1 and Table 3.9.
|
||
4.5.7.1
|
||
Additional Requirements for ELT(AD), ELT(AF) and ELT(DT) Beacons
|
||
For ELT(AD), ELT(AF), and ELT(DT) beacons, the cancellation transmission sequence shall
|
||
start when either:
|
||
•
|
||
the beacon is active (ON mode), and the user turns the beacon off (OFF mode) from the
|
||
front panel on the beacon, or
|
||
•
|
||
the beacon is active (ON mode), and an automatic or manual RESET is initiated,
|
||
provided no other activation sources are present.
|
||
For ELT (DT)s the cancellation function shall include a means of automatic cancellation from
|
||
the same source(s) as the aircraft automatic activation.
|
||
4.5.7.2
|
||
Additional Requirements for ELT(AP) Beacons
|
||
For ELT(AP) beacons, when connected to the remote control and indicator panel (i.e., when
|
||
mounted in the aircraft), the cancellation message sequence shall be initiated whenever a beacon
|
||
is deliberately turned off or reset provided no other activation sources are present (thus overriding
|
||
the cancellation function on the ELT unit itself).
|
||
For ELT(AP) beacons, when not connected to the remote control and indicator panel (i.e., when
|
||
external to the aircraft), the cancellation message sequence shall only be initiated when the
|
||
cancellation function on the ELT unit is enabled.
|
||
|
||
4-15
|
||
|
||
4.5.7.3
|
||
Additional Requirements for all other Beacons
|
||
For all other beacons, the cancellation function shall only be activated through a dedicated
|
||
control.
|
||
Manual operation of the cancellation function shall only result in the transmission of a set of
|
||
cancellation messages when either the beacon is active and transmitting distress alerts or when
|
||
the cancellation function is activated within 180 seconds of a previously activated beacon having
|
||
been turned off, deactivated or reset.
|
||
4.5.8
|
||
Verification of Registration
|
||
See footnote.\*
|
||
4.5.9
|
||
RLS Functions
|
||
If a beacon is equipped with a Return Link Service (RLS) functionality and is configured to transmit
|
||
an RLS Rotating Field, it shall meet the following additional requirements.
|
||
4.5.9.1 RLS GNSS Receiver
|
||
The RLS beacon shall contain an internal GNSS Receiver capable of receiving and decoding
|
||
Return Link Messages (RLMs) from a Cospas-Sarsat recognised Return Link Service Provider
|
||
(RLSP) and of providing these messages to the beacon in an IEC 61162-1 RLM compliant
|
||
sentence or an equivalent proprietary RLM sentence defined by the GNSS receiver manufacturer.
|
||
If the GNSS receiver is capable of processing signals from only one GNSS constellation, this
|
||
shall be the associated RLS provider’s constellation, and satellites should be tracked above 5
|
||
degrees of elevation.
|
||
If the GNSS receiver is capable of processing signals from several GNSS constellations
|
||
(multi-constellation GNSS receiver), such a receiver shall prioritize the reception from satellites
|
||
of the GNSS constellation associated with the RLS provider above 5 degrees of elevation over
|
||
other GNSS constellations.
|
||
The following Return Link Messages have been defined by Cospas-Sarsat to date:
|
||
•
|
||
RLM Type 1 Automatic Acknowledgement – An automated response that simply
|
||
acknowledges receipt of the RLS request by the System.
|
||
•
|
||
RLM Type 3 Two-way Communication (message) – a return link message (RLM) that
|
||
supports the exchange and acknowledgement of information between the beacon user
|
||
and SAR Authorities using pre-defined questions, answers or instructions.
|
||
* C/S G.008 Section 3.13 describes an operational beacon requirement to design the beacon such that the registration
|
||
status of the beacon is displayed to the beacon user. The registration status shall remain valid for a period of two years
|
||
and the beacon shall be designed such that the self-test function indicates by default that the beacon is not
|
||
registered. National Administrations have a variety of registration renewal requirements and methods for registration
|
||
verification. The lack of a common approach makes it difficult to identify a specific specification to achieve the
|
||
requirement at this time. It's possible that in the future that a common approach would be identified, but until such
|
||
time, compliance with this requirement is not met by SGBs in C/S T.018.
|
||
|
||
4-16
|
||
|
||
The definition of the Type 1 RLM message content included as part of the Galileo L1 navigation
|
||
message is defined in the Galileo Open Service Public Signal in Space ICD Issue 1.3.
|
||
The definition of the Type 3 RLM message content included as part of the Galileo L1 navigation
|
||
message is defined in the Galileo Open Service Public Signal in Space ICD Issue TBD.
|
||
4.5.9.2
|
||
RLS Type 1 GNSS Receiver Operation
|
||
4.5.9.2.1
|
||
Operation Cycle
|
||
In addition to the beacons normal GNSS receiver operating cycle as defined in section
|
||
4.5.5.2 or as defined by the beacon manufacturer if the receiver is designed to be active
|
||
more frequently than those requirements, the RLS Type 1 automatic acknowledgement
|
||
beacon shall:
|
||
a) when encoded with RLS functionality (i.e., transmitting an RLS Rotating
|
||
Field) maintain the GNSS receiver in an active mode of operation such that it
|
||
can continuously check for receipt of an RLM message and Coordinated
|
||
Universal Time (UTC), for a minimum period of 30 minutes after beacon
|
||
activation, or until a valid RLM message is acquired, or until the beacon is
|
||
deactivated, whichever occurs first;
|
||
b) as soon as possible determine UTC from the GNSS receiver and maintain a
|
||
clock for at least 6 hours from the time the beacon was first activated, to an
|
||
accuracy of better than three seconds (once UTC has been acquired) or until
|
||
the beacon is deactivated (if UTC is not acquired see (e) below);
|
||
c) if an RLM message has not been received within the first 30-minute period,
|
||
then at the end of this time, utilize UTC time to next activate the GNSS receiver\*
|
||
at the next occurrence of UTC Moffset† minutes to check for receipt of an RLM,
|
||
for a minimum period of 15 minutes, or until an RLM message is acquired
|
||
(e.g., if the first 30-minute period ended at 02:29 and Moffset is 15 minutes, then
|
||
next activate the GNSS receiver at 03:15, or if Moffset is 44 minutes, then next
|
||
activate the GNSS receiver at 02:44);
|
||
d) then during each subsequent hour reactivate the GNSS receiver to check for
|
||
receipt of an RLM for a minimum period of 15 minutes at Moffset minutes, with
|
||
0 ≤ Moffset ≤ 59, past the hour until either an RLM message is received or 6
|
||
hours has elapsed since the beacon was activated;
|
||
e) if UTC is not available after the first 30 minutes the beacon shall attempt to
|
||
establish UTC using the timings detailed in sections 4.5.5.2. If UTC is then
|
||
established the beacon shall continue as per c) and d) above from the next
|
||
occurrence of UTC Moffset minutes; and
|
||
* There is no specific requirement to deactivate the GNSS receiver between position updates so the “next activation”
|
||
may simply consist of ensuring that the GNSS receiver remains on at the start of this period. The GNSS receiver may
|
||
have been previously activated due to a required GNSS position update and not as a result of the Moffset timing.
|
||
† Note that in between Moffset activations the GNSS receiver must also comply with the requirements in section 4.5.5.2.
|
||
|
||
4-17
|
||
|
||
f) once an RLM message is received, or after 6 hours has elapsed since beacon
|
||
activation, whichever is sooner, the beacon shall revert to the GNSS timings
|
||
in sections 4.5.5.2.
|
||
For instance, if the beacon is activated at 03.17h UTC, then the GNSS receiver would
|
||
remain active until at least 03.47h UTC or until an RLM message is acquired if sooner,
|
||
or the beacon is deactivated if it is deactivated before that time. If an RLM message is
|
||
acquired within this period, then the beacon reverts to the GNSS timings in section
|
||
4.5.5.2. If an RLM message is not acquired then it would reactivate at the next occurrence
|
||
of Moffset past the hour and remain active until at least Moffset+15, or until an RLM message
|
||
is acquired, or the beacon is deactivated and it would then reactivate again during the next
|
||
hour at Moffset until Moffset+15, etc. The scheme continues as above until an RLM message
|
||
is acquired, or 6 hours has elapsed since beacon activation, that is in this example until
|
||
09.17h UTC, at which time if an RLM wasn’t acquired earlier the GNSS Receiver reverts
|
||
to the GNSS timings in section 4.5.5.2. If the beacon is deactivated, then the entire
|
||
operation cycle commences again from the beginning when the beacon is next activated.
|
||
NOTE – The Galileo system will cease sending RLM messages back to the beacon, either
|
||
once it receives an RLM Acknowledgement confirming that the RLM has been received
|
||
by the beacon, or 6 hours have elapsed since the first RLS Request message from the
|
||
beacon was received by the RLSP, whichever is the sooner.
|
||
The RLS beacon may contain an internal GNSS receiver capable of receiving and
|
||
decoding other types of acknowledgment RLM following the same operation cycle as the
|
||
one described.
|
||
4.5.9.2.2
|
||
Derivation of Moffset
|
||
The value of Moffset for each beacon is computed from the beacon 15 Hex ID subset of the
|
||
23 Hex ID (see section 3.6). More specifically:
|
||
Moffset = BIN2DEC (CRC16(Beacon 15 Hex ID in Binary)) mod 60
|
||
Where BIN2DEC and CRC16 are functions performing the conversion of binary number
|
||
to a decimal number and the CRC-16 of a stream of bits with polynomial x16+x15+x2+1
|
||
respectively. The CRC-16 is used to obtain a uniform distribution of Moffset. A sample of
|
||
a Moffset calculation and CRC code is shown in Appendix F.
|
||
4.5.9.3
|
||
RLS Indicator
|
||
The beacon shall be provided with an RLS indicator designed to advise the user when a Type 1
|
||
RLS message has been received by the RLSP and the beacon has received a Type 1 Return Link
|
||
Message (RLM). The RLS Indicator shall:
|
||
a) be readily visible to the user when the beacon is operated in all its normal operational
|
||
configurations as declared by the manufacturer;
|
||
b) be clearly visible to the user in direct sunlight;
|
||
c) provide a distinct unique indication;
|
||
d) remain inactive at all times when the beacon message is encoded with any message
|
||
content other than the RLS Rotating Field RF\#2;
|
||
|
||
4-18
|
||
|
||
e) within 5 seconds of the beacon transmitting an initial RLS request, commence
|
||
indication of an RLS request until either a valid RLM Type 1 message is received,
|
||
or the beacon is deactivated, or the beacon battery is expired;
|
||
f) within 5 seconds of the beacon receiving a valid RLM Type 1 message
|
||
acknowledgement, commence a distinct indication until either the beacon is deactivated
|
||
or the beacon battery is expired;
|
||
g) only provide the indication of receipt of an RLS request acknowledgment when the
|
||
received RLM Type 1 message contains the unique 15 Hex ID subset of the 23 Hex ID
|
||
programmed into that beacon and the beacon has validated that this matches its own
|
||
15 Hex ID subset of its 23 Hex ID; and
|
||
h) provide an indication during a self-test if the RLS functionality is enabled in accordance
|
||
with section 4.5.4.1 e).
|
||
4.5.9.4
|
||
Confirmation of a Return-Link Message Receipt
|
||
Upon receipt of an Acknowledgement Type-1 RLM or a Test RLM associated with the beacon
|
||
15 HEX ID, the beacon shall, within 4 minutes and 14 seconds, acknowledge the RLM receipt
|
||
by changing the coding of its message as defined in the RLS rotating field, as described in section
|
||
3.3. Once changed, the RLM beacon feedback field shall no longer be changed until a different
|
||
RLM message is received or beacon is switched off or the beacon battery is depleted.
|
||
Once the beacon has received an Acknowledgement Type-1 RLM or a Test RLM and has
|
||
acknowledged the RLM receipt, the GNSS Receiver shall continue to function as required by
|
||
section 4.5.9.2.1 unless the beacon is coded as a "Type-1 only capable" RLS beacon as defined
|
||
in Table 3.5. In this specific case only, the GNSS receiver may revert to operating as defined
|
||
within sections 4.5.5.2 and 4.5.5.4, taking into account the time elapsed between the moment of
|
||
activation and the moment when the Type-1 RLM message is received, until either the beacon is
|
||
deactivated or the beacon performance ceases to meet specification due to battery depletion.
|
||
Example
|
||
A beacon is activated at 9:00. It transmits emergency signals for 2 hours and 30 minutes. During
|
||
the period from 11:00 to 11:15, it receives a Type-1 RLM Acknowledgement. The GNSS
|
||
receiver could then revert to operating in accordance to the requirements for internal GNSS
|
||
receiver without the RLS capability which specifies that, the navigation device shall attempt
|
||
location update at least once every 15 minutes, for a period of at least 90 seconds, or until an
|
||
updated location is obtained, if sooner.
|
||
4.5.9.5
|
||
RLS Beacon Documentation
|
||
The operation of the RLS Type 1 automatic acknowledgement function shall be clearly explained
|
||
in the User Manual including the performance characteristics of the overall RLS system.
|
||
Suggested minimum text is provided in Annex H.1.
|
||
4.5.10
|
||
Battery Status Indication
|
||
The battery status indication provides the user with an indication prior to beacon activation that the
|
||
battery may be partially depleted and may not operate for the full specified operating lifetime.
|
||
Beacons powered by a rechargeable battery shall automatically provide an indication when the battery
|
||
requires recharging.
|
||
|
||
4-19
|
||
|
||
Beacons powered by a non-rechargeable battery shall provide an indication of battery status during
|
||
self-tests. This shall be a separate indication to the self-test pass/fail indication and the battery status
|
||
indicator shall provide a distinct indication of Potentially Insufficient Battery Energy (PIE). That is,
|
||
that the remaining battery energy may not be sufficient to support the manufacturer declared
|
||
minimum duration of continuous beacon operation.
|
||
4.5.11
|
||
Beacon Labelling
|
||
All beacons shall have the following information durably marked on the exterior of the beacon:
|
||
1)
|
||
Beacon 23 Hex ID (the 23 Hex ID shall be displayed as:
|
||
NNNNNN NNNNNN NNNNNN NNNNN (i.e., a space after every 6 characters))
|
||
2)
|
||
The beacon operating temperature range
|
||
3)
|
||
The minimum duration of continuous operation
|
||
4)
|
||
For RLS-capable beacons, wording on the Beacon Identity label (TAC / Hex ID Label)
|
||
indicating whether the RLS function is enabled or disabled
|
||
5)
|
||
For RLS-capable beacons\*, a label indicating which are the RLS and RLM indicator(s).
|
||
If applicable, all Programming Adapters shall be durably marked with the Beacon Model that it
|
||
relates to and its own unique TAC and Serial Number. In addition there shall be sufficient space to
|
||
provide the Country Code and Vessel ID information that will be programmed into the adapter.
|
||
4.5.12
|
||
Beacon Instruction Manual
|
||
An End User instruction manual shall be made available with all beacons, it shall include the
|
||
information as outlined in the data item description (Annex H.1.10 of document C/S T.021).
|
||
4.5.13
|
||
Beacon Data Requirements
|
||
The manufacturer shall make available for the purposes of supporting the type approval review the
|
||
information as outlined in the data item description (Annex G-3 and Annex H.1 of document C/S
|
||
T.021).
|
||
4.5.14
|
||
External Power Source for ELT(DT)s
|
||
The ELT(DT) shall have its own integral or internal power source. However, when available, all
|
||
ELT(DT)s (including those in compliance with sections 4.5.15 and 4.5.16) may use the external
|
||
aircraft electrical power source. An ELT(DT) shall comply with all applicable requirements
|
||
regardless of power source. In addition, the ELT(DT) performance shall not be impacted by switching
|
||
between power sources.
|
||
* Labeling of the RLS and RLM indicator(s), is independent of the value of bit 42, and whether there is a rotating field #2.
|
||
|
||
4-20
|
||
|
||
4.5.15
|
||
ELT(DT)s Specifically Designed to Withstand a Crash Impact
|
||
4.5.15.1
|
||
Introduction
|
||
Potentially there may be ELT(DT)s that have additional functionality, as defined by National
|
||
Administrations and/or Aviation Authorities, which are designed to:
|
||
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.
|
||
Table 4.2: Expected Crash Survivable ELT(DT) Behaviour
|
||
Activation Criteria
|
||
Activation Means
|
||
Manual
|
||
Automatic Activation
|
||
by the Beacon
|
||
Avionics Trigger
|
||
Unknown aircraft state
|
||
406 Distress
|
||
Tracking (DT)
|
||
sequence only
|
||
preferred,
|
||
homing permitted
|
||
406 Post Crash (PC)
|
||
sequence and homing
|
||
406 DT sequence only
|
||
On-Ground
|
||
406 Distress
|
||
Tracking (DT)
|
||
sequence and
|
||
homing
|
||
406 PC sequence and
|
||
homing
|
||
Avionics Activation
|
||
Disabled
|
||
In-Flight
|
||
406 DT sequence
|
||
only preferred
|
||
homing permitted
|
||
406 PC sequence and
|
||
homing
|
||
406 DT sequence only
|
||
If the beacon is activated in one aircraft state (e.g., in-flight) and the aircraft transitions to another state
|
||
(e.g., on-ground) while the beacon is still transmitting, the beacon transmission characteristics should
|
||
behave as indicated for the new aircraft state as per the table above.
|
||
If there is a conflict between the requirements of this section and any other section of this
|
||
document, then this section takes precedence.
|
||
4.5.15.2
|
||
Beacon Hex ID
|
||
The Hex ID of the ELT(DT) shall not change from when activated in-flight compared to when
|
||
operating after a crash.
|
||
|
||
4-21
|
||
|
||
4.5.15.3
|
||
Burst Transmission Interval (with Crash Detection)
|
||
If the ELT(DT) includes a crash detection function, within 5 seconds of a crash the ELT(DT)
|
||
shall initiate or restart the transmission schedule for an ELT(DT) as if the ELT(DT) had just
|
||
been activated as defined in section 2.2.1 and maintain this transmission schedule for the first
|
||
95 bursts (i.e., approximately 30 minutes) after the crash detection. After burst number 95 (after
|
||
crash detection), transmissions shall then occur at nominally 120 second intervals. The time
|
||
between the start of two successive transmissions (TR) shall be randomized with uniform (flat)
|
||
distribution around the stated nominal value, so that the time intervals between the beginnings
|
||
of two successive bursts (TR) are randomly distributed over ± 5 seconds. After burst number
|
||
95 (after crash detection), the standard deviation over the next 20 successive bursts of TR shall
|
||
be greater than 2.5 seconds. The minimum value of TR observed over the 20 successive bursts
|
||
shall be between 115.0 and 115.2 seconds, the maximum value of TR observed over the 20
|
||
successive bursts shall be between 124.8 and 125.0 seconds.
|
||
Operation after 370 minutes without crash detection
|
||
If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash
|
||
mode or has not been deactivated, then it shall continue transmitting on the same schedule
|
||
(with the GNSS encoded location updated before each transmitted burst) as before the 370-
|
||
minute limit was reached until the ELT(DT) is either deactivated, gets a subsequent “crash”
|
||
indication to transition to the “post-crash” mode, runs out of battery life, or reaches the
|
||
minimum duration of continuous operation, whichever occurs first.
|
||
4.5.15.4
|
||
GNSS Update Rate (after Crash Detection)
|
||
During a 30-minute period after a crash detection, the GNSS encoded location shall be updated
|
||
before each transmitted burst, as per sections 4.5.5.1, 4.5.5.3 and 4.5.5.4 (if applicable).
|
||
Beyond 30 minutes, the GNSS encoded location shall be updated in accordance with section
|
||
4.5.5.1, 4.5.5.2 and 4.5.5.4 (if applicable).
|
||
4.5.15.5
|
||
Duration of Continuous Operation
|
||
The minimum duration of continuous operation under worst case conditions for this type of
|
||
ELT(DT) shall be at least 24 hours at any temperature throughout the specified operating
|
||
temperature range. This is to be understood to mean the total operating time which is a
|
||
combination of the time prior to a crash (minimum of 10 minutes and maximum of 370
|
||
minutes) and post-crash. For the avoidance of doubt, if the ELT(DT) continues to operate after
|
||
370 minutes without crash detection then the 24-hour minimum duration of continuous
|
||
operation does not apply, and might be reduced as a result of the extended operation in this
|
||
pre-crash mode.
|
||
|
||
4-22
|
||
|
||
4.5.15.6
|
||
Homing and Locating Signals
|
||
The inclusion or otherwise of one or more homing signals in the ELT(DT) and the activation
|
||
and duration of any homing signal transmissions are the responsibility of national
|
||
administrations.
|
||
4.5.16
|
||
ELT(DT)s Combined with Automatic ELTs
|
||
4.5.16.1
|
||
Introduction
|
||
Potentially there may be ELT(DT)s that have combined functionality, that is they function as an
|
||
ELT(DT) during a flight, but on detection of an incident perform as an Automatic ELT (either
|
||
an ELT(AD), ELT(AF) or ELT(AP)), such a combined ELT would be required to meet the
|
||
regulatory requirements set by National Administrations and/or Aviation Authorities, for both an
|
||
ELT(DT) and the type of Automatic ELT that it is combined with.
|
||
However, from a Cospas-Sarsat perspective there are certain key functions of such a combined
|
||
ELT that need to be clearly defined related to its performance and operation and the transition
|
||
from an ELT(DT) to either an ELT(AD), ELT(AF) or ELT(AP) as follows.
|
||
ELT(DT)s combined with Automatic ELTs should function as follows.
|
||
Table 4.3: Expected ELT(DT) Combined with Automatic ELT Behaviour
|
||
Activation Means
|
||
Activation Criteria
|
||
Manual
|
||
Automatic Activation
|
||
by the Beacon
|
||
Avionics Trigger
|
||
Unknown aircraft state
|
||
406 Distress
|
||
Tracking (DT)
|
||
sequence only
|
||
preferred,
|
||
homing permitted
|
||
406 SGB sequence
|
||
and homing
|
||
406 DT sequence only
|
||
On-Ground
|
||
406 SGB sequence
|
||
and homing
|
||
406 SGB sequence
|
||
and homing
|
||
Avionics Activation
|
||
Disabled
|
||
In-Flight
|
||
406 DT sequence
|
||
only preferred,
|
||
homing permitted
|
||
406 SGB sequence
|
||
and homing
|
||
406 DT sequence only
|
||
If the beacon is activated in one aircraft state (e.g., in-flight) and the aircraft transitions to another
|
||
state (e.g., on-ground) while the beacon is still transmitting, the beacon transmission
|
||
characteristics should behave as indicated for the new aircraft state as per the table above.
|
||
If there is a conflict between the requirements of this section and any other section of this
|
||
document, then this section takes precedence.
|
||
|
||
4-23
|
||
|
||
4.5.16.2
|
||
Beacon Coding and Beacon Hex ID
|
||
The combined ELT(DT) and Automatic ELT shall transmit the ELT(DT) In-Flight Emergency
|
||
Rotating Field \#1 at all times and shall not change to transmitting the Objective Requirements
|
||
Rotating Field \#0 when the combined device transitions to or is activated as an Automatic ELT.
|
||
The 23 Hex ID shall remain the same regardless of whether the device is operating as an
|
||
ELT(DT) or as an automatic ELT.
|
||
Bit 42 in the combined device message shall remain as “0” indicating that the device is not
|
||
equipped with the RLS capability and shall not change to “1” when the combined device
|
||
transitions to or is activated as an Automatic ELT.
|
||
Bits 138 to 140 in the combined device message shall remain as “011” indicating that the device
|
||
is an ELT(DT) and shall not change to “000” when the combined device transitions to or is
|
||
activated as an Automatic ELT.
|
||
4.5.16.3
|
||
Burst Transmission Interval
|
||
When activated as an ELT(DT) the beacon shall meet the burst repetition requirements for an
|
||
ELT(DT) as defined in section 2.2.1. When activated as an Automatic ELT or if transitioning
|
||
from an ELT(DT) to an Automatic ELT then the combined device shall commence the burst
|
||
repetition requirements for a non-ELT(DT) 406 MHz beacon as defined in section 2.2.1 (i.e.,
|
||
restart the Initial IAMSAR stage transmission schedule).
|
||
Operation after 370 minutes without crash detection
|
||
If, after 370 minutes of in-flight operation, the ELT(DT) has not transitioned to a post-crash mode
|
||
or has not been deactivated, then it shall continue transmitting on the same schedule (with the
|
||
GNSS encoded location updated before each transmitted burst) as before the 370-minute limit
|
||
was reached until the ELT(DT) is either deactivated, gets a subsequent “crash” indication to
|
||
transition to the “post-crash” (Automatic ELT) mode, runs out of battery life, or reaches the
|
||
minimum duration of continuous operation, whichever occurs first.
|
||
4.5.16.4
|
||
System Requirements
|
||
The combined ELT(DT) and Automatic ELT shall meet the more stringent requirements, that
|
||
apply to either part of the device (except where stated otherwise below), specifically:
|
||
a) the combined ELT(DT) and Automatic ELT does not have to meet the requirement for
|
||
90% of measured EIRP values to meet the limits shown at elevation angles below 55
|
||
degrees (but does have to meet the other requirements in section 2.4.2);
|
||
b) the combined device shall comply with both the Temperature Gradient requirements for
|
||
an ELT(DT) and the Temperature Gradient requirements for a regular 406 MHz beacon,
|
||
based upon the declared temperature classes for each part of the device (section 4.2.2);
|
||
c) the combined ELT(DT) shall not be required to track time since activation (since it will
|
||
not be transmitting Rotating Field \#0) (section 4.5.6); and
|
||
|
||
4-24
|
||
|
||
d) the combined ELT(DT) shall comply with the modes of operation for an ELT(DT)
|
||
(section 4.5.6.1).
|
||
4.5.16.5
|
||
Cancellation Message
|
||
The cancellation message shall function as defined in section 4.5.7 while operating as an
|
||
Automatic ELT as well as while operating as an ELT(DT).
|
||
4.5.16.6
|
||
Encoded Position Data and Navigation Device Performance
|
||
While operating as an ELT(DT) the navigation device shall comply with the requirements of
|
||
sections 4.5.5.1, 4.5.5.3 and 4.5.5.4 (if applicable). When operating as an Automatic ELT, that is
|
||
automatically activated, the navigation device shall comply with the requirements of sections
|
||
4.5.5.1, 4.5.5.2 and 4.5.5.4 (if applicable). When operating as an Automatic ELT, that is manually
|
||
activated, the navigation device shall comply with the requirements of sections 4.5.5.1, 4.5.5.3
|
||
and 4.5.5.4 (if applicable), for a period of at least 6 hours and 10 minutes, after which time it shall
|
||
comply with the requirements of sections 4.5.5.1, 4.5.5.2 and 4.5.5.4 (if applicable).
|
||
4.5.16.7
|
||
Duration of Continuous Operation
|
||
The minimum duration of continuous operation under worst case conditions for this type of
|
||
combined ELT shall be a combination of the minimum duration of continuous operation for an
|
||
ELT(DT) (370 minutes) and the minimum duration of continuous operation for a regular 406
|
||
MHz beacon (24 hours), thus resulting in a total of at least 30 hours and 10 minutes.
|
||
For the avoidance of doubt, if the combined ELT continues to operate after 370 minutes without
|
||
crash detection, then the 30 hours and 10 minutes minimum duration of continuous operation
|
||
does not apply and might be reduced as a result of the extended operation in the ELT(DT) mode.
|
||
4.5.16.8
|
||
Class of Operation
|
||
The combined device may, if required, function at different classes of temperature as an
|
||
ELT(DT) or Automatic ELT (e.g., the ELT(DT) part of the device may be specified to operate
|
||
as a Class 1 device, while the Automatic ELT part of the device may be specified to operate as a
|
||
Class 2 device).
|
||
4.5.16.9
|
||
Homing and Locating Signals
|
||
The inclusion or otherwise of one or more homing signals in the combined device and the
|
||
activation and duration of any homing signal transmissions are the responsibility of national
|
||
administrations. The status of the homing signals in the transmitted beacon message shall comply
|
||
with Table 3.1.
|
||
4.5.17
|
||
RLS Type 3 TWC (message) Functionality
|
||
If a beacon is equipped with an RLS Type 3 Two-Way Communication (TWC) (message) functionality
|
||
and is configured to transmit the RLS Type 3 TWC Rotating Field RF\#4, it shall meet the following
|
||
additional requirements.
|
||
|
||
4-25
|
||
|
||
4.5.17.1 RLS Type 3 TWC General Requirements
|
||
a) A TWC beacon shall be provided with a means to visually and legibly display
|
||
Questions, Answers and Instructions (Q/A/I) to an end user (the TWC Beacon User
|
||
Interface) either:
|
||
i. integral to the beacon; or
|
||
ii. separate to the beacon but provided with the beacon; or
|
||
iii. on a third-party device not provided with the beacon but with which the
|
||
beacon can communicate by means of software made available by the
|
||
beacon manufacturer for the third-party device (e.g., an App).
|
||
b) In addition to the visual display, the Q/A/Is may, at the discretion of the beacon
|
||
manufacturer, also be audibly announced to the end user.
|
||
c) If the Q/A/I can be displayed in more than one language then there shall be a means by
|
||
which the beacon user can select their desired language and subsequently change it if
|
||
desired.
|
||
d) The beacon shall display the initial questions according to logic (e.g., decision tree)
|
||
associated with the version of the dataset installed in the beacon/user interface.
|
||
e) The provision of additional Q/A/I languages shall be at the discretion of the beacon
|
||
manufacturer, unless mandated by national regulations.
|
||
f) The beacon or the related device shall store the selected language in memory such that
|
||
when the beacon is activated in a distress it is not necessary to reselect the language.
|
||
g) The beacon or the related device shall contain an approved dataset version of all the
|
||
Q/A/I in at least one language.
|
||
h) The beacon or the related device shall convert the user selected answer(s) from the
|
||
display into the predefined set of binary numbers for transmission in the 406 message
|
||
in accordance with Table 3.7, Figure 4-2 and Figure 4-3.
|
||
i) The beacon or the related device shall translate what it receives as a binary number in
|
||
an RLM into text on the display.
|
||
j) The Q/A/I dataset shall be capable of being updated to the latest version after delivery
|
||
of the beacon to the beacon user.
|
||
k) The beacon user manual shall contain instructions on how to update the dataset to the
|
||
latest version.
|
||
l) The beacon user shall be provided with a visual indication on the beacon when a new
|
||
follow-on question or instruction is first received. An audible indication may also be
|
||
provided in addition to the visual signal.
|
||
m) The visual indication should be reset after the beacon user has accessed the device and
|
||
the beacon has displayed the new follow-on question or instruction.
|
||
n) The beacon or external device shall provide the beacon user with a means by which to
|
||
answer questions and respond to instructions presented to them on the display, by either:
|
||
i. A set of input keys or buttons; or
|
||
ii. A touch sensitive screen
|
||
|
||
4-26
|
||
|
||
o) [The beacon or external device shall provide the beacon user with a means to backtrack
|
||
on an answer to a question [prior to it being transmitted] in case of an incorrect choice
|
||
and to choose an alternative answer to a question.]
|
||
p) The entry method shall not be by vocal means (i.e., spoken responses).
|
||
q) If the beacon user selects an option to cancel the alert, the display shall require
|
||
confirmation by the user, and if confirmed the beacon will activate the normal beacon
|
||
cancellation function.
|
||
r) The display and controls shall meet the operational requirements related to the handling
|
||
of messages described in section 4.5.17.6.
|
||
4.5.17.2 Integral TWC Display / Data Entry Additional Requirements
|
||
If the visual display and means of data entry are integral to the beacon, then the following additional
|
||
requirements apply:
|
||
a) The display shall be visible and legible both at night and during the day (but not
|
||
necessarily in direct sunlight).
|
||
b) The display shall operate over the operating temperature range of either a Class 1 or
|
||
Class 2 beacon as defined by the beacon manufacturer.
|
||
c) The display may be turned off when not in use and may time out after 30 seconds of
|
||
data entry inactivity\*.
|
||
d) There shall be a simple means of turning the display back on without inadvertently
|
||
generating an answer for transmission by the beacon.
|
||
e) The means of answering questions or responding to instructions shall be self-evident
|
||
(e.g., up, down, left, right and enter keys) or shall be indicated to the user on the display
|
||
or the body of the beacon near the display.
|
||
f) There shall be a means of testing the display to ensure that it is functioning correctly
|
||
(this may be part of the beacons normal Self-Test function)
|
||
g) If the Q/A/I dataset is stored in the beacon the manufacturer shall ensure that the latest
|
||
version of the dataset is encoded in the beacon prior to it leaving the place of
|
||
manufacture.
|
||
h) When activated, the beacon shall commence the display of the first question before the
|
||
second 406 MHz transmission has been emitted.
|
||
4.5.17.3 Separate TWC Display / Data Entry Additional Requirements
|
||
If the visual display and means of data entry are separate to the beacon but provided with the beacon,
|
||
then the following additional requirements apply:
|
||
a) The display shall be visible and legible both at night and during the day (but not
|
||
necessarily in direct sunlight).
|
||
* For the purposes of determining the beacon’s minimum duration of continuous operation during type approval testing,
|
||
a cumulative total display on-time of [60] minutes minimum, or greater as declared by the beacon manufacturer, shall
|
||
be assumed.
|
||
|
||
4-27
|
||
|
||
b) The operating temperature range of the separate device shall be as specified by the
|
||
beacon manufacturer. If this is different to the operating temperature range of the
|
||
beacon that it is associated with, then the device shall detail the temperature range that
|
||
the display will work over and contain a warning to the effect that the display may not
|
||
function at the operating temperature extremes of the beacon.
|
||
c) The display may be turned off when not in use and may time out after 30 seconds of
|
||
data entry inactivity\*
|
||
d) There shall be a simple means of turning the display back on without inadvertently
|
||
generating an answer for transmission by the beacon.
|
||
e) The means of answering questions or responding to instructions shall be self-evident
|
||
(e.g. up, down, left, right and enter keys) or shall be indicated to the user on the
|
||
display or on the body of the separate device near the display.
|
||
f) There shall be a means of testing the display and the connection to the beacon to
|
||
ensure that it is functioning correctly.
|
||
g) If the Q/A/I dataset is stored in the separate device the manufacturer shall ensure that
|
||
the latest version of the dataset is encoded in the device prior to leaving the place of
|
||
manufacture.
|
||
h) There shall be a means of enabling two-way communications between the beacon and
|
||
the separate device (e.g., hardwired, Bluetooth, Wi-Fi etc.) over a range of distances
|
||
declared by the beacon manufacturer.
|
||
i) The means of communication between the beacon and the separate device may go into
|
||
a ‘sleep’ mode when not required to transmit data between the devices\*.
|
||
j) The separate device may contain its own power supply or may draw power from the
|
||
beacon that it is associated with. If the separate device does contain its own power
|
||
supply this shall be capable of operating the device for a minimum of [12] hours over
|
||
the operating temperature range of the separate device. If the separate device is powered
|
||
by the beacon, it shall not degrade the duration of continuous operation of the beacon
|
||
as defined in 4.5.1
|
||
k) When the external device is activated, the external device shall commence the display
|
||
of the first question within 10 seconds.
|
||
4.5.17.4 Third-Party TWC Display / Data Entry Additional Requirements
|
||
If the visual display and means of data entry are provided on a third-party device (e.g., a Smartphone)
|
||
then the following additional requirements apply:
|
||
a) The display of Q/A/Is on the third-party device shall be legible.
|
||
* For the purposes of determining the beacon’s minimum duration of continuous operation during type approval testing,
|
||
a cumulative total communications time between devices of [10] minutes minimum, or greater as declared by the
|
||
beacon manufacturer, shall be assumed
|
||
|
||
4-28
|
||
|
||
b) A means of answering questions or responding to instructions shall be provided on the
|
||
third-party device.
|
||
c) There shall be a means of testing the TWC function on the third-party device and its
|
||
connection to the beacon to ensure that it is functioning correctly.
|
||
d) If the Q/A/I dataset is stored on the third-party device the beacon manufacturer shall
|
||
ensure that it is provided as a part of the related software Application required for the
|
||
TWC functionality to run on the device.
|
||
e) There shall be a means of enabling two-way communications between the beacon and
|
||
the third-party device (e.g., hardwired, Bluetooth, Wi-Fi etc.) over a range of distances
|
||
declared by the beacon manufacturer.
|
||
f) The means of communication between the beacon and the third-party device may go
|
||
into a ‘sleep’ mode when not required to transmit data between the devices\*.
|
||
g) The third-party device shall not be able to draw power from the beacon’s primary
|
||
battery.
|
||
h) The beacon user manual shall provide adequate guidance on how to download install
|
||
and operate any Application required on the third-party device to enable the TWC
|
||
functionality.
|
||
i) The beacon user manual shall contain any necessary warnings related to the use and/or
|
||
limitations on the type of third-party device and applications that the beacon can
|
||
function with.
|
||
j) When beacon is activated and the third party device is active, it shall commence the
|
||
display of the first question within 10 seconds of the display application being accessed.
|
||
4.5.17.5 RLS Type 3 TWC (message) Mode of Operation
|
||
If the RLS Type 3 Two-Way Communication (TWC) (message) functionality is enabled on a
|
||
beacon, after activation and start of transmissions in accordance with section 2.2.1, the TWC
|
||
capable beacon shall display the initial automatic questions.
|
||
Starting from beacon activation, RF\#4 and RF\#0 shall be transmitted.
|
||
The initial questions shall be made available to the beacon user sequentially and the next one
|
||
shall be made available only when the previous one is answered by the user. However, the beacon
|
||
may provide an option to skip a particular question. If a follow-on question or instruction is
|
||
received during the initial questions answering phase, it shall be prioritized over the remaining
|
||
initial questions.
|
||
The priority among follow-on questions or instructions shall be the order of reception by the
|
||
beacon.
|
||
* For the purposes of determining the beacon’s minimum duration of continuous operation during type approval testing,
|
||
a cumulative total communications time between devices of [10] minutes minimum, or greater as declared by the
|
||
beacon manufacturer, shall be assumed
|
||
|
||
4-29
|
||
|
||
If the RLS Type 3 Two-Way Communication (TWC) (message) functionality in the beacon is
|
||
not enabled, then the user shall be advised of this.
|
||
The bit assignment in the RF\#4 defined in Table 3.11 is represented hereafter:
|
||
Figure 4-2: RF\#4 bit assignment representation with the FLAM in the case
|
||
where the bit 14 (Answer Format Flag) is 0 (Short)
|
||
Figure 4-3: RF\#4 bit assignment representation with the FLAM in the case
|
||
where the bit 14 (Answer Format Flag) is 1 (Long)
|
||
This assignment enables having three separate slots of 11 bits each, or one slot of 22 bits followed
|
||
by one slot of 11 bits, for Questions/Answers or Instructions/Reception Acknowledgements per
|
||
burst.
|
||
4.5.17.6 RLS Type 3 Two-Way Communication (TWC) (message) Operation
|
||
All the answers to initial or follow-on questions shall be transmitted [as soon as available in the
|
||
next] RF\#4 (i.e., the beacon shall not wait until all Q&A slots in the message have been filled).
|
||
In the event that the number of answers to be sent exceeds the number of slots available in the
|
||
RF\#4 (i.e., 2 or 3 slots, depending on the answer format configuration), the questions and
|
||
associated answers shall be stacked and sent in different successive RF\#4 bursts without waiting
|
||
for acknowledgements from the TWC-SP. The questions and associated answers sent in the
|
||
RF\#4s rotate, meaning that for example, if 6 answers to short answer format questions have to
|
||
be sent, the first 3 in stack are transmitted, then the next 3 answers, then the first 3 answers again
|
||
etc. Beacon user’s answers (Ax slot different from default values) shall be prioritized over
|
||
beacon’s acknowledgements.
|
||
|
||
|
||
|
||
|
||
|
||
4-30
|
||
|
||
In the case where multiple selectable answers to a long format answer question have to be sent,
|
||
the Answer Format Flag bit shall be set to 1 and the 22-bit slot in the long format shall be used
|
||
to encode the question (in the 7 bits) and the long format answer(s) (15 bits).
|
||
The beacon shall inform the user (e.g., “Select all that apply”) when displaying a question that
|
||
allows multiple-selectable answers (i.e., the question has the corresponding flag with value of 1).
|
||
The beacon shall be able to handle a decision tree, meaning that certain questions can lead to
|
||
other questions. The questions and answers at every step in the decision tree shall be transmitted
|
||
[as soon as possible]. [In the case where multiple answers triggering different subsequent
|
||
questions are selected, the beacon shall display the subsequent questions one after the other, in
|
||
the same order as the display order of the selected answers.]
|
||
4.5.17.6.1
|
||
Operation with Initial Q&As
|
||
Upon activation the beacon transmits RF\#4 (alternating with RF\#0) with default Q&As using the
|
||
short answer format until either an Initial Question is answered or a Follow-on Question or
|
||
Instruction is received (see 4.5.17.6.2 below).
|
||
a) Once the user answers the first question this is inserted in Slot 1 together with its Answer
|
||
and is transmitted in the next RF\#4 burst. This process is repeated for subsequent Initial
|
||
Q&As using other slots in the message as available. If there are more questions than
|
||
slots available then Q&As are stacked and alternated in subsequent RF\#4s as outlined
|
||
above.
|
||
b) Once an Initial Q&A has been received by the TWC-SP, it will be acknowledged by
|
||
sending an Acknowledgement for the specific question (or questions) back to the beacon
|
||
in an RLM containing the beacon’s 15 Hex ID (truncated from the 23 Hex ID).
|
||
c) [Upon receipt of the Acknowledgement to a specific question the beacon will continue
|
||
to transmit the Question in the next RF\#4 burst but will change the Answer to Default
|
||
(this will advise the TWC-SP that it can now stop transmitting the Acknowledgement
|
||
for that specific question)].
|
||
d) [The beacon shall transmit the Question with the Default Answer in [5] bursts (as a
|
||
means to try and ensure that the TWC-SP receives this message), after this period of
|
||
time the beacon reverts to transmitting default data in both the Q&A part of the Slot
|
||
until such time as this Slot is required to send another Q&A].
|
||
e) The same strategy applies to any other Initial Q&As, which may be contained in the
|
||
same burst as the first Q&A, or may be in later bursts depending on the speed at which
|
||
the user answers the Initial Questions.
|
||
f) Once all the Initial Questions and associated answers have been acknowledged by the
|
||
TWC-SP, unless one or more Follow-on Questions or Instructions have been received,
|
||
the beacon will revert to transmitting all default Q&As.
|
||
|
||
4-31
|
||
|
||
As noted above, the Initial Q&A session may be interrupted by the reception of a Follow-on
|
||
Question or Instruction from an RCC or SPOC. In this case this Follow-on question shall take
|
||
priority over any unanswered Initial Questions.
|
||
Note that slots in the message are generic as each slot contains all necessary data, thus it does not
|
||
matter if a specific Q&A is for example transmitted in Slot 2 in one RF\#4 and is then
|
||
subsequently transmitted in Slot 1 in a later RF\#4.
|
||
4.5.17.6.2
|
||
Operation with Follow-on Q&As or Instructions
|
||
The beacon will not have answered any of the Initial Questions, or still be answering Initial
|
||
Questions, or will have finished with all of these and will thus have reverted to transmitting
|
||
default Q&As. Regardless of when it receives one or more Follow-on Question(s) or
|
||
Instruction(s) it handles them as follows.
|
||
a) As soon as the beacon receives a Follow-on Question or Instruction in an RLM
|
||
containing the beacon’s 15 Hex ID (truncated from the 23 Hex ID) it shall, transmit the
|
||
Follow-on Question / Instruction Number with a Default answer in a free Slot in the
|
||
next RF\#4 (this informs the TWC-SP that the Question / Instruction has been received).
|
||
b) If there is not a free Slot in which to transmit the follow-on Question / Instruction, then
|
||
this shall replace the newest other Q&A in whichever Slot it occupies in RF\#4. This
|
||
other Q&A shall then be transmitted in the next RF\#4. RF\#4 transmissions then alternate
|
||
between the sets of Q&As until one or more Slots can be freed up as the result of
|
||
completing the handshake with the TWC-SP. At which time the beacon reverts to
|
||
providing all outstanding Q&As in a single RF\#4.
|
||
c) If further Questions or Instructions are received, they shall be handled in the same
|
||
manner as in (a) above in the order of reception by the beacon.
|
||
d) If the user has not yet answered all of the Initial Questions then any Follow-on Questions
|
||
or Instructions take priority over these in terms of being presented to the user for
|
||
answering. Once the Follow-on Questions or Instructions have been answered the
|
||
beacon shall revert to displaying any remaining unanswered Initial Questions to the user,
|
||
or if there are no more Questions or Instructions then the user shall be advised of this.
|
||
e) Once the user answers a Follow-on Question or Instruction, then the message containing
|
||
the Question / Instruction Number shall be updated with the relevant Answer instead of
|
||
the default which shall be transmitted in the next RF\#4.
|
||
f) The beacon shall continue to transmit the Follow-on Question or Instruction with its
|
||
Answer until it receives an RLM Acknowledging receipt containing the beacon’s 15
|
||
Hex ID (truncated from the 23 Hex ID). Once the beacon receives the acknowledgment
|
||
it shall cease transmitting the Follow-on Question or Instruction with its Answer.
|
||
Once all the Initial Questions and Follow-on Questions or Instructions have been addressed, the
|
||
beacon will revert to transmitting default Q&As using the short answer format.
|
||
|
||
4-32
|
||
|
||
Note that slots in the message are generic as each slot contains all necessary data, thus it does not
|
||
matter if a specific Q&A is for example transmitted in Slot 2 in one RF\#4 and is then
|
||
subsequently transmitted in Slot 1 in a later RF\#4.
|
||
4.5.17.7 GNSS Receiver
|
||
The RLS Type-3 TWC GNSS receiver shall comply with the requirements in section 4.5.9.1.
|
||
4.5.17.7.1
|
||
RLS Type-3 TWC GNSS Receiver Operation
|
||
In addition to the beacon’s normal GNSS receiver operating cycle as defined in section
|
||
4.5.5.2 or as defined by the beacon manufacturer if the receiver is designed to be active
|
||
more frequently than those requirements, the TWC beacon shall when activated with TWC
|
||
functionality:
|
||
a) maintain the GNSS receiver in an active mode of operation such that it can continuously
|
||
check for receipt of an RLM message and Coordinated Universal Time (UTC), for a
|
||
minimum period of 3 hours after beacon activation, or until the beacon is deactivated,
|
||
whichever occurs first;
|
||
b) as soon as possible determine UTC from the GNSS receiver and maintain a clock for at
|
||
least 12 hours from the time the beacon was first activated, to the accuracy of better than
|
||
three seconds (once UTC has been acquired) or until the beacon is deactivated (if UTC
|
||
is not acquired see (e) below);
|
||
c) after the first 3 hours and each subsequent hour reactivate the GNSS receiver to check
|
||
for receipt of an RLM for a minimum period of 15 minutes at Moffset minutes, with 0 ≤
|
||
Moffset ≤ 59, past the hour until 12 hours has elapsed since the beacon was activated;
|
||
d) if UTC is not available after the first 3 hours the beacon shall attempt to establish UTC
|
||
using the timings detailed in sections 4.5.5.2. If UTC is then established the beacon shall
|
||
continue as per c) above from the next occurrence of UTC Moffset minutes; and
|
||
e) after 12 hours has elapsed since beacon activation the beacon shall revert to the GNSS
|
||
timings in sections 4.5.5.2.
|
||
For instance, if the beacon is activated at 03:17 UTC, then the GNSS receiver would
|
||
remain active until at least 06:17 UTC or the beacon is deactivated if it is deactivated
|
||
before that time. The beacon GNSS receiver shall reactivate at the next occurrence of
|
||
Moffset past the hour and remain active until at least Moffset+15, or the beacon is deactivated
|
||
and the GNSS receiver would then reactivate again during the next hour at Moffset until
|
||
Moffset+15, etc. The scheme continues as above until 12 hours has elapsed since beacon
|
||
activation, that is in this example until 15:17 UTC, at which time the GNSS Receiver
|
||
reverts to the GNSS timings in section 4.5.5.2. If the beacon is deactivated, then the entire
|
||
operation cycle commences again from the beginning when the beacon is next activated.
|
||
The TWC beacon may contain an internal GNSS receiver capable of receiving and
|
||
decoding other types of RLM following the same operation cycle as the one described.
|
||
|
||
4-33
|
||
|
||
4.5.17.7.2
|
||
RLS Type-3 TWC (message) Beacon Use of Moffset
|
||
The derivation of Moffset is defined in section 4.5.9.2.2.
|
||
4.5.17.8
|
||
RLS Type 3 Two-Way Communication (TWC) (message) Indicator
|
||
The beacon shall be provided with a TWC indicator designed to advise the user when the first TWC
|
||
message has been received by the TWC-SP and the beacon has received the first Type-3 Return Link
|
||
Message (RLM). The TWC Indicator shall:
|
||
a) be readily visible to the user when the beacon is operated in all its normal operational
|
||
configurations as declared by the manufacturer;
|
||
b) be clearly visible to the user in direct sunlight;
|
||
c) provide a distinct unique indication;
|
||
d) remain inactive at all times when the beacon message is encoded with any message
|
||
content other than the TWC Rotating Field;
|
||
e) within 5 seconds of the beacon transmitting an initial Type-3 request, commence
|
||
indication of the request until either the valid RLM Type-3 message is received, or the
|
||
beacon is deactivated, or the beacon battery is expired;
|
||
f) within 5 seconds of the beacon receiving the first valid Type-3 RLM message
|
||
acknowledgement, commence a distinct indication until either the beacon is deactivated
|
||
or the beacon battery is expired;
|
||
g) only provide the indication of receipt of a Type-3 request acknowledgment when the
|
||
received RLM Type-3 message contains the unique 15 Hex ID subset of the 23- Hex ID
|
||
programmed into that beacon and the beacon has validated that this matches its own 15-
|
||
Hex ID subset of its 23- Hex ID;
|
||
h) provide an indication during a self-test if the TWC functionality is enabled in
|
||
accordance with section 4.5.4.1; and
|
||
i) be distinct from the RLS indicator described in Section 4.5.9.3.
|
||
4.5.17.9
|
||
RLS Type 3 TWC (message) Beacon Documentation
|
||
The operation of the TWC function shall be clearly explained in the User Manual including the
|
||
performance characteristics of the overall TWC system. Suggested minimum text is provided in
|
||
Annex H.2.
|
||
- END OF SECTION 4 -
|
||
|
||
A-1
|
||
|
||
APPENDIX A - LIST OF ACRONYMS
|
||
A full list of all Acronyms can be found in document C/S S.011 – Glossary.
|
||
- END OF APPENDIX A -
|
||
|
||
B-1
|
||
|
||
APPENDIX B - SAMPLE BOSE-CHAUDHURI-HOCQUENGHEM ERROR-
|
||
CORRECTING CODE AND 23 HEX ID CALCULATIONS
|
||
NOTE: The information in the Appendix is not aligned with the current text in the main body of
|
||
this document and requires an update.
|
||
B.1
|
||
Sample 48-Bit BCH Code Calculation
|
||
The error-correcting code used in 406 MHz messages is a shortened form of a (255,207) Bose-
|
||
Chaudhuri-Hocquenghem (BCH) code. The shortened form (250,202) consists of 202 bits of data
|
||
followed by a 48-bit sextuple error-correcting code. The code is used to detect and correct up to
|
||
six errors in the entire 250-bit pattern (bits 1 through 250 of the 406 MHz message).
|
||
Note: For the purpose of error correction, all calculations shall be performed with the full
|
||
255 length code. Therefore, 5 zeros are placed before the 202 data bits to form the 207-bit pattern
|
||
of the (255,207) BCH code. These padding zeros do not affect the generation of the BCH code as
|
||
described below.
|
||
For the (250,202) BCH code, a generator polynomial g(X) (the same as for (255,207) BCH code)
|
||
is defined as follows:
|
||
𝑔(𝑋) = 𝐿𝐶𝑀(𝑚1(𝑋), 𝑚3(𝑋), 𝑚5(𝑋), 𝑚7(𝑋), 𝑚9(𝑋), 𝑚11(𝑋))
|
||
where LCM = Least Common Multiple.
|
||
In the above case:
|
||
𝑚1(𝑋) = 𝑋8 + 𝑋4+𝑋3+𝑋2 + 1
|
||
𝑚3(𝑋) = 𝑋8 + 𝑋6 + 𝑋5 + 𝑋4 + 𝑋2 + 𝑋+ 1
|
||
𝑚5(𝑋) = 𝑋8 + 𝑋7 + 𝑋6 + 𝑋5 + 𝑋4 + 𝑋+ 1
|
||
𝑚7(𝑋) = 𝑋8 + 𝑋6 + 𝑋5 + 𝑋3 + 1
|
||
𝑚9(𝑋) = 𝑋8 + 𝑋7 + 𝑋5 + 𝑋4 + 𝑋3 + 𝑋2 + 1
|
||
𝑚11(𝑋) = 𝑋8 + 𝑋7 + 𝑋6 + 𝑋5 + 𝑋2 + 𝑋+ 1
|
||
from which
|
||
𝑔(𝑋)
|
||
= 𝑚1(𝑋), 𝑚3(𝑋), 𝑚5(𝑋), 𝑚7(𝑋), 𝑚9(𝑋), 𝑚11(𝑋)
|
||
= 𝑋48 + 𝑋47 + 𝑋46 + 𝑋42 + 𝑋41 + 𝑋40 + 𝑋39 + 𝑋38 + 𝑋37 + 𝑋35 + 𝑋33 + 𝑋32+𝑋31
|
||
+ 𝑋26 + 𝑋24+𝑋23+𝑋22+𝑋20+𝑋19+𝑋18+𝑋17+𝑋16+𝑋13+𝑋12+𝑋11+𝑋10+𝑋7+𝑋4+𝑋2
|
||
+ 𝑋+ 1
|
||
|
||
B-2
|
||
|
||
a determination of g(X) results in the following 49-bit binary number
|
||
𝑔(𝑋) = 1110001111110101110000101110111110011110010010111
|
||
To generate the BCH code, an information polynomial, m(x) is formed from the 202 data bits as
|
||
follows:
|
||
𝑚(𝑋) = 𝑏1𝑋201 + 𝑏2𝑋200 + ⋯+ 𝑏201𝑋+ 𝑏202
|
||
where b1 - is the first bit and b202 - is the last bit of the digital message.
|
||
m (X) is then extended to 250 bits by filling the least significant bits with 48 "0". The resulting
|
||
250-bit binary string is then divided by g(X) and the remainder, r(X), becomes the BCH code (the
|
||
quotient portion of the result of the module-2 binary division is discarded).
|
||
The above process may be clarified by the following example. Suppose, that the digital message
|
||
in the Minimum Requirement main field consists of the following data (decimal notation):
|
||
Digital Message
|
||
Decimal Data
|
||
Binary Data
|
||
Bits in Message
|
||
TAC number
|
||
|
||
|
||
1 to 16
|
||
Serial Number
|
||
|
||
|
||
17 to 30
|
||
Country code
|
||
|
||
|
||
31 to 40
|
||
Status of homing device
|
||
|
||
|
||
RLS function
|
||
|
||
|
||
Test protocol
|
||
|
||
|
||
Encoded GNSS Location
|
||
See below
|
||
See below
|
||
44 to 90
|
||
Vessel ID
|
||
|
||
47 Bits all 0’s
|
||
91 to 137
|
||
Beacon Type
|
||
|
||
|
||
138 to 140
|
||
Spare bits
|
||
16383 (all 1’s)
|
||
|
||
141 to 154
|
||
Message also contains encoded GNSS location. This example uses the following values of position
|
||
data:
|
||
Current latitude
|
||
48,793153539336956 °N
|
||
Current longitude
|
||
69,00875866413116 °E
|
||
Encoded GNSS location in binary notation (converted in accordance with Appendix C):
|
||
Current latitude
|
||
0 0110000 110010110000110
|
||
Current longitude
|
||
0 01000101 000000100011111
|
||
|
||
B-3
|
||
|
||
In this example Rotating Field 1 (C/S G.008 Objective Requirements) is used, containing the following
|
||
data:
|
||
Digital Message
|
||
Decimal Data
|
||
Binary Data
|
||
Bits in Message
|
||
Rotating Field Identifier
|
||
|
||
|
||
155 to 158
|
||
Elapsed Time since activation
|
||
1 hour 27 mins
|
||
|
||
159 to 164
|
||
Time from last encoded location
|
||
6 mins 24 sec
|
||
|
||
165 to 175
|
||
Altitude of encoded location
|
||
430,24 metres
|
||
|
||
176 to 185
|
||
Dilution of precision
|
||
HDOP<1 VDOP <2
|
||
|
||
186 to 193
|
||
Activation notification
|
||
Manual
|
||
|
||
194 to 195
|
||
Remaining battery capacity
|
||
>75%
|
||
|
||
196 to 198
|
||
GNSS status
|
||
3D
|
||
|
||
199 to 200
|
||
Spare bits
|
||
|
||
|
||
200 to 202
|
||
Thus, digital message in binary and hexadecimal notation will be the following:
|
||
Bits 1-202
|
||
0000 0000 1110 0110 0000 1000 1111 0100
|
||
1100 1001 1000 0110 0001 1001 0110 0001
|
||
1000 1000 1010 0000 0100 0111 1100 0000
|
||
0000 0000 0000 0000 0000 0000 0000 0000
|
||
0000 0000 0000 1111 1111 1111 1100 0000
|
||
0001 0000 0000 1100 0001 1010 0000 0000
|
||
1001 0110 00
|
||
Hex Message
|
||
From 202 bits
|
||
00E608F4C986196188A047C000000000000FFFC0100C1A00960
|
||
Cospas-Sarsat Ground
|
||
Segment
|
||
Representation\*
|
||
(MF \#90 Ref. C/S A.002)
|
||
0039823D32618658622811F0000000000003FFF004030680258
|
||
(two leading 0 bits plus bits 1-202)
|
||
* As the length of the message in bits is not divisible by 4, the message is augmented, for ground
|
||
processing purposes, with two leading binary ‘0’s, which results in this revised hexadecimal message.
|
||
The division * described above is shown in Figure A1, and results in a 49-bit remainder of:
|
||
|
||
|
||
The most significant bit position of the remainder will always be a "0" and is deleted to obtain the 48-
|
||
bit BCH code.
|
||
Thus BCH Error-Correcting Code:
|
||
|
||
REFERENCE
|
||
* Modulo 2 division prohibits a "borrow" in the subtraction portion of the long division.
|
||
|
||
B-4
|
||
|
||
An Introduction to Error Correcting Codes, Shu Lin, Prentice Hall 1970
|
||
|
||
B-5
|
||
|
||
5 “0”
|
||
Bits 0-202
|
||
(Data bits)
|
||
Bits (203-250)
|
||
48 «0»
|
||
m(x)=
|
||
00000 0000000011100110000010001111010011001001100001100001100101100001100010001010000001000111
|
||
…
|
||
010000000001001011000 000000000000000000000000000000000000000000000000
|
||
g(X)=
|
||
|
||
|
||
…
|
||
…
|
||
|
||
|
||
49 bits remainder =
|
||
|
||
-------- BCH Code (last 48 bits) -------→
|
||
Figure B-1: Sample 48-Bit BCH Error-Correcting Code Calculation
|
||
(for easier viewing the calculation is reduced and divided into 2 parts)
|
||
|
||
B-6
|
||
|
||
B.2
|
||
Sample 23 Hex ID Calculation
|
||
Using the same data as above the 23 Hex ID can be generated as shown below. It should be noted
|
||
that the 23 Hex ID cannot be formed directly from the transmitted message as additional bits have to
|
||
be added to it and the order of the digital message data has to be changed.
|
||
Referring to T.018 Section 3.6 and Table 3.9 and using the digital message data from above results in
|
||
the following:
|
||
23 Hex ID Bit
|
||
No Bits
|
||
Data Content
|
||
Message Content
|
||
|
||
|
||
Fixed Binary ‘1’
|
||
|
||
2 to 11
|
||
|
||
C/S Country Code ‘201’
|
||
|
||
|
||
Fixed Binary ‘1’
|
||
|
||
|
||
Fixed Binary ‘0’
|
||
|
||
|
||
Fixed Binary ‘1’
|
||
|
||
15 to 30
|
||
|
||
C/S TAC No ‘230’
|
||
|
||
31 to 44
|
||
|
||
Beacon Serial Number ‘573’
|
||
|
||
|
||
Test Protocol Flag
|
||
|
||
46 to 48
|
||
|
||
Aircraft / Vessel ID Type
|
||
‘N/A’
|
||
|
||
49 to 92
|
||
|
||
Aircraft / Vessel ID
|
||
44 Bits all ‘0’s
|
||
1001 1001 0011 0100 0000 0011 1001 1000 0010 0011 1101 0000
|
||
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
|
||
Which in turn gives a final 23 Hex ID of:
|
||
23 Hex ID
|
||
9934039823D000000000000
|
||
Which it can be seen is very different to the first 23 Hex characters of the Digital Message Data
|
||
00E608F4C986196188A047C
|
||
Finally, for completeness it can be noted that the unique 15 Hex ID for the same beacon is obtained
|
||
by truncating the 23 Hex ID, as described in section 3.6, which would give a 15 Hex ID of:
|
||
9934039823D0000
|
||
- END OF APPENDIX B -
|
||
|
||
C-1
|
||
|
||
APPENDIX C - BEACON ENCODED LOCATION CODING
|
||
C.1
|
||
ENCODED LOCATION PROTOCOL
|
||
This section defines the encoded location protocol which can be used with the 406 MHz beacon message
|
||
formats for encoding beacon position data in the digital message transmitted by a 406 MHz distress
|
||
beacon.
|
||
C.2
|
||
Summary
|
||
Encode location is represented differently in second generation beacons. In first generation beacons,
|
||
degrees, minutes and seconds were used. For second generation beacons, degrees and decimal part of the
|
||
degrees are used. Moreover, there is no coarse and fine offset fields: all information appears in one field.
|
||
Moreover, there is no separate return link location protocol. Instead, RLS data is contained in one of the
|
||
rotating fields.
|
||
C.3
|
||
Default Values in Position Data
|
||
The following default values shall be used in all encoded position data fields of the location protocols,
|
||
when no valid data is available:
|
||
a) all bits in the degrees are set to "1", with N/S, E/W flags set to "0"; and
|
||
b) the bits in the decimal parts of the degrees are set to the following patterns:
|
||
i. Latitude: 000001111100000 (Note the first five decimal parts of degrees bits are set to “0”s,
|
||
the middle five bits are set to “1” s and the last 5 bits are set to “0”s)
|
||
ii. Longitude: 111110000011111 (Note the first five decimal parts of degrees bits are set to
|
||
“1”s, the middle five bits are set to “0” s and the last 5 bits are set to “1”s)
|
||
The default pattern shall also be transmitted in the self-test mode. Additionally, if a location protocol
|
||
beacon includes an optional GNSS self-test and this fails to provide a valid location to encode into the
|
||
transmitted self-test message, then the beacon may radiate a single self-test message with the above default
|
||
data. However if a location protocol beacon with optional GNSS self-test obtains a location, then the
|
||
beacon shall radiate a single self-test message with encoded position.
|
||
|
||
C-2
|
||
|
||
This default bit pattern is different from first generation beacons. The degree bits are all set to “1”s as in
|
||
first generation beacons. But it is not easy to set the minutes bit to “0”s and the seconds bits to “1”s as the
|
||
decimal parts do not fall on integer minute or second boundaries.
|
||
C.4
|
||
Definition of Location Data Fields
|
||
The general structure of encoded location data is illustrated below.
|
||
C.4.1
|
||
Encoded Location field
|
||
The 47 bits available in the main digital message are defined as follows:
|
||
a)
|
||
bits 44-66:
|
||
latitude data (23 bits), including:
|
||
• bit 44:
|
||
N/S flag (N=0, S=1)
|
||
• bits 45-51:
|
||
degrees (0 to 90) in 1 degree increments
|
||
• bits 52-66:
|
||
decimal parts of degrees
|
||
b)
|
||
bits 67-90:
|
||
longitude data (24 bits), including:
|
||
• bit 67:
|
||
E/W flag (E=0, W=1)
|
||
• bits 68-75:
|
||
degrees (0 to 180) in 1 degree increments
|
||
• bits 76-90
|
||
decimal parts of degrees
|
||
C.4.2
|
||
Encoded Location Data (1)
|
||
All position information is encoded as degrees, and decimal parts of latitude or longitude. Latitude
|
||
and longitude data are rounded off (i.e., not truncated) to the available resolution. All rounding shall
|
||
follow normal rounding conventions, for example with a resolution of 4, 0.000 to 1.999 shall be
|
||
rounded down to 0 and 2.000 to 3.999 shall be rounded up to 4. In each location field the Most
|
||
Significant Bit (MSB) is the lowest numbered bit in the message which is not a N/S, or E/W flag bit.
|
||
The following table illustrates the bit assignments for the degrees portion of the encoded location
|
||
field.
|
||
|
||
C-3
|
||
|
||
Latitude Bit
|
||
assignment
|
||
Longitude Bit
|
||
assignment
|
||
Bit
|
||
value
|
||
in
|
||
degrees
|
||
N/A
|
||
68 (MSB)
|
||
|
||
45 (MSB)
|
||
|
||
|
||
The following table illustrates the bit assignments for the decimal parts of the degrees portion of the
|
||
encoded location field. The equivalent in minutes and seconds is also provided. The resolution in
|
||
meters of each bit of longitude at the equator is also given, with the resolution of each latitude bit
|
||
0.169% less than for the longitude bit (at the equator). This reflects the fact that the circumference
|
||
around the earth at the equator is 40,075.16 Km and 40,008 Km for each meridian.
|
||
Latitude bit
|
||
assignment
|
||
Longitude
|
||
Bit
|
||
assignment
|
||
Bit value of
|
||
decimal parts
|
||
in degrees
|
||
Bit value of
|
||
decimal parts
|
||
in minutes
|
||
Bit value of
|
||
decimal parts
|
||
in seconds
|
||
Resolution
|
||
in
|
||
meters
|
||
(equator)
|
||
|
||
|
||
0.5
|
||
|
||
|
||
55566.67
|
||
|
||
|
||
0.25
|
||
|
||
|
||
27783.33
|
||
|
||
|
||
0.125
|
||
7.5
|
||
|
||
13891.67
|
||
|
||
|
||
0.0625
|
||
3.75
|
||
|
||
6945.833
|
||
|
||
|
||
0.03125
|
||
1.875
|
||
112.5
|
||
3472.917
|
||
|
||
|
||
0.015625
|
||
0.9375
|
||
56.25
|
||
1736.458
|
||
|
||
|
||
0.0078125
|
||
0.46875
|
||
28.125
|
||
868.2292
|
||
|
||
|
||
0.00390625
|
||
0.234375
|
||
14.0625
|
||
434.1146
|
||
|
||
|
||
0.001953125
|
||
0.1171875
|
||
7.03125
|
||
217.0573
|
||
|
||
|
||
0.000976563
|
||
0.05859375
|
||
3.515625
|
||
108.5286
|
||
|
||
|
||
0.000488281
|
||
0.029296875
|
||
1.7578125
|
||
54.26432
|
||
|
||
|
||
0.000244141
|
||
0.014648438
|
||
0.87890625
|
||
27.13216
|
||
|
||
|
||
0.00012207
|
||
0.007324219
|
||
0.439453125
|
||
13.56608
|
||
|
||
|
||
6.10352E-05
|
||
0.003662109
|
||
0.219726563
|
||
6.78304
|
||
|
||
|
||
3.05176E-05
|
||
0.001831055
|
||
0.109863281
|
||
3.39152
|
||
C.5
|
||
Instructions for converting Latitudes and Longitudes to a Binary Number
|
||
Global Navigation Satellite System receivers (e.g., GPS, Glonass, Galileo, BDS, etc.) normally output
|
||
position data using an IEC 61162-1 (NMEA 0183) formatted sentence. This will provide a position in
|
||
decimal degrees, minutes and parts of a minute as a decimal fraction in a defined format for example
|
||
“3546.295, N, 14821.291, W”. That is 35 degrees and 46.295 minutes North by 148 degrees and 21.291
|
||
|
||
C-4
|
||
|
||
minutes West. The size of the decimal fraction is not defined In IEC 61162-1, but in order to ensure
|
||
adequate accuracy initially and during subsequent rounding processes the number of digits after the
|
||
decimal point should not be less than 3.
|
||
In order to transmit this as a part of a Second Generation Beacon message it is necessary to convert the
|
||
position into a binary number expressed as degrees and a decimal fraction of a degree. The following
|
||
text provides an example of how this can be achieved.
|
||
Referring to C/S T.018 Table 3.1 Encoded GNSS Location we can see that the required message format
|
||
is as follows:
|
||
No of Bits
|
||
Content
|
||
|
||
N/S flag (N=0, S=1)
|
||
|
||
Degrees (0 to 90) in 1 degree increments
|
||
|
||
Decimal parts of a degree (0.5 to 0.00003)
|
||
|
||
E/W flag (E=0. W=1)
|
||
|
||
Degrees (0 to 180) in 1 degree increments
|
||
|
||
Decimal parts of a degree (0.5 to 0.00003)
|
||
The use of the bits for the N/S or E/W flags and the encoding of Degrees is straightforward and no
|
||
further explanation is deemed necessary. But converting minutes and a decimal fraction of a minute to
|
||
decimal parts of a degree and then to binary is less obvious, so an example of this is provided below.
|
||
Using the example above “3546.295, N” in binary would appear as follows:
|
||
N/
|
||
S
|
||
Degrees
|
||
Decimal Parts of a Degree
|
||
0/1
|
||
|
||
|
||
8 4 2 1
|
||
1/
|
||
|
||
1/
|
||
|
||
1/
|
||
|
||
1/1
|
||
|
||
1/3
|
||
|
||
1/6
|
||
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
.
|
||
|
||
|
||
0 0 1 1
|
||
|
||
|
||
0 1 1 0 0 0 0 1 1
|
||
Initially the minutes and decimal fraction of minutes must be converted into a decimal fraction of a
|
||
degree, this is achieved by simply dividing the whole number by 60 e.g., 46.295 Minutes divided by
|
||
60 equals 0.77158333 Degrees. Again in order to maintain accuracy this number should be rounded to
|
||
no less than [5] decimal places e.g., [0.77158]. So 35 Degrees and 46.295 Minutes becomes [35.77158]
|
||
Degrees.
|
||
Two procedures for converting decimal parts of a degree to binary are provided below, the first uses
|
||
the Successive Multiplication Method while the second uses the Integral Number Conversion Method.
|
||
Successive Multiplication Method
|
||
1) Start with the decimal fraction part and multiply it by 2 (add it to itself)
|
||
2) If the result is greater than 1 then the first decimal fraction is a 1, if the result is less than 1
|
||
then the first decimal fraction is a 0
|
||
3) If the result was greater than 1 then subtract 1 from the result
|
||
4) Multiply the remaining number by 2
|
||
5) Repeat step 2) to obtain the second decimal fraction and then repeat steps 3) and 4)
|
||
6) Repeat step 5) for all the remaining decimal fractions
|
||
|
||
C-5
|
||
|
||
7) On completing the final step to obtain the fifteenth digit again repeat step 3), if the remainder
|
||
is 0.5 or greater then increase the computed binary number by one to round to the closest
|
||
possible number, or if the remaining number is less than 0.5 then use the binary number as
|
||
computed
|
||
The above example is provided below:
|
||
1) 0.77158 x 2 = 1.54316 thus the first digit is a 1
|
||
2) 1.54316 – 1 = 0.54316
|
||
3) 0.54316 x 2 = 1.08632 thus the second digit is a 1
|
||
4) 1.08632 – 1 = 0.08632
|
||
5) 0.08632 x 2 = 0.1728 thus the third digit is a 0
|
||
6) 0.17264 x 2 = 0.34528 thus the fourth digit is a 0
|
||
7) 0.34528 x 2 = 0.69056 thus the fifth digit is a 0
|
||
8) 0.69056 x 2 = 1.38112 thus the sixth digit is a 1
|
||
9) 1.38112 – 1 = 0.38112
|
||
10) 0.38112 x 2 = 0.76224 thus the seventh digit is a 0
|
||
11) Keep going as above
|
||
12) 0.78336 x 2 = 1.56672 thus the fourteenth digit is a 1
|
||
13) 1.56672 – 1 = 0.56672
|
||
14) 0.56672 x 2 = 1.13344 thus the last digit is a 1
|
||
15) 1.13344 – 1 = 0.13344
|
||
16) If the remaining number is 0.5 or greater then increase the computed binary number above by
|
||
one to round to the closest possible number, or if the remaining number is less than 0.5 then
|
||
use the binary number computed above
|
||
17) In this example, one computed 110001011000011, applying the rounding rule above means
|
||
that in this instance the actual binary number to use is the same
|
||
Integral Number Conversion Method
|
||
1) Start with the decimal fraction part and multiply it by 215 (2 to the power of 15)
|
||
2) Round the result to the nearest whole number
|
||
3) Convert this number to binary
|
||
4) The result is the binary fraction of the decimal fraction
|
||
The above example is provided below:
|
||
1) 0.77158 x 215 = 25283.13344
|
||
2) Rounding gives us 25283
|
||
3) Converting 25283 to binary gives 110001011000011
|
||
- END OF APPENDIX C -
|
||
|
||
D-1
|
||
|
||
APPENDIX D - EXAMPLE OF LINEAR FEEDBACK SHIFT REGISTER
|
||
(LFSR) IMPLEMENTATION
|
||
The spreading PRN sequences are generated by a method equivalent to a Linear Feedback Shift
|
||
Register (LFSR) using the generator polynomial G(x) = X23 + X18 + 1. The generator polynomial
|
||
initialization values for I and Q components for beacon normal mode operation and for beacon self-
|
||
test mode operation are given in Table 2.2.
|
||
This appendix details the generation of the 64 first chips of the normal I-component using the LSFR
|
||
implementation described in section 2.2.3 with the initialization value 000 0000 0000 0000 0000 0001
|
||
(see Table 2.2).
|
||
The last column gives the result of the PRN sequence generation (here 8000 0108 4212 84A1, as per
|
||
Table 2.2).
|
||
|
||
D-2
|
||
|
||
Figure D-1: Example of LSFR with the generation of the 64 first chips of the normal I-
|
||
component
|
||
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||
Out
|
||
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
|
||
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
|
||
0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
|
||
0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
|
||
|
||
0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
|
||
|
||
|
||
0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0
|
||
|
||
0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0
|
||
|
||
0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0
|
||
|
||
1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0
|
||
|
||
|
||
0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0
|
||
|
||
0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0
|
||
|
||
0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0
|
||
|
||
0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0
|
||
|
||
|
||
1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0
|
||
|
||
0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
|
||
|
||
0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0
|
||
|
||
1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0
|
||
|
||
|
||
0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0
|
||
|
||
1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0
|
||
|
||
0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
|
||
|
||
0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0
|
||
|
||
|
||
0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0
|
||
|
||
0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0
|
||
|
||
1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0
|
||
|
||
0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 1
|
||
|
||
|
||
0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0
|
||
|
||
1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0 0
|
||
|
||
D-3
|
||
|
||
0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 0
|
||
|
||
1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0
|
||
|
||
|
||
0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1
|
||
|
||
0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0
|
||
|
||
0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0
|
||
|
||
0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0
|
||
|
||
|
||
1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0
|
||
|
||
0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1
|
||
|
||
0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0
|
||
|
||
1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1 0
|
||
|
||
|
||
0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0 1
|
||
|
||
1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1 0
|
||
|
||
1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0 1
|
||
|
||
0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 0
|
||
|
||
|
||
0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0
|
||
|
||
0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0 0
|
||
|
||
1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 0
|
||
|
||
1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1
|
||
|
||
|
||
0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 0
|
||
|
||
1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0
|
||
|
||
0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1
|
||
|
||
1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0
|
||
|
||
A
|
||
0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0 1
|
||
|
||
0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 0
|
||
|
||
0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0
|
||
|
||
0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0 0
|
||
|
||
|
||
1 0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1 0
|
||
|
||
0 1 0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0 1
|
||
|
||
0 0 1 0 0 0 0 1 0 1 0 1 1 0 0 0 1 1 0 1 0 0
|
||
|
||
- END OF APPENDIX D -
|
||
|
||
E-1
|
||
|
||
APPENDIX E - BIT ASSIGNMENT NUMBERS
|
||
|
||
|
||
Homing Status
|
||
RLS Function
|
||
Test Protocol
|
||
|
||
|
||
Bits 1 to 43 of 202 Information bits
|
||
1 to 43 of 154 bit Main Field
|
||
Bits 44 to 90 of 202 Information bits
|
||
44 to 90 of 154 bit Main Field
|
||
TAC Number
|
||
(16 bits)
|
||
(Part of 23 HEX ID)
|
||
Serial Number
|
||
(14 bits)
|
||
(Part of 23 HEX ID)
|
||
Country Code
|
||
(10 bits)
|
||
(Part of 23 HEX ID)
|
||
23 HEX ID bit numbers
|
||
Encoded Location
|
||
(47 bits)
|
||
Vessel ID
|
||
(47 bits) (Part of 23 HEX ID)
|
||
Bits 138 to 154 of 202 Information bits
|
||
138 to 154 of 154 bit Main Field
|
||
Bits 91 to 137 of 202 Information bits
|
||
91 to 137 of 154 bit Main Field
|
||
Beacon Type
|
||
(3 bits)
|
||
Spare Bits
|
||
(14 bits)
|
||
23 HEX ID bit numbers
|
||
Bits 203 to 250 of message bits (Error Correction Code)
|
||
48 bits
|
||
BCH (250,202)
|
||
Rotating Field Information (48 bits)
|
||
Bits 155 to 202 of 202 Information bits
|
||
|
||
E-2
|
||
|
||
Rotating Field \#0 (C/S G.008 Requirements) (48 bits)
|
||
Bits 155 to 202 of 202 Information bits
|
||
Rotating Field bit number
|
||
Bits 155 to 202 of 202 Information bits
|
||
Rotating Field \#1 (ELT(DT)) (48 bits)
|
||
Rotating Field bit number
|
||
Bits 155 to 202 of 202 Information bits
|
||
Time of last encoded location
|
||
(11 bits)
|
||
Altitude of encoded location
|
||
(10 bits)
|
||
Triggering
|
||
Event
|
||
(4 bits)
|
||
Rotating Field bit number
|
||
Bits 155 to 202 of 202 Information bits
|
||
Beacon Feedback
|
||
(acknowledgement of RLM reception)
|
||
(22 bits)
|
||
Unassigned
|
||
(11 bits)
|
||
National Use
|
||
(44 bits)
|
||
Dilution of Precision
|
||
(8 bits)
|
||
Activation
|
||
(2 bits)
|
||
Rotating Field \#15 (Cancellation Message) (48 bits)
|
||
Rotating Field bit number
|
||
Rotating
|
||
Field ID
|
||
"0000"
|
||
(4 bits)
|
||
Rotating
|
||
Field ID
|
||
"0001"
|
||
(4 bits)
|
||
Rotating
|
||
Field ID
|
||
"0010"
|
||
(4 bits)
|
||
Rotating
|
||
Field ID
|
||
"0011"
|
||
(4 bits)
|
||
Rotating
|
||
Field ID
|
||
"1111"
|
||
(4 bits)
|
||
Rotating Field \#2 (RLS) (48 bits)
|
||
Rotating Field bit number
|
||
Bits 155 to 202 of 202 Information bits
|
||
Rotating Field \#3 (National Use) (48 bits)
|
||
Fixed (all 1's)
|
||
(42 bits)
|
||
Method of
|
||
Deactivation
|
||
GNSS Status
|
||
(2 bits)
|
||
Remaining
|
||
Battery (2 bits)
|
||
Spare
|
||
(9 bits)
|
||
Unassigned
|
||
(2 bits)
|
||
Beacon RLS
|
||
Capability
|
||
(6 bits)
|
||
RLS
|
||
Provider ID
|
||
(3 bits)
|
||
Remaining
|
||
Battery
|
||
(3 bits)
|
||
GNSS Status
|
||
(2 bits)
|
||
Spare
|
||
(2 bits)
|
||
Elapsed Time
|
||
since Activation
|
||
(6 bits)
|
||
Time from last encoded location
|
||
(11 bits)
|
||
Altitude of encoded location
|
||
(10 bits)
|
||
NOTE: When displaying a message as 63 hex characters, one bit is inserted at the beginning of the
|
||
message to indicate the PRN sequence (0 = Normal, 1 = self-test), followed by one zero, to form the 63
|
||
hexadecimal representation (2 bits + 250 bit message) for processing by the Cospas-Sarsat ground
|
||
segment.
|
||
- END OF APPENDIX E -
|
||
|
||
F-1
|
||
|
||
APPENDIX F - MOFFSET CALCULATIONS AND CRC CODE SAMPLE
|
||
Note that the computation of the CRC for the MOffset uses an initial value of 0000 (hexadecimal),
|
||
which does not affect the computation shown below.
|
||
1 0 0 1 1 0 0 1 0 0 1 1 0 1 0 0 0 0 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 0 1 0 0 0 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 CRC-polynomial: x16+x15+x2+1
|
||
15 Hex ID: 9934039823D8000
|
||
0 1 0 1 1 0 0 1 0 0 1 1 0 1 1 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 1 0 0 1 0 0 1 1 0 1 1 1 1 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 1 0 0 1 0 0 1 1 0 1 1 1 0 1 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 1 1 1
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 1 1 1 0 1 0 1 0 1 0 1 0 0 1 1 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 1 0 1 0 1 0 1 0 1 0 0 1 0 1 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 1 0 1 0 1 0 0 1 0 1 0 1 1 1 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 1 0 0 1 0 1 0 1 1 1 1 0 1 1 0 1 1
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 0 1 0 1 0 1 1 1 1 0 1 1 1 1 0 1
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 0 1 0 1 1 1 1 0 1 1 1 0 0 0 1
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 1 0 1 1 1 1 0 1 1 1 0 1 0 0 0 1 1
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 1 1 1 0 1 1 1 0 1 0 0 1 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 1 1 1 0 1 1 1 0 1 0 0 1 0 0 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 1 0 1 1 1 0 1 0 0 1 0 0 0 0 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 1 1 0 1 0 0 1 0 0 0 0 0 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 1 1 0 1 0 0 1 0 0 0 0 0 1 1 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 1 0 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 0 1 0 0 0 0 0 1 1 0 0 1 1 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 0 0 0 0 0 1 1 0 0 1 1 1 1 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 0 0 0 0 1 1 0 0 1 1 1 0 1 1 0 0 0 0 0 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 0 0 1 1 1 0 1 1 0 0 0 0 1 0 1 0 0 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 1 0 1 1 0 0 0 0 1 0 1 0 1 0 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 1 1 0 0 0 0 1 0 1 0 1 0 0 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 0 1 0 0 0 0 1 0 1 0 1 0 0 1 1 1 0 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 0 0 0 1 0 1 0 1 0 0 1 1 0 0 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 0 0 1 0 1 0 1 0 0 1 1 0 1 1 1 0
|
||
1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
|
||
0 1 0 1 0 1 0 1 0 0 1 1 0 1 0 1 1
|
||
CRC-16(9934039823D8000) = 0xAA6B
|
||
and Moffset=BIN2DEC(CRC-16(9934039823D8000)) mod 60 = 7
|
||
Figure F-1: Example of calculation of Moffset
|
||
|
||
F-2
|
||
|
||
- END OF APPENDIX F -
|
||
|
||
G-1
|
||
|
||
APPENDIX G - EXAMPLES OF RLS GNSS RECEIVER TIMING
|
||
The operation of the RLS GNSS Receiver is defined in section 4.5.9.2 of this document. A set of examples
|
||
of RLS operation are provided in Table G.1, which cover a range of conditions to clarify the interpretation
|
||
of the Moffset timing, and are summarized below:
|
||
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.
|
||
|
||
G-2
|
||
|
||
Table G.1:
|
||
Example Scenarios for RLS GNSS Timing
|
||
Description of GNSS and
|
||
Beacon Operation
|
||
Beacon
|
||
RLM
|
||
Attempt
|
||
Example 1
|
||
Example 2
|
||
UTC + Moffset 59 minutes,
|
||
No RLM received
|
||
No UTC + Moffset 1 minutes,
|
||
UTC acquired at 2:34,
|
||
RLM received at 4:07
|
||
Time at which Beacon
|
||
is Activated
|
||
0:00
|
||
0:17
|
||
Time of first RLM
|
||
Request transmission
|
||
|
||
0:01
|
||
0:18
|
||
GNSS Receiver first
|
||
30 minute on period
|
||
0:30
|
||
0:47\*
|
||
GNSS Receiver next turns on at
|
||
|
||
0:59
|
||
1:02
|
||
GNSS Receiver next turns off at
|
||
1:14
|
||
1:05
|
||
GNSS Receiver next turns on at
|
||
|
||
1:59
|
||
1:17
|
||
GNSS Receiver next turns off at
|
||
2:14
|
||
1:20
|
||
GNSS Receiver next turns on at
|
||
|
||
2:59
|
||
1:32
|
||
GNSS Receiver next turns off at
|
||
3:14
|
||
1:35
|
||
GNSS Receiver next turns on at
|
||
|
||
3:59
|
||
1:47
|
||
GNSS Receiver next turns off at
|
||
4:14
|
||
2:02
|
||
GNSS Receiver next turns on at
|
||
|
||
4:59
|
||
2:32
|
||
GNSS Receiver next turns off at
|
||
5:14
|
||
2:34†
|
||
GNSS Receiver next turns on at
|
||
|
||
5:59
|
||
3:01
|
||
GNSS Receiver next turns off at
|
||
6:00‡
|
||
3:16
|
||
GNSS Receiver next turns on at
|
||
|
||
4:01
|
||
GNSS Receiver next turns off at
|
||
4:07§
|
||
GNSS Receiver reverts to non-
|
||
RLS operation
|
||
6:00
|
||
4:07
|
||
Note that interleaved with the GNSS Receiver timings, the GNSS receiver also turns on in accordance
|
||
with section 4.5.5.2, as well in Examples 1, 3 and 4, but these GNSS 'on' periods are omitted for clarity
|
||
in the tables.
|
||
* Timing reverts to schedule per document C/S T.018, section 4.5.5.2.
|
||
† UTC acquired, back to RLS schedule
|
||
‡ Last ‘on’ period, 1-minute duration, as 6 hours have elapsed from beacon turn-on.
|
||
§ With no UTC reference, receiver reverts to document C/S T.018 section 4.5.5.2 timing, until UTC is obtained.
|
||
|
||
G-3
|
||
|
||
Table G.1 (Continued):
|
||
Example Scenarios for RLS GNSS Timing
|
||
Description of GNSS and
|
||
Beacon Operation
|
||
Beacon
|
||
RLM
|
||
Attempt
|
||
Example 3
|
||
Example 4
|
||
Example 5
|
||
UTC + Moffset
|
||
17 minutes,
|
||
No RLM received
|
||
UTC + Moffset
|
||
20 minutes,
|
||
RLM received at
|
||
2:29
|
||
UTC + Moffset
|
||
11 minutes,
|
||
RLM received at
|
||
0:45
|
||
Time at which Beacon
|
||
is Activated
|
||
0:58
|
||
0:14
|
||
0:40
|
||
Time of first RLM
|
||
Request transmission
|
||
|
||
0:59
|
||
0:15
|
||
0:41
|
||
GNSS Receiver first
|
||
30 minute on period
|
||
1:28
|
||
0:44
|
||
0:45\*
|
||
GNSS Receiver next turns on at
|
||
|
||
2:17
|
||
1:20
|
||
GNSS Receiver next turns off at
|
||
2:32
|
||
1:35
|
||
GNSS Receiver next turns on at
|
||
|
||
3:17
|
||
2:20
|
||
GNSS Receiver next turns off at
|
||
3:32
|
||
2:29†
|
||
GNSS Receiver next turns on at
|
||
|
||
4:17
|
||
GNSS Receiver next turns off at
|
||
4:32
|
||
GNSS Receiver next turns on at
|
||
|
||
5:17
|
||
GNSS Receiver next turns off at
|
||
5:32
|
||
GNSS Receiver next turns on at
|
||
|
||
6:17
|
||
GNSS Receiver next turns off at
|
||
6:32
|
||
GNSS Receiver next turns on at
|
||
|
||
‡
|
||
GNSS Receiver next turns off at
|
||
GNSS Receiver reverts to
|
||
non-RLS operation
|
||
6:32
|
||
2:29
|
||
0:45
|
||
– END OF APPENDIX G –
|
||
* GNSS only ‘on’ for 4 min until RLM received, Moffset never needed.
|
||
† GNSS only ‘on’ for 9 min, until RLM received.
|
||
‡ 6 hours up at 6:58, so no seventh attempt is initiated for this case.
|
||
|
||
H-1
|
||
|
||
APPENDIX H - RLS INFORMATION
|
||
H.1 Information to be Included in the User Manual of an RLS Type-1 Automatic Acknowledgement
|
||
Capable Beacon
|
||
This beacon has the Return Link Service (RLS) feature. The RLS feature is an indication on the
|
||
beacon that confirms to the beacon user that the distress signal from an activated beacon has been
|
||
localised by the Cospas-Sarsat system and is being sent to the responsible search-and-rescue (SAR)
|
||
authorities. It does NOT mean that a search and rescue has yet been organized/launched, but only
|
||
confirms that the distress alert has been received by the Cospas-Sarsat System and is being routed
|
||
to the appropriate SAR agencies.
|
||
The RLS is designed to send an acknowledgment to the beacon user in less than 30 minutes from
|
||
beacon activation (actual acknowledgement times are typically much quicker). Alerting of the
|
||
distress to SAR authorities is independent of (and may occur before) the RLS acknowledgment
|
||
indication on the beacon. The RLS specification is described in the Galileo SAR Service Definition
|
||
Document:
|
||
(https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-SAR-SDD.pdf).
|
||
RLS is an optional function and may not be permitted in all countries or for all beacon types. You
|
||
may visit the web page Where Can I Buy an RLS-Enabled Beacon?
|
||
(https://cospas-sarsat.int/en/beacon-ownership/rls-enabled-beacon-purchase) to learn the most
|
||
recent information about national support for RLS.
|
||
Cospas-Sarsat strongly recommends that you appropriately register your beacon. It only is possible
|
||
to register a beacon in the registry operated by the country matching the “country code”
|
||
electronically programmed into the beacon (or the International Beacon Registration Database
|
||
(IBRD) (https://www.406registration.com/) if the country uses the IBRD for their registrations).
|
||
For example, it only is possible to register a beacon with a French country code in France’s national
|
||
registry. However, owners of Belgian-coded beacons must register in the IBRD. The country code
|
||
is encoded in the beacon’s unique identification number (UIN, also called Hex ID), which is used
|
||
to
|
||
register
|
||
the
|
||
beacon.
|
||
Visit
|
||
the
|
||
web
|
||
page
|
||
Beacon
|
||
Registration
|
||
Contacts
|
||
(https://www.406registration.com/countriessupported.aspx) to see where you can register your
|
||
beacon.
|
||
|
||
H-2
|
||
|
||
H.2
|
||
Information to be Included in the User Manual of an RLS Type 3 TWC-Capable
|
||
Beacon
|
||
This beacon features the Two-Way Communication (TWC) capability.
|
||
The TWC function provides the beacon user with a confirmation indication that the distress signal
|
||
from an activated beacon has been detected by the Cospas-Sarsat System and is being transmitted to
|
||
the responsible Search-And-Rescue (SAR) Authorities.
|
||
It is important to note that this confirmation does NOT imply that a search and rescue operation has
|
||
been organized or initiated. In addition, the TWC feature enables the beacon user to establish
|
||
communication with the appropriate SAR Authorities.
|
||
TWC functionality relies on the exchange of information between beacon user and SAR Authorities,
|
||
aiming to facilitate and enhance SAR operations by allowing the beacon user to provide valuable
|
||
information to, or receive instructions from, SAR Authorities.
|
||
Upon beacon activation, a series of initial automatic questions will be displayed for the beacon user
|
||
to respond to. The answers encoded by the user will be transmitted to the SAR Authorities as soon as
|
||
possible. SAR Authorities have the capability to send new or previously asked questions and
|
||
instructions to the beacon user.
|
||
New messages sent from SAR Authorities will take priority over the initial automatic questions
|
||
should the user not have completed answering them.
|
||
The TWC is designed to send an acknowledgment to the beacon user in less than 30 minutes from
|
||
beacon activation (actual acknowledgement times are typically in the order of few minutes).
|
||
It is important to highlight that alerting the distress to SAR authorities is independent of, and may
|
||
occur before, the TWC acknowledgment indication on the beacon. The TWC specification is detailed
|
||
in the Galileo SAR Service Definition Document Issue (TBD).
|
||
TWC is an optional function and may not be permitted in all countries or for all beacon types. You
|
||
may visit the web page Where Can I Buy an TWC-Enabled Beacon? (TBD) to learn the most recent
|
||
information about national support for TWC.
|
||
Cospas-Sarsat strongly recommends that you appropriately register your beacon. It only is possible to
|
||
register a beacon in the registry operated by the country matching the “country code” electronically
|
||
programmed into the beacon or the International Beacon Registration Database (IBRD)
|
||
(https://www.406registration.com/) if the country uses the IBRD for their registrations. For example,
|
||
it only is possible to register a beacon with a French country code in France’s national registry.
|
||
However, owners of Belgian-coded beacons must register in the IBRD. The country code is encoded
|
||
in the beacon’s unique identification number (UIN, also called Hex ID), which is used to register the
|
||
beacon. Visit the web page Beacon Registration Contacts to see where you can register your beacon.
|
||
(https://www.406registration.com/countriessupported.aspx)
|
||
– END OF APPENDIX H –
|
||
|
||
I-1
|
||
|
||
APPENDIX I - BASIC BEACON PROGRAMMING GUIDANCE
|
||
The following text provides basic guidance on programming an SGB, further details can be found in
|
||
document C/S G.005 and in Table 3.1 of this document.
|
||
TAC Number – The Type Approval Certificate number between 10,000 and 17,999 assigned to the
|
||
beacon by the Secretariat excluding the suffixes ‘M’ and ‘m’, see document C/S T.021 Section 2.2.1
|
||
for further details.
|
||
Serial Number – A numerical serial number between 0 and 16,383 assigned by the beacon
|
||
manufacturer to a beacon during production.
|
||
The TAC and Serial Number together form a unique identity for each beacon produced and shall not
|
||
be capable of being changed once programmed by the manufacturer. Once a manufacturer uses up all
|
||
available serial numbers, they shall apply to the Secretariat for an Extension TAC in order to continue
|
||
inserting a unique identity into every beacon that they produce. Identities shall never be reused, if for
|
||
example a beacon is scrapped, then that identity is not reused.
|
||
Country Code – The three-digit decimal country code based on the ITU MID related to the country
|
||
of beacon registration, or the normal place of residence of the beacon owner. Note that the Country
|
||
Code is not necessarily the same as the first 3 digits of the Maritime Mobile Service Identity (MMSI)
|
||
that may be assigned to a beacon associated with a vessel. The country code may be changed as
|
||
necessary during the life of a beacon to reflect changes of beacon registration or place of residence.
|
||
Vessel ID – If a Vessel (Aircraft or Ship) Identity is available / known then it should be included in
|
||
the beacon message using one of the following options:
|
||
SHIPS – In addition to the TAC and Serial Number ships may also be coded with either the MMSI of
|
||
the vessel or its Radio Call Sign, with preference being given to the former, if neither are available
|
||
then these fields are set to default values.
|
||
MMSI – An identity allocated to a beacon associated with a vessel in accordance with
|
||
Recommendation ITU-R M.585. This may be the MMSI assigned to a ship station as defined in ITU-
|
||
R M.585 Annex 1 Section 1 or the MMSI assigned to a craft associated with a parent ship as defined
|
||
in ITU-R M.585 Annex 1 Section 5. It shall not be the freeform number identity as defined in ITU-R
|
||
M.585 Annex 2 Section 2, commencing with 970, 972 or 974 which is only used to identify an AIS
|
||
locating signal transmitter if one is included as part of a 406 MHz beacon. However, if the beacon
|
||
includes an AIS locating signal, then the AIS identity commencing with 974 should be added in bits
|
||
94-123 AFTER the ships MMSI.
|
||
Note that if during the life of a beacon a vessel on which it is provided changes flag state and as a result
|
||
is allocated a different MMSI, then the MMSI in the beacon must be updated accordingly. This will
|
||
not affect the identity of the AIS locating signal, however, as this is not linked to the vessel identity.
|
||
Radio Call Sign – If an MMSI for the vessel is not available then the ships Radio Call Sign may be
|
||
inserted here instead. Radio Call Signs of up to 7 characters may be inserted.
|
||
|
||
I-2
|
||
|
||
AIRCRAFT – In addition to the TAC and Serial Number aircraft may also be coded with one of three
|
||
forms of identity, either the Aircraft Registration Marking (commonly referred to as the Tail Number),
|
||
the Aviation 24-Bit Address (as used by the ADS-B system) or the Aircraft Operator designator
|
||
followed by a serial number. The Aviation 24-Bit Address may also be followed by the 3-letter Aircraft
|
||
Operator Designator (3LD), which is essential for ELT(DT)s.
|
||
Aircraft Registration Marking – This identity, often referred to as the aircraft Tail Number can be
|
||
encoded in up to 7 alphanumerical characters.
|
||
Aviation 24-Bit Address – This identity is becoming more common in larger aircraft as it is allocated
|
||
to an aircraft for use with systems such as the ADS-B. For ELT(DT)s required to meet the Automatic
|
||
Distress Tracking (ADT) requirements of the ICAO GADSS system, it is essential to code the
|
||
ELT(DT) with the aircraft 24-Bit address followed by the 3-letter Aircraft Operator Designator, as both
|
||
of these data items are required by the ICAO Location of an Aircraft in Distress Repository (LADR).
|
||
Note that the Aircraft 24-Bit address followed by the Aircraft Operator Designator can also be used to
|
||
code ELTs other than ELT(DT)s if required.
|
||
Aircraft Operator and Serial Number – This identity is less common but can be used to identify an
|
||
aircraft it consists of the identity of the aircraft operator followed by a serial number allocated to the
|
||
beacon by the aircraft operator to create a unique identity for that aircraft.
|
||
– END OF DOCUMENT –
|
||
|
||
Cospas-Sarsat Secretariat
|
||
1250 René-Lévesque Blvd. West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada
|
||
Telephone: +1 514 500 7999
|
||
Fax: +1 514 500 7996
|
||
Email: mail@cospas-sarsat.int
|
||
Website: http://www.cospas-sarsat.int |