Design and implementation of a SCA- based SDR system for ...

Master’s Thesis in Telecommunications Engineering University of Vigo

Design and implementation of a SCA-

based SDR system for receiving

maritime signals

Víctor Silva Santos

Master’s Thesis presented to the Telecommunications Engineering School

Master’s Degree in Telecommunications Engineering

Supervisors

María Dolores Valdés Peña

Jesús Manuel Costa Pazó

2020


Acknowledgments

The work presented in this document represents the culmination of so many bright individuals

that contributed to my growth as a professional. Firstly, I would like to thank to the entire

Centum RT staff for their support, guidance and encouragement. Specifically, I am grateful to

the development team with whom I have had the pleasure of working over the years: Pablo, Fer,

Tito, Jota, David. Thanks for sharing your experience, knowledge and support.

My greater appreciation goes to my supervisor Suso for his assistance and patience during the

development of this work. It would have been impossible to develop this project without your

support. Also, I gratefully acknowledge the help of my academic supervisor Loly. Thanks for

your guidance and encouragement over these academic years.

I would like to thank to my lifelong friends for bringing a smile to my face each time that I see

them. Also, I would like to thank and mention to my classmates for their help during my college

years.

Finally, I would like to thank my family for being there for me over the years. Most of all, I give

thanks to my parents because without their hard work, sacrifice and humility I would not have

had the opportunity to achieve my goals.


i

Contents Contents ................................................................................................................................... i

List of figures ..........................................................................................................................iv

List of tables ............................................................................................................................vi

Nomenclature .........................................................................................................................vii

Abstract .................................................................................................................................... x

Resumen ..................................................................................................................................xi

1 Introduction ...................................................................................................................... 1

1.1 Context ...................................................................................................................... 3

1.2 Scope ........................................................................................................................ 3

1.3 Document structure.................................................................................................... 4

2 State of the art ................................................................................................................... 5

2.1 Automatic Identification System ................................................................................ 5

2.2 NMEA0183 standard ................................................................................................. 6

2.2.1 NMEA sentence format ...................................................................................... 6

2.3 Emergency Position-Indicating Radio Beacon ............................................................ 7

2.4 Software-Defined Radio ............................................................................................ 8

2.5 Universal Software Radio-Peripheral ....................................................................... 10

2.6 SCA ........................................................................................................................ 12

2.6.1 SCA Architecture ............................................................................................. 13

2.6.1.1 SCA Core Framework .................................................................................. 14

2.6.1.2 Domain Profiles ........................................................................................... 16

2.6.2 SCA implementations ...................................................................................... 17

2.6.2.1 OSSIE .......................................................................................................... 17

2.6.2.2 REDHAWK ................................................................................................. 17

2.7 CORBA ................................................................................................................... 18

3 Study & design ................................................................................................................ 19

3.1 EPIRB: study & design ............................................................................................ 19

3.1.1 Signal form and characterization ...................................................................... 19

3.1.1.1 Bit synchronization ...................................................................................... 21

3.1.1.2 Frame synchronization ................................................................................. 21

3.1.1.3 Format flag .................................................................................................. 21

3.1.1.4 Protocol flag................................................................................................. 22

3.1.1.5 Country code ................................................................................................ 22

3.1.1.6 Data field ..................................................................................................... 22

3.1.1.7 Non-protected data field ............................................................................... 22

3.1.1.8 User protocol codes ...................................................................................... 23


ii

3.1.1.9 Location protocols........................................................................................ 24

3.1.2 EPIRB design: detector and demodulator ......................................................... 26

3.1.2.1 EPIRB detector ............................................................................................ 26

3.1.2.2 EPIRB demodulator ..................................................................................... 30

3.1.3 Validation and results ....................................................................................... 34

3.1.3.1 EPIRB test signal ......................................................................................... 35

3.1.3.2 Validation results ......................................................................................... 36

3.2 AIS: study & design ................................................................................................ 41

3.2.1 Signal form and characterization ...................................................................... 41

3.2.1.1 GMSK modulation ....................................................................................... 42

3.2.1.2 Medium access control scheme .................................................................... 43

3.2.1.3 AIS packet format ........................................................................................ 44

3.2.2 AIS design: detector and demodulator .............................................................. 46

3.2.2.1 AIS detector ................................................................................................. 46

3.2.2.2 AIS demodulator .......................................................................................... 48

3.2.3 Validation and results ....................................................................................... 50

3.2.3.1 AIS test signal .............................................................................................. 50

3.2.3.2 Validation results ......................................................................................... 50

4 Implementation ............................................................................................................... 53

4.1 Dependencies .......................................................................................................... 53

4.1.1 Liquid-Dsp....................................................................................................... 53

4.1.2 Protocol Buffers ............................................................................................... 54

4.2 Implementation in C/C++ ........................................................................................ 57

4.2.1 EPIRB ............................................................................................................. 57

4.2.1.1 EPIRB detector ............................................................................................ 57

4.2.1.2 EPIRB demodulator ..................................................................................... 61

4.2.1.3 EPIRB decoder ............................................................................................ 63

4.2.2 AIS .................................................................................................................. 65

4.2.2.1 AIS detector and demodulator ...................................................................... 65

4.3 Implementation in REDHAWK ............................................................................... 70

4.3.1 REDHAWK components ................................................................................. 70

4.3.1.1 EPIRB ......................................................................................................... 70

4.3.1.2 AIS .............................................................................................................. 72

4.3.1.3 Message dispatcher component .................................................................... 74

4.3.2 REDHAWK waveforms ................................................................................... 75

4.3.2.1 EPIRB waveform ......................................................................................... 75

4.3.2.2 AIS waveform .............................................................................................. 76


iii

4.3.3 REDHAWK node ............................................................................................ 77

5 Results ............................................................................................................................ 79

5.1 Set-up for testing ..................................................................................................... 79

5.2 Launching the SCA domain ..................................................................................... 80

5.3 Results from EPIRB waveform ................................................................................ 80

5.4 Results from AIS waveform ..................................................................................... 82

6 Conclusions .................................................................................................................... 85

7 Future lines ..................................................................................................................... 86

8 Bibliography ................................................................................................................... 87

APPENDIX I: REDHAWK components creation concepts ..................................................... 90


iv

List of figures

Figure 1.1 Block diagram of Lifeeker Maritime. ........................................................................ 1 Figure 1.2 Lifeseeker Unit and Distress Signals Detector Unit physical chassis. ........................ 2 Figure 1.3 Example of an operational mission with Lifeseeker Maritime mounted on SAR’s

helicopter. ................................................................................................................................. 2 Figure 2.1 AIS transponder used on vessels. .............................................................................. 5 Figure 2.2 EPIRB portable devices. ........................................................................................... 8 Figure 2.3 Block diagram of an SDR system [6]. ....................................................................... 9 Figure 2.4 RF flexible frontend block diagram. ....................................................................... 10 Figure 2.5 USRP receiver block diagram. ................................................................................ 11 Figure 2.6 USRP N210 and its internal architecture [7]. .......................................................... 11 Figure 2.7 USRP B210 and its internal architecture [8]. ........................................................... 12 Figure 2.8 SCA architecture layers and elements [11]. ............................................................. 13 Figure 2.9 The Core Framework interfaces available in the SCA architecture. ......................... 14 Figure 2.10 Relational Diagram of XML Domain Profiles [13]................................................ 16 Figure 2.11 Main software implementations and IDEs to work on SCA systems. ..................... 17 Figure 3.1 EPIRB message format [19]. .................................................................................. 20 Figure 3.2 EPIRB detector processing stages. .......................................................................... 26 Figure 3.3 Block diagram of the sequence of calculations needed to implement the FFT-

channelization process. ........................................................................................................... 27 Figure 3.4 Filters for the detected signal. ................................................................................. 28 Figure 3.5 CIC frequency response.......................................................................................... 29 Figure 3.6 Selective FIR filter design. ..................................................................................... 29 Figure 3.7 Frequency response for selective FIR filter. ............................................................ 30 Figure 3.8 Frequency response for compensation FIR filter. .................................................... 30 Figure 3.9 Data encoding and modulation sense. ..................................................................... 31 Figure 3.10 General structure of the EPIRB demodulator. ....................................................... 31 Figure 3.11 Preamble phase angle of EPIRB's burst signal before being corrected. .................. 32 Figure 3.12 Preamble phase angle of EPIRB's burst signal after being corrected. ..................... 32 Figure 3.13 EPIRB demodulator's state machine. .................................................................... 33 Figure 3.14 (a) EPIRB beacon device. (b) Instructions to trigger distress or test signal from EPIRB

beacon device. ........................................................................................................................ 35 Figure 3.15 FFT from EPIRB signal data. No transmission...................................................... 36 Figure 3.16 FFT from EPIRB signal. The 406.037 MHz channel (channel F) begins to transmit

the carrier wave preamble. ...................................................................................................... 37 Figure 3.17 FFT from EPIRB signal. Modulated carrier. ......................................................... 37 Figure 3.18 FFT from EPIRB signal. End of transmission. ...................................................... 38 Figure 3.19 Introducing the demodulated message in EPIRB official decoding tool. ................ 38 Figure 3.20 Decoded EPIRB message. .................................................................................... 39 Figure 3.21 EPIRB beacon device data. ................................................................................... 40 Figure 3.22 OSI model for AIS system [1]. ............................................................................. 41 Figure 3.23 AIS burst data transmitting time [1]. ..................................................................... 42 Figure 3.24 Block diagram of a FM-GMSK ............................................................................ 43 Figure 3.25 AIS message packet format. ................................................................................. 44 Figure 3.26 Unmodified bit pattern vs modified bit pattern by NRZI. ...................................... 44 Figure 3.27 AIS detector processing stages.............................................................................. 47 Figure 3.28 Filter for the detected signal. ................................................................................ 47 Figure 3.29 Low pass filter frequency response. ...................................................................... 47 Figure 3.30 Sample angle values from AIS burst preamble without correction. ........................ 48


v

Figure 3.31 Sample angle values from AIS burst preamble with correction. ............................. 49 Figure 3.32 Correlation against an ideal training sequence in order to detect burst's preamble. . 49 Figure 3.33 FFT from AIS signal data. Both AIS channels are not transmitting any signal. ...... 51 Figure 3.34 FFT from AIS signal data. Channel AIS-2 begins to transmit. ............................... 51 Figure 3.35 Output results of MATLAB script that tests AIS detector, demodulator and decoder.

............................................................................................................................................... 52 Figure 3.36 Vessel public information from Marine Traffic webpage for the decoded AIS signal

(MMSI 263528000). ............................................................................................................... 52 Figure 4.1 API with utility functions. ...................................................................................... 54 Figure 4.2 AIS Protobuf description file. ................................................................................. 55 Figure 4.3 EPIRB Protobuf description file. ............................................................................ 57 Figure 4.4 File header for EPIRB detector (epirb-detect.h). ..................................................... 58 Figure 4.5 Global variables and definitions for epirb-detect.c component. ............................... 59 Figure 4.6 Source code for EPIRB detector example. .............................................................. 60 Figure 4.7 Results from EPIRB detector example. ................................................................... 61 Figure 4.8 File header for EPIRB demodulator. ....................................................................... 61 Figure 4.9 Source code for EPIRB demodulator example. ....................................................... 62 Figure 4.10 Results from EPIRB demodulator example. .......................................................... 63 Figure 4.11 File header for EPIRB decoder. ............................................................................ 63 Figure 4.12 Source code for EPIRB decoder example. ............................................................. 64 Figure 4.13 Results from EPIRB decoder example. ................................................................. 64 Figure 4.14 File header for AIS detector and demodulator. ...................................................... 65 Figure 4.15 Source code for AIS detector and demodulator example. ...................................... 68 Figure 4.16 Result from AIS detector and demodulator example. ............................................ 69 Figure 4.17 a) Introducing the NMEA sentence in AIS decoding tool from http://ais.tbsalling.dk/.

b) Decoded AIS message. ....................................................................................................... 69 Figure 4.18 EPIRB demodulator REDHAWK component file hierarchy and block. ................. 71 Figure 4.19 EPIRB decoder REDHAWK component file hierarchy and block. ........................ 72 Figure 4.20 AIS demodulator REDHAWK component file hierarchy and block. ..................... 73 Figure 4.21 NMEA to Protobuf REDHAWK component file hierarchy and block. .................. 74 Figure 4.22 Message dispatcher REDHAWK component files hierarchy and block. ................ 75 Figure 4.23 EPIRB waveform block diagram. ......................................................................... 76 Figure 4.24 Frontend tuner device configuration for the EPIRB waveform. ............................. 76 Figure 4.25 AIS waveform block diagram. .............................................................................. 77 Figure 4.26 Frontend tuner device configuration for AIS waveform......................................... 77 Figure 4.27 Node GPP and USRP devices. .............................................................................. 78 Figure 5.1 Physical set-up for final tests. ................................................................................. 79 Figure 5.2 Launching REDHAWK domain and node through nodeBooter. .............................. 80 Figure 5.3 EPIRB waveform running in REDHAWK IDE. The bottom graph is the FFT of the

dataFloat output from DataConverter. ..................................................................................... 81 Figure 5.4 Terminal output in which EPIRB signal is being decoded by the EPIRB waveform.82 Figure 5.5 SCS web console. EPIRB decoded message details. ............................................... 82 Figure 5.6 AIS waveform running in REDHAWK IDE. The bottom graph is the FFT of the

dataFloat output from ArbitraryResampler. ............................................................................. 83 Figure 5.7 Terminal output in which multiple AIS signals are being decoded by the AIS waveform

............................................................................................................................................... 83 Figure 5.8 SCS web console. AIS decoded message details for MMSI 263528000. ................. 84 Figure 0.1 Encapsulation process for any processing element into an auto-generated REDHAWK

component wrapper [16]. ........................................................................................................ 90


vi

List of tables

Table 3.1 EPIRB assigned channels and its status. ................................................................... 19 Table 3.2 Data fields for the short message format. ................................................................. 21 Table 3.3 Data fields for the long message format ................................................................... 21 Table 3.4 Maritime Emergency Codes ..................................................................................... 23 Table 3.5 Non maritime Emergency Codes.............................................................................. 23 Table 3.6 User protocol codes. ................................................................................................ 23 Table 3.7 User-Location protocols code [20]. .......................................................................... 24 Table 3.8 Standard and Standard-Short Location protocols codes [20] ..................................... 25 Table 3.9 National and National-Short Location protocols codes [20]. ..................................... 25 Table 3.10 TDMA types that are used depending the AIS class of the system or its specific

application. ............................................................................................................................. 43 Table 3.11 AIS message types [1] [23]. ................................................................................... 45 Table 3.12 Communication state parameters [1]. ..................................................................... 46 Table 3.13 Decoded parameters of the testing AIS burst signal. ............................................... 52 Table 4.1 Six bit ASCII characters [1]. .................................................................................... 67


vii

Nomenclature

ADC Analog-to-Digital Converter

AIS Automatic Identification System

AOA Angle of arrival

AtoN Aids-to-Navigation

ASCII American Standard Code for Information Interchange

CCM CORBA Component Model

CIC Cascaded Integrator-Comb Filter

CF Core Framework

COG Course Over Ground

CW Carrier Wave

COSPAS-SARSAT Cosmicheskaya Sistema Poiska Avariynyh Sudov

CSTDMA Carrier Sense TDMA

DAC Digital-to-Analog Converter

DCD Device Configuration Descriptor

DFT Discrete Fourier Transform

DGPS Differential GPS

DPD Device Package Descriptor

DSDU Distress Signals Detector Unit

DSP Digital Signal Processor

ELT Emergency Locator Transmitter

EPIRB Emergency Position-Indicating Radio Beacon

ETSI European Telecommunication Standards Institute

FIR Finite Impulse Filter

FM Frequency Modulation

FPGA Field Programmable Gate Array

GIOP General InterORB Protocol

GLONASS GLobal NAvigation Satellite System

GMDSS Global Maritime Distress and Safety System

GMSK Gaussian Minimum Shift Keying

GPIRB GPS Position-Indicating Radio Beacon


viii

GPP General Purpose Processor

GSM Global System for Mobile

GPS Global Positioning System

HTIOP HyperText InterORB Protocol

IDL Interface Definition Language

IIOP Internet InterORB Protocol

IMO International Maritime Organization

I/O Input/Output

ISI Intersymbol Interference

ITDMA Incremental TDMA

ITU International Telecommunications Union

JTNC Joint Tactical Networking Center

JTRS Joint Tactical Radio System

LFSU Lifeseeker Unit

LNA Low Noise Amplifier

MID Maritime Identification Digit

MIMO Multiple Input Multiple Output

MMSI Maritime Mobile Service Identity

MPRG Mobile and Portable Radio Research Group

NMEA National Marine Electronics Association

NRZI Non-Returned to Zero Inverted

OMG Object Management Group

ORB Object Request Broker

OSI Open Systems Interface

OSM Open Street Maps

OSSIE Open-Source SCA Implementation Embedded

PLB Personal Locator Beacon

PRF Properties File

RAIM Receiver Autonomous Integrity Monitoring

RATDMA Random Access TDMA

REST Representational State Transfer

RF Radio Frequency


ix

RX Receive

SAD Software Assembly Descriptor

SAR Search And Rescue

SART SAR Transponder

SCA Software Communications Architecture

SCD Software Component Descriptor

SCS Sensor Control Sytem

SDR Software Defined Radio

SMS Short Message Service

SEPIRB Submarine Emergency Position-Indicating Radio Beacon

SOLAS Safety of Life at Sea

SOG Speed Over Ground

SOTDMA Self-Organized TDMA

SPD Software Package Descriptor

SRI Signal Related Information

SSAS Ship Security Alert System

SSL Secure Sockets Layer

SSLIOP SSL InterORB Protocol

TDMA Time-Division Multiple Access

TX Transmit

UHD USRP Hardware Driver

URI Uniform Resource Identifier

URL Uniform Resource Locator

USRP Universal Software Radio Peripheral

UTC Universal Time Coordinated

VHF Very High Frequency

WOLA Weighted Overlap Add

XML Extensible Markup Language

ZIOP Zipped InterORB Protocol


x

Abstract

This master’s thesis in Telecommunication Engineering is focused on the study, design and

development of an SDR solution over an SCA framework. The development of this project has

been carried out in Centum Research and Technology as a part of a commercial product, the

Lifeseeker Maritime.

The SDR system allows the reception, demodulation and decoding of EPIRB and AIS signals,

commonly used on maritime environments as distress signals. The final SCA system runs on a

host PC connected via USB to an USRP acting as the radio front-end for the reception of the

maritime signals. In particular, the USRP B210 from Ettus Research has been the selected

platform.

Firstly, to carry out this project, EPIRB and AIS signals were studied in order to design the signal

detectors and demodulators in MATLAB. The correct design and test of these components is a

very important preliminary step before their final implementation. Therefore, for a precise

validation, real signals were used as input for MATLAB scripts and output bits were checked

against official decoder tools.

Once MATLAB scripts were validated, EPIRB and AIS demodulators were implemented on the

final platform. Since the SCA framework (Redhawk) only supports C, C++, Python and Java

languages, components have been developed on C which has a better performance for signal

processing. Again, the implemented components were validated using the same real signals as in

the case of the MATLAB scripts.

In order to integrate these detector and demodulators on the SCA system, new SCA components

were created by wrapping up the already implemented demodulators. These wrapped components

have the SCA defined interfaces which allow them to communicate with the rest of the SCA

system devices, components and applications.

SCA system supports two different applications (or waveforms, the so-called applications on SCA

environments). Applications are a set of interconnected devices and components that run a

specific signal processing task for a specific purpose. Thus, the USRP platform was configured

and interconnected to the EPIRB and AIS demodulators and/or decoders SCA components.

Finally, the SCA system was deployed on a host PC connected to the USRP. The URSP receives

EPIRB and AIS signals to demodulate and decode them. In order to transmit these signals, another

USRP is used to reproduce the real EPIRB and AIS signals used on the whole process of design,

development and test.

Key words: Software Defined Radio, Software Communications Architecture, Redhawk,

Universal Software Radio Peripheral, Emergency Position-Indication Radio Beacon, Automatic

Identification System, maritime distress signals, signal processing.


xi

Resumen

En este Trabajo Fin de Máster (TFM) de Ingeniería de Telecomunicación se presenta el estudio,

diseño y desarrollo de una solución SDR sobre un framework de SCA. El desarrollo de este

proyecto se ha llevado a cabo en la empresa Centum Research and Technology como parte de un

producto comercial, el Lifseeker Maritime.

Este sistema SDR permite la recepción, demodulación y decodificación de señales EPIRB y AIS,

comúnmente utilizadas en entornos marítimos como señales de auxilio.

El sistema SCA final se basa en un PC host conectado a través de USB a un USRP (Universal

Software Radio Peripheral) que se utiliza como frontal de radio para la recepción de señales

marítimas. En particular, se utiliza el USRP B210 de Ettus Research como plataforma de radio.

Para llevar a cabo el TFM, primeramente se han caracterizado las señales EPIRB y AIS con objeto

de diseñar los módulos detectores y demoduladores de señal en MATLAB. El correcto diseño y

validación de estos componentes es un paso importante antes de realizar la implementación. Para

la validación, se han utilizado señales reales como entrada a los scripts de MATLAB y la señal

digital de salida se ha contrastado contra herramientas de decodificación oficiales.

Una vez que los scripts de MATLAB han sido validados, se ha pasado a la fase de implementación

de los detectores y demoduladores EPIRB y AIS. Como el framework SCA a utilizar

(REDHAWK) soporta los lenguajes de programación C, C++, Python y Java, se ha optado por

desarrollar los componentes en C, porque tiene un mejor rendimiento en procesado de señales.

Para validar los componentes implementados en C se han utilizado las mismas señales reales de

entrada que en el caso de los modelos en MATLAB.

La siguiente fase de desarrollo del proyecto ha sido la integración de los demoduladores sobre el

sistema SCA. Para ello, ha sido necesario crear nuevos componentes SCA que encapsulen los

demoduladores implementados añadiéndoles las interfaces SCA necesarias para que se puedan

comunicar con el resto de los componentes, dispositivos y aplicaciones dentro del sistema SCA.

El sistema SCA correrá dos aplicaciones diferentes (o formas de onda, como se denominan en los

entornos SCA). Las aplicaciones son un conjunto de dispositivos y componentes interconectados

que realizan un procesamiento de señal concreto con un propósito concreto. Esto quiere decir que

ha sido necesario configurar el dispositivo USRP e interconectarlo con los demoduladores y

decodificadores SCA de EPIRB y AIS.

Finalmente, el sistema SCA ha sido desplegado sobre el PC huésped conectado al USRP. El USRP

recibe las señales EPIRB y AIS para demodularlas y decodificarlas. Para verificar el correcto

funcionamiento del sistema final se ha utilizado otro USRP que se encarga de reproducir y

transmitir las señales EPIRB y AIS utilizadas durante todo el proceso de diseño y validación.

Palabras clave: Software Defined Radio, Software Communications Architecture, Redhawk,

Universal Software Radio Peripheral, Emergency Position-Indication Radio Beacon, Automatic

Identification System, señales marítimas de auxilio, procesamiento de señal.


1

1 Introduction

This project has been developed as a master’s thesis to obtain the master’s degree in

Telecommunications Engineering from the Telecommunications Engineering School of the

University of Vigo. The development of this project has been carried out in Centum Research and

Technology as a part of a commercial product, the Lifeseeker Maritime. Lifeseeker Maritime is a

vehicle mounted computer system with two different units:

• LSFU (Lifeseeker Unit) is an electronic radio system that can detect and establish

connections with mobile phones via GSM (Global System for Mobile). Lifeseeker’s

purpose is to locate mobile phones in areas without mobile coverage or only GSM

coverage, by calculating the AOA of the GSM signal transmitted by the phone. It also

allows communication with the phone via SMS. This way, the system acts as a

communication channel between the victim and rescue services.

• DSDU (Distress Signals Detector Unit) is a software defined radio device capable of

detecting, classifying and providing relative bearing information of both GMDSS (Global

Maritime Distress and Safety System) devices and non-specific GMDSS devices used in

the event of an emergency. The DSDU can handle the following kinds of maritime

signals:

o EPIRB 121.5 MHz

o EPIRB 406 MHz

o AIS 162 MHz (channels 87B and 88B).

o VHF (Very High Frequency) Distress Calling.

Figure 1.1 shows a block diagram of Lifeseeker Maritime system and Figure 1.2 are the physical

chassis of both units.

Figure 1.1 Block diagram of Lifeeker Maritime.

Maritime

Signals

AIS EPIRB

GSM

Signal

LIFESEEKER MARITIME

LFSU

LFSU RF Frontend

Processing Unit

DSDU

DSDU RF Frontend

SCA System

VHF


2

Figure 1.2 Lifeseeker Unit and Distress Signals Detector Unit physical chassis.

Figure 1.3 depicts an example of an operational mission with the Lifeseeker Maritime mounted

on SAR’s helicopter. Lifeseeker Maritime can receive the EPIRB distress signal sent by the

beacon located in the ship. This signal is received by the COSPAS-SARSAT satellites too.

Additionality, AIS signals that contain information about that ship are being monitored by

Lifeseeker Maritime and the Rescue Center in land. Lastly, GSM signals from a lost person’s

smartphone are processed to calculate his position.

Figure 1.3 Example of an operational mission with Lifeseeker Maritime mounted on SAR’s helicopter.

The focus of this project will be on the DSDU, specifically on the EPIRB 406 MHz and AIS 162

MHz modules and its development.


3

1.1 Context

Distress and safety communications had been an important part for ships/vessels on the fields of

emergency and security. Since the invention of the radio (19th century) and after the sinking of

RMS Titanic in 1912, the U.S Congress enacted the legislation to use Morse code (invented by

Samuel Morse) radiotelegraph equipment in order to use it for distress signals on every ship over

the country. Later, the International Telecommunication Union (ITU) extended this legislation to

the rest of the countries within the consortium.

Although Morse encoded distress signal saved many lives, it has several limitations:

• It requires skilled radio operators who spend many hours listening to the radio distress

frequency.

• Its range is on the medium frequency distress band ~500 kHz.

• The amount of traffic Morse signals can carry is very limited.

For these reasons, the IMO (International Maritime Organization) started to look for ways to

improve maritime security-distress signals and in 1979 this group began the development of a

global search and rescue plan, under the name of Global Maritime Distress and Safety System

(GMDSS).

GMDSS is a set of security procedures, equipment and communication protocols mainly designed

to increase security, navigation facility and help for ships in distress situations.

This system would provide the communication support needed for search and rescue plans

through a combination of satellite and terrestrial radio services. This would change the

international distress communications from ship-to-ship to ship-to-shore (Rescue Coordination

Center).

GMDSS can provide automatic distress locating and alerting in cases where the radio operator

does not have enough time to send an SOS call.

SOLAS (Safety of Life at Sea) was the first maritime treaty which set minimum safety standards

for the construction, equipment and operation of merchant ships. This equipment should consist

in GMDSS devices. The main components or devices that ships need to be equipped with are

NAVTEX (an automated system for instantly distributing navigational and meteorological

warnings and forecasts), EPIRB devices and AIS transponders.

Nowadays, search and rescue teams and maritime surveillance teams are focused on analyzing

AIS signals in order to check information about the ships on the sea (source and destination ports,

ship type, goods on the ship…) and EPIRB signals in order to start a rescue mission.

1.2 Scope

The first goal of this master’s thesis is the study of EPIRB and AIS signals:

• Review of the purpose of EPIRB and AIS technologies and its applications.

• Study and characterization of the EPIRB and AIS signals. This will be an important step

in order to correctly design detectors and demodulators for both signals in MATLAB.

• Validation of the designed detectors and demodulators using real captured samples as

input for these components. The demodulated bits will be decoded and checked against

official decoding tools.


4

• Implementation of these detectors and demodulators in C modules. Validation of these

components against the same samples used on the design process.

• Implementation of EPIRB decoder in C++ module. Validation of this component against

the demodulated bits.

• Implementation of NMEA1803 sentence generator component for each AIS decoded

message.

Once all modules are designed, implemented and validated, the second objective is to study the

SDR and SCA framework in order to design and integrate previous the components:

• State of the art review of SDR and SCA technologies. State of the art of USRP and SDR

platforms in general.

• Implementation of SCA components based on previous C modules with the defined SCA

interfaces.

• Design of SCA applications which will configure the USRP at the correct frequency and

gain values. Setting up connection between the radio device and the SCA components in

order to create the SCA application or waveform.

• Configuration of all devices to be used in the SCA domain.

• Deployment of the SCA system on host PC connected to the USRP though USB.

• Transmission of real signals from other USRPs (out of SCA) to check whether the USRP

in the SCA system receives these signals and the system is capable of detecting,

demodulating and decoding EPIRB and AIS signals.

Finally, all results will be presented in a custom map interface in order to check that all data are

received and decoded.

1.3 Document structure

This master thesis has been divided in seven main chapters according to the objectives.

• Chapter 2: the state of the art will be presented. Each involved technology in this work

will be described to understand the basic concepts of the project.

• Chapter 3: this chapter will be devoted to the study of both maritime signals in order to

detect, demodulate and decode them. Additionally, this is the chapter in which all the

MATLAB components will be designed before the implementation stage. Here all the

component designs will be validated at MATLAB level.

• Chapter 4: this chapter will describe the implementations of all the components designed

in MATLAB in the previous chapter. Later on, these implemented components will be

wrapped up in REDHAWK components to design the REDHAWK waveforms and the

REDHAWK node.

• Chapter 5: this chapter will be devoted to present the results obtained via the execution

of the final SCA system that will run the EPIRB and AIS waveforms. These results will

contain information about the decoded signals which will be depicted in an external UI.

• Chapter 6: several conclusions that were drawn after the completion of this final master’s

thesis will be commented here.

• Chapter 7: some future lines or improvements proposed for further work will be

included.


5

2 State of the art

In this section EPIRB and AIS devices will be described on their own context. Then SDR, USRP

and SCA technologies will be commented and described.

2.1 Automatic Identification System

AIS (Automatic Identification System) is an automatic tracking system that is used on ships,

aircrafts and vessels. The signal transmitted by AIS transponders (Figure 2.1) is received by

satellites (S-AIS, Satellite AIS) and ground stations (like rescue centers) which use this

information for traffic monitoring and rescue on distress situations.

The first document about the technical specifications of AIS was released in 1991 by the ITU.

This standard is currently regulated by the maritime authorities in each country through the

recommendation ITU-R M.1371 [1], whose latest revision was presented in 2014.

Since 2002, all vessels with the following characteristics must integrate the AIS system [2]:

• Any vessel with a gross tonnage over 500 tons.

• Any vessel with a gross tonnage over 300 tons and that perform international crossings.

• Any ship vessel intended for the transport of passengers.

The main reason to use AIS is that it allows ships to check maritime traffic in their area and to be

seen by that traffic, so that collision avoidance is increased. This system can provide several

information about the vehicle where it is installed:

• MMSI (Maritime Mobile Service Identity) which is a unique identification of the vessel.

• Vessel name and details.

• Position, course and speed.

• Source and destination ports.

• Vehicle status.

• Cargo type.

AIS transponders are often integrated with extra sensors that improve the accuracy of the

information to transmit. These sensors can be either a GPS/GLONASS sensor for self-location, a

gyrocompass or rate turn indicators or VHF transceivers for maritime communications.

Figure 2.1 AIS transponder used on vessels.

Global AIS transceiver’s data are collected from internet-connected ground base stations or

satellites, aggregated and made available on the internet through several service providers or web

pages like Marine Traffic. These aggregated data can be checked in real time.


6

The main applications of AIS are the following

• Collision avoidance.

• Fishing fleet monitoring and control.

• Maritime security.

• Search and rescue (SAR).

• Fleet and cargo tracking.

• Accident investigations.

• Ocean current estimates

• Infrastructure protection

2.2 NMEA0183 standard

NMEA (National Marine Electronics Association) is a partnership dedicated to defining standards

for marine electronic products between different manufacturers. These standards establish

protocols that facilitate the operation of users with various shipboard systems.

In 1980 the first standard version (NMEA0180) was defined. This standard allowed all on-board

systems to communicate with each other. This version was modified two times and in 1983 the

NMEA0183 was released, becoming the standard for all marine electronic devices (like GPS

receivers, AIS transceivers, radars, sonars…).

This standard defines a signal code protocol, so any system under NMEA0183 will be able to

interpret any received data.

2.2.1 NMEA sentence format

In [3], information about all NMEA types of message is available, but broadly speaking, each

NMEA sentence is formed by six-bit-long ASCII characters which indicate:

• Type of device that is transmitting the message.

• Message data.

• CRC data.

Its format is as follows:

$𝑥𝑥𝑋𝑋𝑋, 𝑌𝑌𝑌𝑌 … 𝑌𝑌, 𝑌 ∗ 𝑦𝑦 < 0𝐷 >, < 0𝐴 >

! 𝑥𝑥𝑋𝑋𝑋, 𝑌𝑌𝑌𝑌 … 𝑌𝑌, 𝑌 ∗ 𝑦𝑦 < 0𝐷 >, < 0𝐴 >

Each field is defined as:

• $ and ! are the initial delimiters for each NMEA sentence.

• xx is a 2-digit field that indicates the type of device that is transmitting the message.

• XXX is a 3-digit field that indicates the type of data sent.

• YYY..YY is the data payload. Each character is ASCII-encoded using six bits of data.

• yy is a 2-hexadecimal digit field that indicates the checksum to verify the integrity of the

message.

• <0D><0A> are the hexadecimal digits that define the carriage return and line feed. It

marks the end of NMEA sentence.


7

For example, a NMEA sentence transmitted by an AIS transceiver could be something like this:

! 𝐴𝐼𝑉𝐷𝑀, 1,1, , 𝐴, 13𝑠 = 𝑈𝑣𝑃𝑃00𝑂𝐺𝑠𝑊𝐹𝐻: 𝑄4 = 𝑠? 𝑣`28 << ,0 ∗ 59

• ! is the initial delimiter.

• AI indicates that the device type is an AIS transceiver.

• VDM indicates that this is data received from other vessels.

• 1,1, , 𝐴, 13𝑠 = 𝑈𝑣𝑃𝑃00𝑂𝐺𝑠𝑊𝐹𝐻: 𝑄4 = 𝑠? 𝑣`28 << ,0 is the payload to decode.

• 59 is the checksum value.

2.3 Emergency Position-Indicating Radio Beacon

EPIRB (Emergency Position-Indicating Radio Beacon) is a portable device or radio transmitter

(Figure 2.2) used in distress or emergency events to locate vessel and persons. The EPIRB

standard is regulated by COSPAS-SARSAT’s C/S T.001 specification [4], whose latest revision

dates back to 2013.

When the EPIRB beacon is activated, it may send one out of these two different types of radio

signals or both:

• A secondary continuous signal emitted on 121.5 MHz. This signal is not listened by

satellites; tracking is done by airplanes or earth stations which are equipped with a set of

antennas and electronic equipment used as signal direction finders.

• A primary encoded and burst signal over 406 MHz. This signal can be uniquely identified

by orbital satellites (COSPAS-SARSAT).

The first version of this beacon was used by the U.S. military in 1950s. At that time, only the

121.5 MHz continuous signal was transmitted, and the position accuracy was very poor (being

roughly 20 km). The technology was later expanded, and the primary frequency was shifted to

406 MHz.

There are many other types of emergency locator beacons that can be distinguished according to

the environment they were designed for:

• ELT (Emergency Locator Transmitter) are carried by airplanes and are activated on crash

events.

• SEPIRB (Submarine Emergency Position-Indicating Radio Beacons) are like EPIRBs but

carried by submarines.

• SSAS (Ship Security Alert System) are used to indicate possible piracy/terrorism attack

against vessels on the sea.

• PLB (Personal Locator Beacons) are carried by individuals to indicate a possible distress

situation. Typically, they are equipped on backpacks.

EPIRB devices can be automatically activated in different emergencies like sinking ship

scenarios. A water-sensitive sensor can detect if the beacon has been submerged in between 1 and

4 meters of water. It can also be manually triggered by the user.


8

Figure 2.2 EPIRB portable devices.

When the beacon starts transmitting, a 0.5 second burst of 406 MHz data is sent every 50 seconds.

This signal is received by at least one of the satellites operated by the international consortium of

rescue services COSPAS-SARSAT.

COSPAS-SARSAT is a nonprofit intergovernmental initiative that has deployed a satellite

network providing terrestrial coverage to detect and locate different radio beacons like the EPIRB

devices.

At the time when the satellites detect an EPIRB signal, the information is forwarded to the nearest

authorities for event location, so they can quickly act and begin the rescue. This process takes less

than a minute to forward it to any signatory nation.

Several data are sent on EPIRB messages. This data can contain device country code and serial

number, MMSI (if AIS sensor is connected) and location. Moderns EPIRBs (also called GPRIBs)

have built-in GPS/GLONASS sensors that allow to track the position with an accuracy of 100

meters.

With serial number and country code information, Mission Control Centers can hand over crucial

information like phone numbers to call, vessel description, home port and any additional

information that may be useful to SAR services.

2.4 Software-Defined Radio

Software Defined Radio (SDR) is a radio communication technology that allows developers to

implement signal processing elements in embedded systems through blocks defined in software.

Those signal processing elements can be analog components traditionally implemented in

hardware, like detectors, demodulators, mixers, etc.

An SDR system needs some form of radio frequency front-end to transmit and/or receive radio

signals. This allows a greater radio reconfigurability over traditional radio systems that are limited

by hardware design [5].

In SDR systems, signal processing is carried out by general-purpose processor (GPP) via different

software implementations and components. The combinations of various software processing

components are often called ‘waveforms’ or radio applications.


9

The receiver scheme (Figure 2.3) would pass the radio signal captured by the antenna through an

analog-to-digital converter connected to the antenna. The output of the converter would be read

by a digital signal processor that would transform the data stream to any other form required by

the application in the GPP.

For the transmitter, the digital signal processor would generate the data stream that is converted

through a digital-to-analog converter. This signal is passed to the configured RF hardware and

then it is transmitted through the antenna.

Figure 2.3 Block diagram of an SDR system [6].

The flexible RF frontend is implemented via a super-heterodyne receiver, whose block diagram

is depicted in Figure 2.4. A brief explanation of each block is appended below:

• The so-called RF filter bank is a set of band-pass filters tailored for a frequency band.

They are usually sub-octave filters with moderate selectivity. These filters are used to

filter out the harmonic distortion the real RF devices introduce and help the overall

antialiasing process.

• The RF amplifier is used to adapt the input signal level to the ADCs input power range.

This is implemented via a combination of a low-noise amplifier and a switched bank of

attenuators that are used to implement an automatic gain control (AGC).

• The Mixer is used to down convert the signal’s frequency from RF to the appropriate

intermediate frequency (IF) that can even be zero (baseband). This device is crucial in

the overall process because the mixing process introduces some spurious signals in the

analog signal that is going to be sampled. The level of those spurious signals depends on

the quality of the selected device (of course, the more efficient the device is, the more

expensive the receiver will be).

• The variable-frequency oscillator is in charge of generating the mixing sinusoidal signal.

This module must be designed in order to deliver a highly pure signal, because otherwise

the spurious signal components are going to appear in the digital signal and introduce

noise in the digital signal processing.

• The antialiasing filter is used to limit the band of the analogue signal that is going to be

sampled. The design of this filter must be carefully performed if we do not want aliases

to appear in the digital signal the ADC delivers: its frequency selectivity has to be very

high so that the alias’ levels are kept below noise.


10

Figure 2.4 RF flexible frontend block diagram.

Currently, SDR systems are used in military and civil fields. USA army has a program called

JTRS (Joint Tactical Radio System) that offers flexible and interoperable communications in

hand-held, vehicles, ground stations and airborne radios. This goal is achieved using SDR systems

based on an SCA (Software Communications Architecture).

2.5 Universal Software Radio-Peripheral

There is a broad range of hardware solutions for radio amateurs and home use. There are

professional-grade transceiver solutions (Zeus-ZS1, PicAStart…), but nowadays the most popular

are USRP (Universal Software Radio Peripheral) devices designed and sold by Ettus Research

and its parent company, National Instruments.

USRP are hardware devices for software radio systems that offer a flexible and low-cost RF front

end. Most of USRPs are composed by a motherboard and a daughterboard connected to a PC host

through a high-speed link that is used to configure and to control the USRP. The most recent

models are integrating the host computer in the USRP with an embedded processor. This allows

the USRP to be operated in a stand-alone version.

The USRP product family has a similar architecture (Figure 2.5). The motherboard provides the

following basic subsystems that are required for baseband processing:

• Clock generation and synchronization.

• FPGA.

• ADCs and DACs.

• Host processor interface.

• Power regulation.

A daughterboard implements the necessary analog operations for the radio front-end:

• Up/down conversion.

• Filtering.

• Signal conditioning.

Preselector

RF filter

LO

Antialiasing

Filter RF

Amplifier

Mixer

Antenna


11

Figure 2.5 USRP receiver block diagram.

This modularity allows the USRP to run applications that can operate from 1 MHz to 6 GHz.

USRP models can be connected to the host computer via different interfaces. Models N200 and

N210 (Figure 2.6) from Ettus Research use an up to 50 MS/s Gigabit Ethernet interface that

allows complex and baseband sampled data transfer to/from the host. They are recommended for

applications that require a bandwidth higher than 20MHz. These models also provide a MIMO

(Multiple Input Multiple Output) expansion port which can be used to synchronize two devices

of these models.

Figure 2.6 USRP N210 and its internal architecture [7].

The models B200 and B210 (Figure 2.7) use an USB 3.0 interface to transfer samples to/from

the host computer. Applications that do not require a bandwidth higher than about 20 MHz can

use them and benefit from the higher dynamic range provided.

Daughterboard Motherboard

FPGA

ADC Band

Filter

LO

LPF

LO

LPF ↓N Gain

I

Q

To GPP

Quadrature

Mixer Complex

Mixer


12

Figure 2.7 USRP B210 and its internal architecture [8].

These two USRPs (B210 and N210) are the devices to be used for this work.

In 2014, Ettus released the E310 model as part of the embedded series. The devices belonging to

this family do not need to be connected to an external host computer for running applications, so

they are designed for applications requiring stand-alone operation.

Ettus Research provides the device driver for their USRPs. Its name is UHD (USRP Hardware

Driver) [9] and it is supported by all OS platforms. The UHD API supports C++ but it can be

also used by other languages capable of importing the C++ functions. For example, Python uses

SWIG to import these functions.

The UHD API is integrated on several frameworks to develop SDR systems like GNU Radio,

Soapy, LabView, MATLAB and Simulink.

2.6 SCA

The SCA (Software Communication Application) is an open architecture implementation-

independent framework intended to set up the baseline requirements for the development of

software for SDRs [10]. It specifies a standard way for SDRs to design, configure, instantiate,

manage and deploy applications (better known as waveforms in the SCA context) running on a

target platform like computers or embedded systems.

This framework allows to separate waveform software from their hardware supporting

platform(s), simplifying waveform software portability and avoiding redevelopment costs.

Additionally, SCA allows to develop distributed-computing applications on a computer network

so the interoperability of communication systems is greatly improved.

SCA was created by the JTNC (Joint Tactical Networking Center), organization which supports

US Department of Defense on innovative tactical communications. This framework was designed

to reach commercial application requirements as well as those of military applications. It is

important to note that SCA is not a system specification but an implementation independent set

of rules that constrain the design of SDR systems to achieve the former goals or objectives [10].


13

2.6.1 SCA Architecture

To reach its goals, SCA follows an object-oriented approach that defines three main layers:

Operating Environment, CORBA middleware and Waveforms layer. Figure 2.8 shows the layer

structure of Redhawk, one of the available SCA implementation, and the one used in this project.

Figure 2.8 SCA architecture layers and elements [11].

The Operating Environment allows to execute applications, providing them the necessary

elements:

• Operating system.

• Network stack.

• SCA Core Framework (CF) (further discussed in the section 2.7).

• CORBA interface.

• Other extensions added by each SCA implementation.

This layer provides an abstraction from the underlying platform. From waveforms’ perspective,

the OE becomes transparent, no matter how different the actual logical and physical platforms

are.

On other hand, the middleware layer offers services for identification, naming, security and

directories. It allows the communication between the waveforms layer and the OE layer. It

provides different functions to convert and translate any data between the mentioned layers. This

provides transparency mechanisms to waveforms so that they can run on different platforms

independently and keep them communicated.

Lastly, the Waveform layer allows to deploy all SCA waveforms with their respective devices

and components. Each SCA component in a waveform performs some signal processing

algorithm and transmits the result via its ports to other SCA components or devices.

The SCA devices in this layer are abstraction elements of physical hardware devices. The

interfaces that provide the SCA devices allow to control and manage the real and physical

hardware in the system.


14

2.6.1.1 SCA Core Framework

The essential core set of open software interfaces and profiles are defined on the CF (Core

Framework). This set provides the tools to design and manage waveforms and its components for

the SCA system in the host computer or embedded system.

CF interfaces are broken down in four groups [12]: Base application interfaces, Framework

control interfaces, Base device interfaces and Framework service interfaces. Figure 2.9 shows all

CF interfaces grouped up in the former groups.

Figure 2.9 The Core Framework interfaces available in the SCA architecture.

2.6.1.1.1 Base application interfaces

These interfaces should be implemented by the SCA component in an application. Components

are considered Resource elements in the CF that have the following interfaces:

• LifeCycle initializes or releases the Resource in the running application.

• TestableObject is used for testing Resource functionalities.

• PropertySet offers methods to configure Resource properties.

• PortSupplier offers methods to get the reference of Resource ports.


15

Resource components are connected via Ports which are logical elements that can request or

response information to other Resource ports. Ports can be connected or disconnected in the

Resource’s waveform.

ResourceFactory is an optional interface used to create and remove other Resources in the

waveform.

2.6.1.1.2 Framework control interfaces

This is the heart of the CF. These interfaces offer control and management methods to the CF.

They are responsible of deploying, configuring and managing all waveforms and devices in the

system.

DeviceManager interface is used to manage the set of devices and services running in the SCA

system. The instance of a DeviceManager is often called node and this instance is responsible of

launching all the devices specified in its own XML descriptor (see section 2.6.1.2). The node also

obtains the path of the DomainManager and registers itself in the domain.

Application interface offers methods to define “containers” where Resources (components) are

configured and interconnected in order to define the waveform.

ApplicationFactory interface provides general procedures to instantiate waveforms and allocate

devices needed by these waveforms. It also performs the connection between waveforms and

devices.

The DomainManager methods control the overall state of the SCA system. It defines the

FileManager and its relative FileSystem, and provides methods to register DeviceManagers and

Applications

2.6.1.1.3 Base devices interfaces

Device-related interfaces provide interaction methods between the physical hardware devices and

their abstraction elements in the SCA domain. Device is similar to Resource but acting as a proxy

to interact with the real hardware device. It provides control methods to manage and define the

capacity of the related device.

LoadableDevice methods allow to add software loading and unloading functionalities that the

involved device needs. A FPGA that needs to load its firmware to get ready, would be an example

of LoadableDevice.

ExecutableDevice interface offers methods to start and terminate any element in the waveform,

like Resources or other Devices.

AggregateDevice is an optional interface that allows to group up different devices under the same

Device representation.

2.6.1.1.4 Framework service interfaces

It provides non-core application interfaces for file access and file management.


16

File interfaces offers access to files through basic I/O operations (write, read…)

FileSystem defines remote access to other file systems. This is an important interface for

distributed SCA systems.

FileManager is the root file system which mounts or unmounts other FileSystems.

2.6.1.2 Domain Profiles

To initialize and configure the SCA system, the CF framework uses as input a set of configuration

files for each element in the SCA domain. All the file descriptors are XML files the framework

that implements SCA needs to parse to set the state of each involved element. There are seven

different XML descriptors in the Doman Profile [12]:

• Domain Manager Configuration Descriptor (DMD): it defines the services (for

example the logging service) and their location in the file system.

• Device Configuration Descriptor (DCD): it contains configuration data about the

devices to be used in the SCA domain, including the domain manager.

• Software Assembly Descriptor (SAD): it defines the waveform installed in the domain

(components, devices, interconnections…).

• Software Package Descriptor (SPD): it defines the implementation of the related SCA

component. For example, it describes how it was compiled and the language used for the

implementation.

• Software Component Descriptor (SCD): it contains information about the SCA

components installed in the domain. It describes the properties and ports of each

component.

• Device Package Descriptor (DPD): it describes the basic device information, such as

serial number, model, device family…

• Properties Descriptor (PRF): it describes the component/device properties and

structure.

Figure 2.10 Relational Diagram of XML Domain Profiles [13].


17

2.6.2 SCA implementations

There are different software implementations and IDEs to develop SCA systems. The most

popular are NordiaSoft (licensed) and Redhawk (open source), that is based on the first SCA

implementation realized in OSSIE. In this project, Redhawk has been chosen to design and

develop the SCA system.

Figure 2.11 Main software implementations and IDEs to work on SCA systems.

2.6.2.1 OSSIE

OSSIE (Open-Source SCA Implementation Embedded) was the first open-source implementation

of the SCA for Linux systems. It was developed in C++ by the Mobile and Portable Radio

Research Group (MPRG) in 2004.

This SCA implementation offers a framework for prototyping SCA systems. It has not

implemented all the SCA elements, it just implements the minimum required to operate with

components and devices.

The OSSIE team has released the source files to build two different libraries:

• ossieparse: this library contains all the required XML parsers.

• ossiecf: this library contains the SCA implementation of most of the interfaces described

in the section 2.6.1.1.

OSSIE project has now been discontinued in favor of REDHAWK which utilizes many libraries

and tools from OSSIE [14].

2.6.2.2 REDHAWK

REDHAWK is a software framework which implements the 2.2.2 version of SCA [15]. It supports

the design, development, management and upgrade of real-time distributed applications by

providing a runtime environment. The REDHAWK manual [16] states that the runtime

environment allows to:

• Deploy components in different computers on a network.

• Support processing hardware hot swapping.

• Manage colliding software dependencies.

• Manage constrained/specialized hardware resources.

• Reduce the configuration burden on remote computing hardware.

• Coordinate the sharing of limited hardware resources between different applications.

It also states [16] that the strong points of using REDHAWK as SCA framework are:

• Existing libraries can be defined to be used into a common framework.


18

• Decouples specialized hardware from processing algorithms which permits to process

algorithms that can be ported to new platforms in an easy way.

• Supports language agnosticism, allowing appropriate languages (C++, Java, Python) to

be used for various aspects of the system.

• Supports metadata-tagging of data streams.

• Supports precision-time stamping of data.

• Supports dynamic interconnection of modules.

• Data transport mechanism is optimized for processing applications.

REDHAWK provides a powerful and flexible IDE based on the extensible Eclipse Framework

which will be used to develop the different components and applications.

2.7 CORBA

To transfer data between different components, SCA uses Common Object Request Broker

Architecture (CORBA) [17]. CORBA is a standard defined by Object Management Group

(OMG) and it allows different software components written on different programming languages

on different host computers to work together. Thus, it guaranties that data can be transported

between different applications on distributed systems.

CORBA is more than a multiplatform specification; it also defines core elements like interfaces

and security. For these reasons, CORBA is considered as a middleware element inside the SCA

system Figure 2.8.

The main advantages of CORBA are the following:

• Technology independent: Does not depend on the programming language or the

operating system. Allows the interaction between different technologies.

• Distribution transparency: client and server do not need to know if the application is

distributed or centralized.

• Location transparency: client does not need to know where to execute the service.

• Software integration: previous software can be reused.

• Memory management: remote objects do not need to be permanently on memory.

• Typed data, high configuration capacity, data compression.

The three main elements of CORBA are:

• Object Request Broker (ORB): This is a core component from CORBA architecture.

Its mission is to ease communication between different components. It manages

requests and responses to clients invoked on the serialization process.

• Interface Definition Language (IDL): This is the language used to define interfaces

between all components from the same application and it is the element that supports

the technology interoperability. These interfaces should be implemented for each

component in the application.

• CORBA Component Model (CCM): This is a component container where

components are deposited. The container offers a set of services like notification,

authentication, persistence, and transaction.

In summary, CORBA provides SCA the capacity to handle different processes (waveforms) on

different machines (nodes) with different architectures running for the same system (domain). It

allows the communication between each other by exchanging messages regardless the type of

implementation, formats and addresses, without the intervention of the developer.


19

3 Study & design

In this chapter, EPIRB and AIS waveforms will be described and characterized. Based on this

information, detectors and demodulators for both waveforms will be designed in MATLAB using

scripts. Finally, the scripts will be validated applying real data input to verify their correct

functionality.

3.1 EPIRB: study & design

3.1.1 Signal form and characterization

As described in chapter 2, EPIRB devices can transmit two different signals in two different

frequencies, 121.5 MHz and 406 MHz.

The 121.5 MHz signal is an analog AM signal with full carrier and both sidebands (A3X) [18].

An audio signal sweeps downward within a range of not less than 700 Hz between 1600 Hz and

300 Hz. In this project, this signal will be not considered.

The 406 MHz signal is a digital BPSK modulated signal that includes a preamble, a message and

an error correcting code. It works at 400 bps and transmits important data such as:

• Location (if GPS sensor and its connection are enabled).

• Registered user.

• Serial Number.

• National location protocol.

• Additional data programmed into the radio beacon.

There are different channels on the 406 MHz bands assigned to distress signals (Table 3.1). The

frequency used distinguishes the capabilities of the beacon. A recognized beacon can operate on

one of the four (currently) COSPAS-SARSAT satellite-compatible frequencies.

Table 3.1 EPIRB assigned channels and its status.

Channels Frequencies (MHz) Status

A 406.022 Reference

B 406.025 In use today

C 406.028 In use today

D 406.031 Not assigned

E 406.034 Not assigned

F 406.037 In use today

G 406.040 In use today

H 406.043 Not assigned

I 406.046 Not assigned

J 406.049 Operational at future date

K 406.052 Operational at future date

L 406.055 Not assigned

M 406.058 Not assigned

N 406.061 Operational at future date

O 406.064 Operational at future date

P 406.067 Not assigned

Q 406.070 Not assigned

R 406.073 Operational at future date

S 406.076 Operational at future date


20

In this project the design will be focused on the operational channels that are used nowadays. So

only B, C, F and G channels will be considered in the demodulator design.

Figure 3.1 shows the EPIRB signal format.

When the radio beacon is activated, and prior to the transmission of the encoding data (message

and error signals), a CW (Carrier Wave) preamble is generated. Thus, the unmodulated carrier of

the EPIRB channel (B, C, F or G) is transmitted with a duration between 158,4 msec and 161,6

msec.

After that, the message is transmitted for 280 or 360 msec, depending on whether it is a long or a

short message. As seen in Table 3.2 and Table 3.3, the EPIRB signal support two types of

messages with the same frame format but different total number of bits. The short message is a

112-bit signal while the long one is 144-bit. In both cases the transmission bit rate is 400 bps.

The bits of an EPIRB message frame are divided into five groups:

1. The 24 first transmitted bits are system bits used for synchronization purposes.

2. The following 61 bits (positions 25th to 85th) are data bits. This group of bits is referred

as PDF-1 (Protected Data Field 1) and the first bit defines the type of message, ‘0’ for

short or and ‘1’ for long.

3. The following 21 bits (positions 86th to 106th) are a Bose-Chaudhuri-Hocquenhem or

BCH error-correcting code. This group is referred to as the first BCH error correcting

field (BCH-1). This code can detect and correct up to three-bit errors in the 82 bits of

PDF-1 and BCH-1.

4. The following group consists of data bits and its content depends on the message format.

a. Short message: the last 6 bits (positions 107th to 112nd) are not protected data

bits.

b. Long message: the following 26 bits (positions 107th to 132nd) are data bits

protected by the second protected data field (PDF-2).

5. The last 12 bits are only applicable for long messages (positions 133rd to 144th) and they

are part of the second BCH error protecting field (BCH-2) that can detect and correct up

to 2 bit errors in the 38 bits of PDF-2 and BCH-2.

Figure 3.1 EPIRB message format [19].


21

Table 3.2 Data fields for the short message format.

Bit

synchronization

Frame

synchronization

First Protected Data Field (PDF-1) BCH-1 Non-

protected

data field

Unmodulated

Carrier (160

ms)

Bit

synchronization

pattern

Frame

synchronization

pattern

Format

flag

Protocol

Flag

Country

Code

Identification

or

identification

plus position

data

21-bit

BCH

code

Emergency

code /

Supplement

data

Bits position 1-15 16-24 25 26 27-36 37-85 86-106 107-112

Total bits 15 bits 9 bits 1 bit 1 bit 10 bits 49 bits 21 bits 6 bits

Table 3.3 Data fields for the long message format

Bit

synchronization

Frame

synchronization

First Protected Data Field (PDF-1) BCH-

1

Second

Protected

Data Field

(PDF-2)

BCH-

2

Unmod

ulated

Carrier

(160

ms)

Bit

synchronization

pattern

Frame

synchronization

pattern

Format

flag

Protocol

Flag

Country

Code

Identification

or

identification

plus position

data

21-bit

BCH

code

Supplemen

tary data

and

position

12-Bit

BCH

Code

Bits

position

1-15 16-24 25 26 27-36 37-85 86-106

107-132 133-144

Total

bits

15 bits 9 bits 1 bit 1 bit 10 bits 49 bits 21 bits 26 bits 12 bits

The following subsections provide more details on the frame format of an EPIRB signal.

3.1.1.1 Bit synchronization

Consists in an all ‘1’ pattern occupying the 15 first bits.

3.1.1.2 Frame synchronization

After the bit synchronization, a frame synchronization will follow. In this case the pattern

occupies bits 16th to 24th (9 bits). For a normal operation, these bits should be “000101111” but

if the beacon transmits in the self-test mode, the frame synchronization pattern shall be

“011010000” (i.e. the last 8 bits are complemented).

3.1.1.3 Format flag

The format flag (bit 25th) shows whether the message is short (‘0’) or long (‘1’).


22

3.1.1.4 Protocol flag.

The protocol flag (bit 26th) indicates which type of protocol is used to define the structure of

encoded data, according to the following code:

• If ‘0’, standard-short location protocols, standard location protocols or national location

protocol.

• If ‘1’, user protocols or user-location protocols.

3.1.1.5 Country code

Bits between positions 27th and 36th designate a three-digit country code number in binary

notation indicating the place where the beacon was registered. Country codes digits are based on

the MID (Maritime Identification Digit) codes of the ITU (International Telecommunication

Union) agency.

3.1.1.6 Data field

Bits 37th to 85th contain the identification and/or position data of the beacon. Different protocols

can be used for data transmission, so the first 3 or 4 bits of the data field are reserved for specifying

the protocol code and the rest for location or other more specific information.

Coding protocol is identified by a unique protocol code:

• 3-bit code in bits 37th to 39th, for the user protocols and the user-location protocols.

• 4-bit code in bits 37th to 40th, for the standard-short location protocol, the standard

location protocol or the national location protocol.

The user protocol codes are described in section 3.1.1.8 and the location-related codes are

described in 3.1.1.9.

3.1.1.7 Non-protected data field

In the case of short messages, the non-protected data field consists of six bits (107th to 112nd, if

bit 107th is set to one, there will be some data in bits 109th to 112th. If bit 108th is set to 0, the

beacon can only be manually triggered, otherwise it can be triggered both manually or

automatically) which can be encoded with emergency/national codes or data. Emergency codes

can be maritime or non-maritime as listed in Table 3.4 and Table 3.5.

More information about these protocols can be found in the technical draft from ETSI [20].


23

Table 3.4 Maritime Emergency Codes

IMO Indication Binary Code Usage

1 0001 Fire/explosion

2 0010 Flooding

3 0011 Collision

4 0100 Grounding

5 0101 Listing

6 0110 Sinking

7 0111 Distress and adrift

8 0000 Unspecified distress

9 1001 or 1111 Spare

Table 3.5 Non maritime Emergency Codes

Bits Usage

109 No fire (0); fire (1)

110 No medical help (0); medical help required

(1)

111 Not disabled (0); Disable (1)

112 Spare (0)

3.1.1.8 User protocol codes

User protocol codes are used to encode beacon identification data (MMSI, serial number…) but

they do not offer location information.

Table 3.6 shows the user protocol messages available to encode the identification and other data

transmitted by the beacon. More information about each protocol can be found in section 9.4 of

EPIRB technical document [20].

Table 3.6 User protocol codes.

1. Maritime User Protocol

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

0 1 Country Code

0 1 0 MMSI or Radio Call Sign 0 0 R L

2. Radio Call User Protocol

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

0 1 Country

Code

1 1 0 Radio Call Sign 0 0 R L

3. Aviation User Protocol

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

0 1 Country Code

0 0 1 Aircraft Registration Marking

0 0 R L

4. Serial User Protocol

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

0 1 Country Code

0 1 1 T T T C Serial number

and other

data

C/S Cert. No or

National

Use

R L


24

5. Test User Protocol

Bits 25 26 27 36 37 39 40 85

F 1 Country

Code

1 0 0 National Use

6. National User Protocol

Bits 25 26 27 36 37 39 40 85

F 1 Country

Code

1 1 1 Test beacon data

7. Orbitography Protocol

Bits 25 26 27 36 37 39 40 85

F 1 Country

Code

0 0 0 Orbitography data

3.1.1.9 Location protocols

There are five types of location protocols and they can be used for encoding beacon position and

identification data in the digital message transmitted by the 406 MHz beacon.

These protocols are the following:

• User-Location Protocols (Table 3.7): It uses the long message format and the beacon

identification data is provided in PDF-1 field by one of the user protocols defined in

clause 9.4 of EPIRB technical document [20]. Position data is provided in the PDF-2

field as latitude and longitude with a 4-minute resolution.

• Standard Location Protocols (Table 3.8): It uses the long message format. Beacon

identification and position (15-minute resolution) data are both in the PDF-1 field. In

PDF-2 position offsets with a 4-second resolution are stored.

• Standard-Short Location Protocols (Table 3.8): This is the short version of the previous

one. Beacon identification data and position data are stored in the PDF-1 field. The

supplementary data is not protected by a BCH code.

• National Location Protocol (Table 3.9): It uses the long message format. The

identification data is provided in a national defined format in 18 bits of PDF1. Position

data with 2-minute resolution is given in PDF-1. PDF-2 is used to store position offsets

with a 4-second resolution.

• National-Short Location Protocol (Table 3.9): Like the previous one, but in this case

position offsets are not stored.

Table 3.7 User-Location protocols code [20].

U s e r - L o c a t i o n P r o t o c o l s

Bit

26 bits

27-39 bits 40-83 bits

84-85 bits 86-106 bit 107 bits 108-132 bits

133-144

1 .......

Identification Data (44 bits) Radiolocating Device

21-Bit BCH code

Posit. Data

Source Position Data to 4 min

Resolution (25 bits) 12-Bit

BCH code


25

Table 3.8 Standard and Standard-Short Location protocols codes [20]

S t a n d a r d L o c a t i o n P r o t o c o l s

bit 26

bits 27-40

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

0 .......

Identification Data

(24 bits) Position Data to 15 min


BCH code Supplementary

Data Position Data to 4 sec


BCH code

S t a n d a r d - S h o r t L o c a t i o n P r o t o c o l s

Table 3.9 National and National-Short Location protocols codes [20].

N a t i o n a l L o c a t i o n P r o t o c o l

bit 26

bits 27-40

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

bits 133-144

0 .......

Identification Data

(18 bits) Position Data to 2 min


BCH code Supplementary

Data Position Data to 4

sec Resolution (14

bits)

National

Use 12-Bit

BCH

code

N a t i o n a l - S h o r t L o c a t i o n P r o t o c o l

Position data information is encoded as degrees, minutes and seconds of latitude or longitude.

This data is rounded off (not truncated) to the available resolution. The long message protocols

offer a higher resolution information given in PDF-2 as an offset relative to position provided in

PDF-1.

Supplementary data can be provided in location protocol:

• Source of Position Data: It states whether the encoded position data is provided by an

external or internal navigation device.

• Auxiliary Radio Locating Device Code: It states whether the 121.5 MHz homing signal

is transmitted or not.


26

3.1.2 EPIRB design: detector and demodulator

This chapter describes the design process on MATLAB of the EPIRB detector and demodulator

modules. As mentioned in the previous chapter, the goal of this project is to detect and demodulate

the 406 MHz digitally encoded signal transmitted by the beacon.

3.1.2.1 EPIRB detector

The detection process of the EPIRB signal has different stages (Figure 3.2). Firstly, a WOLA FFT

(Weighted Overlap Add FFT) process is used to channelize the input signal with the appropriate

frequency resolution. In order to improve the spectral resolution of the input signal an appropriate

window is used (recall that the frequency resolution refers to the discretization step in the

frequency axis and spectral resolution has to do with the capability of the system to separate weak

signals when they are mixed with strong ones).

The resolution must be chosen in such a way that it allows the correct separation of the ERPIB

channels, enabling the detector to distinguish simultaneous transmissions on different channels.

Once the target channels are isolated (channels B, C, F and G as stated in Table 3.1), the power

and the noise power of each channels is estimated. The noise power computation is based on the

measured power of the nearby frequencies in which we a priori know there are no transmissions.

Finally, the activity in the target channels is detected via a single comparison with the noise

power.

Next subsections contain more detailed information about the implementation of the EPIRB

detector.

Figure 3.2 EPIRB detector processing stages.

Preprocessing

Input EPIRB

Signal

Window

WOLA+FFT

Estimation & detection

EPIRB

channels

power

estimation

Noise power

estimation

Detection and

conditioning


27

3.1.2.1.1 WOLA FFT channelization technique

Using an FFT is a simple solution to the channelization problem. It is usually reserved to cases of

signals with a large number of channels evenly spaced in frequency, with all channels having

equal filtering and where the filter performance is not so critical.

One way to improve the performance of the filter is using a WOLA FFT structure, whose block

diagram is depicted in Figure 3.3 [21]. It consists of a channelization process that is performed

instead of computing a (𝑊 · 𝑁) point FFT, where 𝑁 is the length of the output sequence and 𝑊

is the so-called WOLA factor, or the ratio between the lengths of the input and output sequences

(for example a Kaiser window). This is a simple procedure that takes the 𝑊𝑁 signal samples,

partitions them into W pieces of N samples and adds all these pieces up to obtain a single piece

of 𝑁 samples.

Mathematically, this process can be expressed like this: if 𝑥 is a vector of 𝑊𝑁 samples, applying

the WOLA process of factor 𝑊 on 𝑥 gives place to an 𝑁 sample vector 𝑦 in which every sample

is computed as (1):

𝑦[𝑛] = ∑ 𝑥[𝑛 + 𝑤𝑁], 𝑛 = 0,1, … , 𝑁 − 1

𝑊−1

𝑤=0

, (1)

This method allows us to increase the spectral resolution of the input signal’s FFT as well as

reduce computational cost. At the same time, the signal to noise ratio of the input sequence will

improve because the number of samples used in the process gets larger.

Figure 3.3 Block diagram of the sequence of calculations needed to implement the FFT-channelization process.

3.1.2.1.2 Power and noise power estimation of EPIRB channels

For each windowed frame of data processed by the WOLA FFT, both power and the noise power

of EPIRB channels are calculated using the bin information from the FFT.

The detector calculates the power noise by averaging the powers of the frequency bins outside

the EPIRB channels and the standard deviation of their values. This process is represented by

equations (2), (3), (4) and (5). The involved parameters are the following:

• 𝑛 indicates the EPIRB channel index (B, C, E and F).

• 𝑏𝑛 ∈ {0,1, … , 𝑁 − 1} is the index of the FFT bin for the EPIRB channel 𝑛.

• 𝒃𝑛𝑜𝑖𝑠𝑒 is the set of 𝑀 (𝑀 ≤ 𝑁) FFT bins assigned to the calculation of the noise floor.

𝑃𝑠𝑖𝑔𝑛𝑎𝑙(𝑛) = |𝑋(𝑏𝑛)|2, 𝑛 = 0,1,2,3 (2)

𝒃𝑛𝑜𝑖𝑠𝑒 = {𝑘1, 𝑘2, … , 𝑘𝑀| 𝑘𝑚 ∈ {0,1, … , 𝑁 − 1}, 𝑘𝑚 ≠ 𝑘𝑛 𝑖𝑓 𝑚 ≠ 𝑛 , 1 ≤ 𝑚, 𝑛 ≤ 𝑀 } (3)

𝜇𝑛𝑜𝑖𝑠𝑒 = 1

𝑀∑ |𝑋(𝑘𝑖)|2𝑀

𝑖=1 𝜎𝑛𝑜𝑖𝑠𝑒2 =

1

𝑀∑ (|𝑋(𝑘𝑖)|2 − 𝜇𝑛𝑜𝑖𝑠𝑒)2𝑀

𝑖=1 (4)

𝑃𝑛𝑜𝑖𝑠𝑒 = 𝜇𝑛𝑜𝑖𝑠𝑒 + 2.6 · 𝜎𝑛𝑜𝑖𝑠𝑒 (5)

𝑊 ∙ 𝑁

samples Windowing WOLA FFT N samples


28

3.1.2.1.3 Signal detection and conditioning

In order to detect the signal, it is necessary to know its transmission time. The EPIRB technical

draft from ETSI [20] states that the signal duration is 520 msec and that the first 160 msec

correspond to the preamble, where just the carrier is transmitted.

Knowing the transmission time and power values, the four EPIRB channels of interest are

detected and properly conditioned for the demodulation process.

A channel is considered of interest if the channel power is higher than the noise power for at least

400 msec. When that is the case, a 400-msec portion of the signal is isolated.

The isolated signal is moved to baseband (centered around 0) through a process of mixing with

the variable local oscillator tuned to the baseband frequency of the channel carrier.

Then, the baseband signal is filtered and down sampled from 384 kHz to 8 kHz. The reason to

down sample to 8 kHz is that the EPIRB technical document [20] states that the bit rate of the

signal is 400 bps and 20 samples per symbol are going to be used. This means that the signal

requires a sample rate of 20 ∗ 400 = 8 𝑘𝐻𝑧.

Figure 3.4 shows the filtering process. It consists in a combination of CIC and compensation

filters. The process is as follow:

• First, the detected signal is passed through a CIC filter to decimate it by 24, thus reducing

its sample rate by the same value. The magnitude and phase response of the filter is

depicted in Figure 3.5. It can be seen that the CIC filter introduces an attenuation that

increases as the frequency increases.

• Next, a FIR filter with a high attenuation in the stop band, a low ripple in the pass band

and a high slope in the transition band is used to filter the signal and also decimate it by

an additional factor of 2, reducing the sample rate to the target value of 8 kHz. Figure 3.6

and Figure 3.7 show the design parameters used to generate the filter coefficients and the

filter response, respectively.

• Finally, a compensation filter is used to compensate for the ever-increasing attenuation

the CIC filter introduces in the signal’s pass band. Its frequency response is included in

Figure 3.8.

Figure 3.4 Filters for the detected signal.

8 𝑘𝐻𝑧 16 𝑘𝐻𝑧

𝑦(𝑛)

CIC Decimator

(↓ 24)

FIR Filter

(↓ 2)

Compensation

FIR filter

(↓ 2)

𝑥(𝑛)



29

Figure 3.5 CIC frequency response.

Figure 3.6 Selective FIR filter design.


30

Figure 3.7 Frequency response for selective FIR filter.

Figure 3.8 Frequency response for compensation FIR filter.

The output signal of the filter chain is the one which will be demodulated in the next stage. All

the processes this signal has been through in the detection stage render approximately the first 80

msec of the signal preamble useless, so that the effective signal length is about 440 msec.

3.1.2.2 EPIRB demodulator

As stated above, the 406 MHz EPIRB signal is a BPSK modulated digital signal, which must be

demodulated to extract the message. The EPIRB demodulator considers both the filtered signal

from the detector and the noise floor, used to not demodulate those initial or final samples where

the power is not higher than the noise floor.


31

The BPSK modulation uses two phase offsets to represent the high and low logic levels. Usually,

as in the case of the EPIRB signal, the difference between phases of both levels is 180º. This

means that in one logical state the phase of the carrier is inverted, while in the other it is not. The

BPSK modulation is depicted in Figure 3.9.

Figure 3.9 Data encoding and modulation sense.

Bearing this in mind, the demodulator must detect changes in the phase of the input signal, decide

if such changes correspond to a valid logic state and assign the correct state to the output bit.

Nevertheless, since demodulation is phase dependent, before starting demodulation, a phase

correction of the input signal is required. It is because when working with real radio signals and

RF devices, local RX and TX oscillators, which are not synchronized with each other, and the

effect of the communication channel itself, tend to introduce an unknown phase error in the signal

that must be corrected to ensure the demodulator works properly.

According above, Figure 3.10 shows the general structures of the demodulator. To carry out the

phase correction, the phase error is estimated as the phase deviation of the carrier in the preamble

transmission. This deviation is computed using 70 msec out of the 80 msec available in the

process: the phase of the carrier is computed in this interval and approximated by a straight line;

the slope of this line is the value we are looking for. The signal is corrected subtracting the phase

error to each phase angle calculated. Figure 3.11 and Figure 3.12 show this correction.

Once the phase of the input signal has been corrected, the BPSK demodulation is performed using

a finite state machine (FSM) that detects the changes in the phase of the signal, verifies that the

signal remains in the correct state for the required time and assigns the corresponding bit to the

output buffer where bits are stored.

Figure 3.10 General structure of the EPIRB demodulator.

Phase correction

Phase error

detection

Signal phase

correction

BPSK demodulation

Phase

changes

detection

Bit value

assignment


32

Figure 3.11 Preamble phase angle of EPIRB's burst signal before being corrected.

Figure 3.12 Preamble phase angle of EPIRB's burst signal after being corrected.

Figure 3.13 shows the state diagram of the FSM. To detect a high or low logic level (bit ‘0’ or

‘1’) the FSM evaluates the 20 samples of each symbol of the ERPIB detected channel. As

mentioned above, we are using a sampling frequency of 8 kHz, twenty times higher than the

transmission frequency of 400 bps. It means that there are 20 samples per bit or symbol.

To understand how the FSM works, it is necessary to introduce the variables it uses:

• 𝑡: Sample’s discrete time. It is increased with each sample.

• 𝑇𝑏: bit period corresponding to 20 samples (1 symbol).

• 𝑇𝑒: elapsed time in 𝑡 for the current state.

• 𝑇𝑠 : sample period (1

𝑓𝑠).

• ∆𝜙: phase offset.


33

The first rising edge of the input signal marks the start of the demodulation sequence. This is the

instant when the state variable is initiated to “11”. In each state, the elapsed time 𝑇𝑒 is checked in

order to verify if the state stayed long enough. This is necessary to prevent wrong hops in phase

offset.

State changes occur when one of the following conditions are met:

• Condition A: ∆𝜙 > 0.7 𝑎𝑛𝑑 |(𝑡%𝑇𝑏) −𝑇𝑏

2| < 3𝑇𝑠

• Condition B: ∆𝜙 < −0.7 𝑎𝑛𝑑 |((𝑡 +𝑇𝑏

2)%𝑇𝑏) −

𝑇𝑏

2| < 3𝑇𝑠

• Condition C: ∆𝜙 < −0.7 𝑎𝑛𝑑 |(𝑡%𝑇𝑏) −𝑇𝑏

2| < 3𝑇𝑠

• Condition D: ∆𝜙 > 0.7 𝑎𝑛𝑑 |((𝑡 +𝑇𝑏

2)%𝑇𝑏) −

𝑇𝑏

2| < 3𝑇𝑠

Figure 3.13 EPIRB demodulator's state machine.

An explanation regarding this state machine diagram is in order.

When the machine is in state “11” (initial state) waiting for a new phase transition:

• When the sample’s time 𝑡 has reached a new half bit period and a phase increment smaller

than -0.7 radians has been found, the state machine transitions to state “00”. If, in this

situation, the elapsed time for the current state, 𝑇𝑒, has reached a half-bit period or a full-

bit period, a new “1” is generated and appended to the output bit sequence array (if the

phase transitions when 𝑇𝑒 reaches a half-bit period, the new “1” comes after a “0”, and if

the phase transitions when 𝑇𝑒 reaches a full-bit period, the new “1” comes after another

“1”).


than -0.7 radians has been found, the state machine transitions to state “01”. In this

situation, no bit is generated.


34

When the machine is in state “01” waiting for a new phase transition:

• When the sample’s time 𝑡 has reached a new half bit period and a phase increment greater

than 0.7 radians has been found, the state machine transitions to state “11”. If, in this





“0”).


than 0.7 radians has been found, the state machine transitions to state “10”. In this




than 0.7 radians has been found, the state machine transitions to state “11”. If, in this





“0”).


than 0.7 radians has been found, the state machine transitions to state “10”. In this




than -0.7 radians has been found, the state machine transitions to state “00”. If, in this





“1”).


than -0.7 radians has been found, the state machine transitions to state “01”. In this


Once the whole frame is demodulated (112 or 144 bits depending on the message format), the bit

sequence obtained is compared with the EPIRB preamble. If it matches, the message contained

in the bit buffer can be checked against an EPIRB decoder tool.

3.1.3 Validation and results

To check the correct functioning of the MATLAB modules, we use a real test signal. It consists

of a file storing complex samples of an EPIRB signal transmitted by a real EPIRB beacon. Before

commenting on the verification results, we will explain some characteristics of the test signal.


35

3.1.3.1 EPIRB test signal

The beacon used to generate the test signal is a TRON60S/GPS from JOTRON (Figure 3.14). It

uses the EPIRB channel F (406.037 MHz) to transmit the digital encoded message. This beacon

can only be activated for test purposes the first 5 minutes of each hour as COSPAS-SARSAT

states in their protocols.

Figure 3.14 (a) EPIRB beacon device. (b) Instructions to trigger distress or test signal from

EPIRB beacon device.

The signal is captured through the USRP B210 using the rx_samples_to_file binary provided by

the UHD. This application streams data from a single RX channel of the USRP device to a file.

In order to capture the EPIRB signal, the center frequency of the USRP was set to 406.001 MHz

and the sample rate was set to 384 ksps. Once the USRP is configured, the EPIRB beacon was

triggered in order to transmit the test signal. The stored signal samples are single-precision

floating-point complex numbers.


36

3.1.3.2 Validation results

The script of the EPIRB detector includes some functions to visualize the spectrum of the test

signal over the time. It is really useful for testing purposes as both, carrier and modulated signal,

can be detected.

In Figure 3.15 we can see the initial FFT of EPIRB test signal. At this time, the EPIRB beacon

was not triggered yet because there is not any active carrier in the EPIRB channels. The peak

shown at 406.001 MHz is due to the power of the local oscillator in the USRP. It is important to

note that the tuning frequency configured in the USRP (406.001 MHz) is not set to the same value

as the EPIRB channels to avoid fake detections in those frequencies.

Figure 3.16 shows the instant in which the EPIRB carrier wave on channel F (406.037 MHz)

transmits the preamble of the signal. Figure 3.17 shows the moment when the carrier begins to

modulate the EPIRB message.

The signal is detected and sent to the EPIRB demodulation script where, by means of the state

machine defined in Figure 3.13, the bit sequence of the digital message is acquired and stored in

a buffer. The output sequence has a length of 144 bits; the 24 first ones correspond to bit & frame

synchronization preambles. The other 120 bits are the actual message:

100100000010011000110111100101011110111101111111110111111111110101010100100011100111011110000011111000001111011001101100

Or its hexadecimal representation:

90263795𝐸𝐹7𝐹𝐷𝐹𝐹𝐷548𝐸7783𝐸0𝐹66𝐶

Figure 3.15 FFT from EPIRB signal data. No transmission.


37

Figure 3.16 FFT from EPIRB signal. The 406.037 MHz channel (channel F) begins to transmit the carrier wave preamble.

Figure 3.17 FFT from EPIRB signal. Modulated carrier.


38

Figure 3.18 FFT from EPIRB signal. End of transmission.

This message will be checked against an EPIRB decoder tool like the official one from COSPAS-

SARSAT webpage: https://www.cospas-sarsat.int/en/beacon-decode-program (Figure 3.19). In

addition, it can be checked that the decoded information of Figure 3.20 matches with the

information displayed by the physical EPIRB beacon of Figure 3.21.

Figure 3.19 Introducing the demodulated message in EPIRB official decoding tool.

https://www.cospas-sarsat.int/en/beacon-decode-program


39

Figure 3.20 shows the decoded message from the EPIRB processed signal. There is some

important information that can be checked against the data the physical EPIRB beacon device

contains. Among them, the serial number from EPIRB beacon and the C/S TAC (COSPAS-

SARSAT Type Approval Certificate), which is a number that COSPAS-SARSAT assigns to

beacon manufacturers to approve them as valid devices.

In this case the message protocol is a location protocol, specifically a ‘Standard Location –

EPIRB’. The location values of latitude, longitude and offsets are “default”. This means that the

transmitted signal was a test signal without GPS, and so does not send the position of the beacon

at that time.

Finally, Figure 3.21 shows some information about the real EPIRB beacon device. It can be

checked that both C/S TAC (222) and serial number (05615) values are the same as those decoded

from the message. So, it can be assumed that both, the detector and the demodulator MATLAB

modules, are working properly.

Figure 3.20 Decoded EPIRB message.


40

Figure 3.21 EPIRB beacon device data.


41

3.2 AIS: study & design

This chapter will describe the design process on MATLAB for AIS detector and demodulator

components.

3.2.1 Signal form and characterization

AIS system technical specifications are defined in ITU-R M.1371-5 [1] recommendation, where

physical layer, link layer, network layer and transport layer of the open system interconnection

(OSI) model are covered (Figure 3.22).

Application layer

Presentation layer

Session layer

Transport layer

Network layer

Channel A Channel B

Link management entity

(LME) layer

Link layer LME

Data link service (DLS)

layer Link layer DLS

Medium access control

(MAC) layer Link layer MAC

Physical layer Physical layer

Rx A Tx A/B Rx B

Figure 3.22 OSI model for AIS system [1].

This chapter will focus mainly on the physical layer since it is the layer that defines both the radio

parameters, modulation schemes and coding, necessary to undertake the design of the AIS

detector and demodulator.

The AIS transceivers work in the marine VHF band on two channels: AIS-1 (161.975 MHz) and

AIS-2 (162.025 MHz) both channels have a channelization of 25 kHz. Each burst of data is

transmitted during 26.67 msec, as it shown the Figure 3.23.


42

Figure 3.23 AIS burst data transmitting time [1].

The AIS signal coding uses NRZI (Non-Return to Zero Inverted) and the encoded bits are

modulated by a frequency modulated Gaussian filtered minimum keying (FM-GMSK) scheme.

The specified transmission bit rate is 9600 bps.

3.2.1.1 GMSK modulation

To explain how GSMK modulation works, it is necessary to explain MSK. MSK is a form of

continuous-phase frequency shift keying binary modulation where the modulated carrier has no

discontinuities on its phase and frequency changes occur when the carrier gets zero crossings [22].


43

MSK is often used for wireless communication because of its desirable characteristics like high

immunity to noise and interferences as well as its ease of implementation. However, in MSK the

spectrum is not compact enough for narrowband applications. To solve this, the power spectrum

of MSK can be made more compact by using a pre-modulation low-pass filter at the cost of

intersymbol interference.

GMSK is MSK modulation with a Gaussian pre-modulation filter. The main advantage of the

Gaussian filter is that it does not change abruptly at the cutoff frequency. This results in GMSK

providing smooth phase transition between signal states, reducing the bandwidth requirements.

However, the smooth phase transition of the GMSK transmitted signals makes the demodulation

at the receiver more complex because the Gaussian pulse is made longer than one-bit interval,

thus increasing ISI. For the receiver to achieve a specified bit error rate, more power must be

generated at the transmitter in order to dodge the presence of ISI.

Figure 3.24 Block diagram of a FM-GMSK

Finally, FM is the form of angle modulation in which the instantaneous frequency of the carrier

is varied linearly with the message signal. Figure 3.24 shows a block diagram of an FM-GMSK

modulator.

3.2.1.2 Medium access control scheme

As the technical document [1] states, AIS uses a type of TDMA depending on the equipment AIS

class and its application environment (Table 3.10).

Table 3.10 TDMA types that are used depending the AIS class of the system or its specific application.

AIS class or specific application TDMA Type

SAR Not defined in [1]

SART SOTDMA

AtoN FATDMA or RATDMA

Class A AIS SOTDMA, RATDMA or ITDMA

Class B AIS CSTDMA

AIS ground station FATDMA or RATDMA

Every scheme is synchronized over UTC through the GNSS network. Each system is self-

managed so as not to collide with another system that is transmitting in the assigned slot of 26.67

msec.

Gaussian Low

Pass Filter

Frequency

Modulator


44

AIS systems can work in three different operation modes [1]:

• Continuous: in this mode the AIS system is transmitting and receiving AIS messages.

• Assigned: the authorities from each country define this mode in the maritime area.

• Interrogation: the AIS ground station requests to another system some parameter or status.

3.2.1.3 AIS packet format

The packet format for AIS messages is composed by seven fields with a total length of 256 bits.

It is portrayed in Figure 3.25.

Figure 3.25 AIS message packet format.

The first field is start buffer (or ramp-up buffer) of 8 bits. It is followed by a preamble or training

sequence of 24 bits which is used to synchronize the AIS received. This should be a bit pattern

consisting of alternating ‘0’s and ‘1’s (010101…) which is modified due to the NRZI mode

(Figure 3.26).

Figure 3.26 Unmodified bit pattern vs modified bit pattern by NRZI.

The next field is the start flag. It is 8 bits long (‘01111110’ or 0x7E) and it is used to detect the

start of a transmission packet.

Data field is the next one. It consists in a portion of 168 bits long in the default transmission

packet. This field will be discussed in the next section (3.2.1.3.1).

Following, it is the CRC (Cyclic Redundancy Check) of a 16-bit polynomial to calculate the

checksum. The bits should be pre-set to one (1) at the beginning of a CRC calculation and only

the data portion should be included in the CRC calculation.

24 bits 8 bits 168 bits 16 bits 24 bits 8 bits

Preamble Flag Data CRC Final header

End

Buffer

8 bits

Start

Buffer


45

The last two fields are the end flag field and temporal buffer field. The first one is identical to the

start flag field; the other is a 24-bit long buffer that contains information like bit stuffing (4 bits),

distance delay (14 bits) and synchronization jitter (6 bits).

Bit stuffing is the insertion of one or more bits into a transmission unit to provide signaling

information to a receiver.

Distance delay and synchronization jitter are values that can be used at the receiver end to

preserve integrity of the data link channel.

3.2.1.3.1 Data field

The data field is mainly composed by four groups of data: the message type, MMSI, message data

and the communication state.

Message type is defined by the first 6 bits. There are up to 27 different types of message that are

listed in Table 3.11.

Table 3.11 AIS message types [1] [23].

Message Type Description

1, 2, 3 Position Report Class A

4 Base Station Report

5 Stating and Voyage Related Data

6, 7, 8 Binary Addressed Message

9 Standard SAR Aircraft Position Report

10, 11 UTC Date

12, 13, 14 Addressed Safety Related Message

15 Interrogation

16 Assignment Mode Command

17 DGNSS Binary Broadcast Message

18, 19 Class B Position Report

20 Data Link Management

21 Aid-to-Navigation Report

22, 23 Channel Management

24 Static Data Report

25, 26 Binary Messages

27 Position Report For Long-Range Applications

The MMSI, represented by the next 30 bits via 9 decimal digits, is the unique identifier of the AIS

system. It is assigned by the regulatory authority of the country where it is operating.

The communication state defines the slot status during the medium access. It indicates the synchronous state of the system over GPS and contains information used by the slot allocation algorithm in the SOTDMA concept.

Table 3.12 shows the parameters that communication state offers.

The message data strongly depends on the message type. The nature of these data can be classified

as follows [1]:

• Static data: the data that will not change in any moment, as the MMSI or vessel’s

dimensions.


46

• Dynamic data: the data that is constantly updated, as position, speed or course.

• Voyage data: this information is manually entered by the user. It states information about

the marine voyage, as the destination seaport.

• Other data: the data that can be sent to inform about a distress call or any other purpose.

Table 3.12 Communication state parameters [1].

Finally, it should be emphasized that each AIS message is sent over a period. This period depends

on the AIS class of the system and the speed. If the vessel is docked in the port, then the period

will be of 6 minutes but if the vessel is navigating, this period may vary between 2 seconds and 3

minutes.

3.2.2 AIS design: detector and demodulator

This chapter will describe the design process on MATLAB for AIS detector and demodulator

components. As mentioned in the previous chapter, the goal is to detect and to demodulate signals

from both channels (AIS-1 and AIS-2) that are transmitted by ships and vessels.

3.2.2.1 AIS detector

AIS detector design will be very similar to the EPIRB detector design that was discussed in 3.1.2.

It is intended to work with signals with a sample rate value of 96 kHz and a center frequency of

162 MHz.

Figure 3.27 shows the detector stages. The input signal will be passed through a series of signal

processing stages to channelize both AIS channels, AIS-1 (161.975 MHz) and AIS-2 (162.025

MHz) with the appropriate frequency resolution. This resolution must be assigned a proper value

to distinguish transmissions from both channels.

The main difference regarding the EPIRB detector is the fact that the extraction of the AIS pulse

is split in two parts. In the first one a rough estimation of the pulse length is obtained. To do this,

the signal and noise powers are estimated every 0.66 msec via an FFT process. The calculation is

carried out in the same way as it was explained in EPIRB (section 3.1.2.1.2).


47

The detection process can then be carried out by comparing the signal and noise powers and the

length of every detected pulse can be computed. Those pulses whose length is lower than the

minimum admissible length (22 msec) are discarded.

Figure 3.27 AIS detector processing stages.

The rest of the pulses are going to be down-converted to baseband and their sample rate reduced

to 48KHz. This value comes from the fact that the AIS standard states a bit rate of 9600 bits per

second. For every bit, 5 samples are going to be used in the demodulation process, and so, the

final value of the sample rate is 48KHz (see Figure 3.28) . The down-conversion process needs a

suitable local oscillator and a low-pass filter with a cut-off frequency of 16KHz. In Figure 3.29,

the frequency response for this filter is depicted.

Figure 3.28 Filter for the detected signal.

Figure 3.29 Low pass filter frequency response.

Preprocessing

Input AIS

Signal

Window

WOLA+

FFT

Rough estimation & detection

AIS channels

power

estimation

Noise power

estimation

Rough

detection

Refined estimation & detection

Burst instant

power

estimation

Noise power

estimation

Refined

detection


𝑦(𝑛)

FIR Filter

(↓ 2)

𝑥(𝑛)


48

Once the pulse has been down converted, a second detection step is carried out to extract the

samples that are going to feed the demodulation process. These samples meet the requirement

that their instant power be at most 3 dB lower than the average power of the pulse, that is:

instantaneous power of the samples average power of the pulse – 3 dB

3.2.2.2 AIS demodulator

Before starting the demodulation, a phase correction process similar to that explained in section

3.1.2.2 for the EPIRB demodulator has to be carried out on the input signal. The purpose is to

compensate for the unknown phase that is added due to the lack of synchronization between the

RX and TX local oscillators and the effect of the channel itself.

This phase error is estimated as the phase deviation of the carrier in the preamble transmission

(24 bits) and flag bits (8 bits). Both fields correspond to the first 160 samples, because, as

explained in section 3.2.1.3, AIS needs 5 samples to demodulate 1 symbol. The phase is computed

in this interval by fitting a polynomial of degree 1 among the local maxima you can see in Figure

3.30 and another polynomial of degree 1 among the local minima in the same figure. The average

of the two polynomials is used to correct the phase deviation of the input signal. In Figure 3.31

we can see the outcome of the phase correction process.

Figure 3.30 Sample angle values from AIS burst preamble without correction.


49

Figure 3.31 Sample angle values from AIS burst preamble with correction.

The next process is to find the preamble location via a correlation process of the phase of the input

signal and that of an ideal training sequence (Figure 3.32).

Figure 3.32 Correlation against an ideal training sequence in order to detect burst's preamble.

The best sample phase for making bit decisions is then computed: if there are more than one peak

in the correlation sequence, whose levels are pretty much the same as the highest one, the latest

one will be taken. This is done so because there are some ramp up bits that can mislead us when

it comes to finding the position of the preamble. It is assumed that the last highest peak is

associated with the real preamble.

Then, all the bits are calculated by finding phase transitions between consecutive samples. When

the phase offset is greater than 𝜋

4, then a ‘1’ is assigned to that bit, and ‘0’ otherwise.


50

When all the demodulated bits are available, the start flag field (0x7E) is searched to extract the

message type (it is composed by the next 6 bits). After that, the message bits will suffer a process

of unstuffing, following the AIS specification [1]. In this step, if a message has 5 consecutive 1’s,

a zero should be inserted. This process will unstuff everything, even the end flag in the AIS

message.

Finally, the data bits are obtained according to the message type. The calculated checksum from

these bits are compared against the CRC field. If both values are the same, it is considered that

the demodulation is correct. If checksum passes the bytes are flipped and the data will be decoded

as it was discussed in the section 3.2.1.3.1. The decoding process will be different for each

message type.

3.2.3 Validation and results

To check the correct functioning of the MATLAB modules, real AIS signals are going to be used.

Before commenting on the verification results, we will explain some characteristics of the test

signal.

3.2.3.1 AIS test signal

For validation purposes, the designed components are going to use a file which stores complex

samples from AIS signals captured near of Bouza’s seaport in Vigo. These signals were

transmitted by ships and vessels near the seaport.

The signals were captured through the USRP B210 using the rx_samples_to_file binary provided

by the UHD. This application streams data from a single RX channel of the USRP device to a

file. In order to capture these AIS signal, the center frequency of the USRP was set to 162 MHz,

sample rate was set to 200 ksps and RX gain set to its maximum value (76 dB). The stored signal

samples have a single precision floating complex format.

The signal captured contains multiple AIS bursts. For the validations, the samples from a single

burst were isolated and stored in other data file. This is the file that will be used to test the

following components.

3.2.3.2 Validation results

For the validation of the AIS detector and demodulator, the real captured signal indicated in

3.2.3.1 is used. The script for the detection part allows to visualize the signal’s spectrum versus

time. It is useful to detect the period of time when both AIS channels are transmitting.

Figure 3.33 shows the initial power spectrum for the AIS signal. Both AIS channels are not

transmitting any signal at that time. The peak shown at 162 MHz is due to the power of the local

oscillator in the USRP. As commented in section 3.1.3.2, it is important that the tuning frequency

configured in the USRP is not set to the same value as any of the AIS channels to avoid fake

detections in those frequencies.


51

In Figure 3.34, the instant in which an AIS signal is being transmitted in AIS-2 channel (162.025

MHz) is portrayed. This is the signal the AIS detector will filter and isolate. Finally, it will be sent

to the demodulator.

Figure 3.33 FFT from AIS signal data. Both AIS channels are not transmitting any signal.

Figure 3.34 FFT from AIS signal data. Channel AIS-2 begins to transmit.

Figure 3.35 shows the output results of running the MATLAB script that detects, demodulates,

and decodes the AIS burst signal. Table 3.13 shows all decoded parameters.

The MMSI can be checked at online vessel tracker webpages like Marine Traffic to get public

information about the vessel. Figure 3.36 shows the vessel information for the decoded MMSI

263528000. So, it can be assumed that both, the detector and the demodulator MATLAB modules,

are working properly.

https://www.marinetraffic.com/


52

Figure 3.35 Output results of MATLAB script that tests AIS detector, demodulator and decoder.

Table 3.13 Decoded parameters of the testing AIS burst signal.

Decoded data field Value Units

Message type 1 Constant

Repeat indicator 0 Message repeat count

MMSI 263528000 9 decimal digits

Navigation status 0 (under way using engine) Constant

Rate of turn 0 (not turning) Constant

Speed over ground (SOG) 0 Knots. Range 0-1023 with 0.1-knot resolution

Position accuracy 1 (DGPS-quality fix; accuracy

< 10 m)

Boolean

Longitude -8.7853 Degrees

Latitude 42.2572 Degrees

Course over ground (COG) 190.1 Degrees (relative to true

north)

True heading 197 Degrees

Time stamp 15 UTC Seconds

RAIM flag 0 (not in use) Boolean

Communication state 66172 Struct (see

Table 3.12)

Figure 3.36 Vessel public information from Marine Traffic webpage for the decoded AIS signal (MMSI 263528000).


53

4 Implementation

The final goal of this project is the development of an SDR solution over an SCA framework,

specifically, the REDHAWK framework. That is why the detectors and demodulators modules

previously designed in MATLAB must be ported to a programming language supported by the

framework, in this case, C language.

This section presents the C language implementation of the detector and demodulator systems. It

also includes the implementation of the EPIRB decoder based on the technical revision [20], but

in this case, in the C ++ language. Finally, it discusses the REDHAWK realization for each

component.

4.1 Dependencies

For the implementation in C, two different libraries are used mainly: liquid-dsp for signal

processing in the detector and demodulator components, and Protocol Buffers or Protobuf to send

decoded information from the EPIRB decoder and from the NMEA converter as serialized

messages.

4.1.1 Liquid-Dsp

For detector and demodulator signal processing operations, an external library that will be a hard

dependency for these C components is used. This library is liquid-dsp [24] , a free and open-

source digital signal processing (DSP) library designed specifically for software-defined radios

on embedded systems. It provides a lightweight DSP library with basic and advanced signal

processing designed elements like filters, oscillators, modems, synchronizers… It supports

complex mathematical operations and it is a highly flexible, scalable and dynamic library. All the

documentation and the API can be found in GitHub liquid-dsp repository [25] or in the online

documentation [26].

From this library, a common API of utility functions is created, which contains a set of functions

used by the different implementations discussed below. Figure 4.1 shows the header of this API.


54

Figure 4.1 API with utility functions.

4.1.2 Protocol Buffers

Protocol Buffers [27] (commonly named Protobuf) is a method of serializing structured data

developed by Google. It is useful in development environments to communicate over the network

various components that can be written in different programming languages. The method involves

an interface description language that describes the data structure and a program or compiler that

generates source code from that description for serializing or deserializing a stream of bytes that

represents the structured data.

Protobuf is widely used at Google for storing and interchanging all kind of structured information.

The design goals for Protobuf were the simplicity and performance. It was designed to be smaller

and faster that XML.

#ifndef _CRTDSP_H_ #define _CRTDSP_H_

#include <liquid/liquid.h>

typedef struct {

int binStart;

int binEnd;

} __attribute__((packed)) HopperStruct; // Utility struct to store burst bondaries

typedef struct {

float complex *samples;

int samplesSize; int timestampOffset;

} __attribute__((packed)) BurstStruct; // Utility struct to store burst samples and timestamp offsets

int writeComplexVectorToFile (const char *filename, float complex * sampleVector, int vectorSize);

int loadFile (const char * filename, float * sampleVector, int vectorSize);

int writeFloatVectorToFile (const char *filename, float * sampleVector, int vectorSize);

int findMaxAbs(float vector[], int vectorSize);

int findMax(float vector[], int vectorSize, float * maxValue);

float sumComplexVectorAbs(float complex vector[], int vectorSize);

float sumVectorAbs(float vector[], int vectorSize);

int vectorSquare(float vector[], int vectorSize); int complexVectorAbs(float complex inVector[], int vectorSize, float outVector[]);

float sumVector(float vector[], int vectorSize);

float findNoiseLevelThreshold(float complex *dataSamplesBuffer, int dataSamplesBufferSize) ;

int wola(const float complex *vector, int vectorSize, int windowSize, float complex *outVector);

int semavg(float *inVector, int inVectorSize, float *outVector, int windowSize); // A moving average

of size windowSize is applied to the input samples

int gefhDetect(char *flagDetectionArray, char *flagPostdetectionArray, int flagsLength, HopperStruct

*hopperArray, int maxHopperArraySize, int *hopperArraySize); // Detección de pulsos

int cleanBurstStruct(BurstStruct *burstStruct, int burstStructSize);

void *cicCreate(int R, int N, int M);

void cicProcess(void *f, const float complex *in, int inSize, float complex *out, int *outSize); void cicDelete(void *f);

#endif /* _CRTDSP_H_ */


55

Data structures and services are described in a protobuf definition file with proto extension. With

this file, the protobuf compiler will generate code that can be called by the sender or the receiver.

Officially, Protobuf provides a code generator for C++, C#, Java, Javascript, Ruby, Go, PHP and

Python, although there are some third parties that have Protobuf implementations for other

programming languages (as C, Perl, R…) [28].

AIS and EPIRB .proto files are portrayed in Figure 4.2 and Figure 4.3, respectively. In both files,

heartbeat messages are defined to tell the receiver that the waveforms are alive. This kind of

message is usually sent every one or two seconds. It is necessary to stress that EPIRB protocol

file is considerably larger than AIS protocol file. This is because the NMEA message decoded

from AIS can be easily parsed using external libraries from the receiver end. On the other hand,

there is not a similar one for EPIRB decoded bits, so EPIRB decoder must be implemented to

send this information.

For AIS messages, the decoded NMEA is sent together with the detection timestamp, power and

frequency. For EPIRB messages, the decoded EPIRB protocol message is sent with detection

timestamp, power and frequency.

Figure 4.2 AIS Protobuf description file.

syntax = "proto2";

package ais;

// Messages

message Out { oneof type {

Heartbeat heartbeat = 1;

Nmea nmea = 2;

}

}

// Submessages

message Heartbeat {

optional int32 uptime = 1;

}

message Nmea { optional double timestamp = 1;

optional float power = 2;

optional uint64 frequency = 3;

required string aisNmea = 4;

}


56

syntax = "proto2";

package epirb;

// Messages

message Out {

oneof type {

Heartbeat heartbeat = 1;

Epirb epirb = 2;

}

}

// Submessages

message Heartbeat {

optional int32 uptime = 1;

}

enum BeaconOperation {

NORMAL_OPERATION = 0;

SELFTEST_OPERATION = 1;

}

enum RlsBeaconType {

ELT = 1;

EPIRB = 2;

PLB = 3;

}

enum UserLocationProtocolType {

ORBITOGRAPHY = 0;

ELT_AVIATION = 1;

EPIRB_MARITIME = 2;

SERIAL = 3;

NATIONAL = 4;

EPIRB_RADIO_CALL_SIGN = 6;

TEST = 7;

}

enum SerialUserProtocolBeaconType {

ELT_SERIAL_IDENTIFICATION_NUMBER = 0;

ELT_AIRCRAFT_DESIGNATOR_SERIAL_NUM

BER = 1;

FLOAT_FREE_EPIRB_SERIAL_NUMBER = 2;

ELT_AIRCRAFT_24BIT_ADDRESS = 3;

NON_FLOAT_FREE_EPIRB_SERIAL_NUMBER

= 4;

PLB_SERIAL_NUMBER = 6;

}

enum StandardLocationProtocolType {

EPIRB_MMSI = 2;

ELT_24BIT_ADDRESS = 3;

ELT_SERIAL = 4;

ELT_AIRCRAFT_OPERATOR = 5;

EPIRB_SERIAL = 6;

PLB_SERIAL = 7;

SHIP_SECURITY = 12;

STANDARD_TEST = 14;

}

enum NationalLocationProtocolType {

NATIONAL_ELT = 8;

NATIONAL_EPIRB = 10;

NATIONAL_PLB = 11;

NATIONAL_TEST = 15;

}

enum RlsLocationProtocolType {

RLS = 13;

}

enum UserShortProtocolType {

USER_ORBITOGRAPHY = 0;

USER_AVIATION = 1;

USER_MARITIME = 2;

USER_SERIAL = 3;

USER_NATIONAL = 4;

USER_SPARE = 5;

USER_RADIO_CALL_SIGN = 6;

USER_TEST = 7;

}

enum AuxiliaryRadioLocationDevice {

NO_AUXILIARY_RADIO_LOCATION_DEVICE

= 0;

AUXILIARY_121MHZ = 1;

AUXILIARY_MARITIME_9GHZ = 2;

AUXILIARY_OTHER = 3;

}

enum ActivationType {

MANUAL_ACTIVATION_ONLY = 0;

AUTOMATIC_AND_MANUAL_ACTIVATION =

1;

}

enum MaritimeEmergencyCode {

UNSPECIFIED_DISTRESS = 0;

FIRE_EXPLOSION = 1;

FLOODING = 2;

COLLISION = 3;

GROUNDING = 4;

LISTING_DANGER_CAPSIZING = 5;

SINKING = 6;

DISABLED_AND_DRIFT = 7;

enum ActivationType {

MANUAL_ACTIVATION_ONLY = 0;

AUTOMATIC_AND_MANUAL_ACTIVATION = 1;

}

enum MaritimeEmergencyCode {

UNSPECIFIED_DISTRESS = 0;

FIRE_EXPLOSION = 1;

FLOODING = 2;

COLLISION = 3;

GROUNDING = 4;

LISTING_DANGER_CAPSIZING = 5;

SINKING = 6;

DISABLED_AND_DRIFT = 7;

ABANDONING_SHIP = 8;

}

message UserLocation {

optional uint64 mmsiRadioCallSign = 1;

optional uint64 radioCallSign = 2;

optional SerialUserProtocolBeaconType

serialUserProtocolBeaconType = 3;

optional uint32 csTypeApprovalFlag = 4;

optional uint32 csCertNationalUse = 5;

optional uint32 serialNumber = 6;

optional uint64 aircraftRegistrationMarking = 7;

optional uint64 nationalUse = 8;

optional uint64 testBeaconData = 9;

optional uint64 orbitographyData = 10;

optional uint32 encodedPositionDataSource = 11;

optional AuxiliaryRadioLocationDevice

auxiliaryRadioLocationDevice = 12;

optional UserLocationProtocolType

userLocationProtocolType = 13;

optional uint32 specificEltNumber = 14;

}

message StandardLocation {

optional uint32 mmsiLastDigits = 1;

optional uint32 beaconNumber = 2;

optional uint32 aircraft24BitAddress = 3;

optional uint32 aircraftOperatorDesignator = 4;


optional uint32 csTaNumber = 6;

optional uint32 serialNumberLong = 7;


optional uint32 homing121Mhz = 9;

optional StandardLocationProtocolType

standardLocationProtocolType = 10;

}

message NationalLocation {

optional uint32 nationalIdNumber = 1;

optional uint32 additionalDataFlag= 2;



optional NationalLocationProtocolType

nationalLocationProtocolType = 5;

}

message RlsLocation {

optional RlsBeaconType rlsBeaconType = 1;

optional uint32 nationalIdNumber = 2;

optional uint32 additionalDataFlag= 3;



optional uint32 rlsData = 6;

optional RlsLocationProtocolType rlsLocationProtocolType

= 7;

}

message UserShort {

optional UserShortProtocolType userShortProtocolType =

1;


optional uint32 specificBeacon = 3;

optional uint32 firstFourChars = 4;

optional uint32 lastThreeChars = 5;

optional SerialUserProtocolBeaconType beaconType = 6;

optional uint32 csCertFlag = 7;


optional uint32 csCertNumber = 9;



optional uint64 nationalUser = 12;

optional AuxiliaryRadioLocationDevice

auxiliaryRadioLocationDevice = 13;

optional uint32 emergencyCodeUse = 14;

optional ActivationType activationType = 15;

optional MaritimeEmergencyCode natureOfDistress = 16;

optional uint32 natureOfDistressFire = 17;

optional uint32 natureOfDistressMedicalHelpRequired =

18;

optional uint32 natureOfDistressDisabled = 19;

}

message Epirb {

optional double timestamp = 1;



optional BeaconOperation beaconOperation = 4;


57

Figure 4.3 EPIRB Protobuf description file.

4.2 Implementation in C/C++

4.2.1 EPIRB

In this section, the former EPIRB detector and demodulator designed in MATLAB will be

implemented in C. On other hand, the EPIRB decoder needs to be implemented in C++ for

compatibility reasons with Protobuf.

4.2.1.1 EPIRB detector

EPIRB detector has been implemented in C in a library with two different files: epirb-detect.h

and epirb-detect.c. EPIRB detector’s header file can be found in Figure 4.4. It includes three

functions, epirb_detect_init, epirb_detect_uninit and epirb_detect.

message UserShort {

optional UserShortProtocolType userShortProtocolType = 1;


optional uint32 specificBeacon = 3;

optional uint32 firstFourChars = 4;

optional uint32 lastThreeChars = 5;

optional SerialUserProtocolBeaconType beaconType = 6;

optional uint32 csCertFlag = 7;


optional uint32 csCertNumber = 9;



optional uint64 nationalUser = 12;

optional AuxiliaryRadioLocationDevice auxiliaryRadioLocationDevice = 13;

optional uint32 emergencyCodeUse = 14;

optional ActivationType activationType = 15;

optional MaritimeEmergencyCode natureOfDistress = 16;

optional uint32 natureOfDistressFire = 17;

optional uint32 natureOfDistressMedicalHelpRequired = 18;

optional uint32 natureOfDistressDisabled = 19;

}

message Epirb {

optional double timestamp = 1;



optional BeaconOperation beaconOperation = 4;

optional uint32 formatFlag = 5;

optional uint32 protocolFlag = 6;

optional uint32 countryCode = 7;

optional uint32 protocolType = 8;

optional uint32 mmsi = 9;


optional uint32 beaconNumber = 11;

optional float latitude = 12;

optional float longitude = 13;

optional uint32 resolutionError = 14;

optional float resolutionLat = 15;

optional float resolutionLon = 16;

optional UserLocation userLocation = 17;

optional StandardLocation standardLocation = 18;

optional NationalLocation nationalLocation = 19;

optional RlsLocation rlsLocation = 20;

optional UserShort userShort = 21;

}


58

The initial function epirb_detect_init() is responsible for initializing all the signal processing

buffers with the appropriate length and content. These buffers are the following:

• Kaiser window used in the channelization process based on the WOLA technique.

• CIC filter for sample decimation.

• FIR filter.

• Compensation filter.

The function epirb_detect_uninit is used to free all the allocated memory used by the signal

processing buffers.

The function epirb_detect() is the operational function which implements the signal processing

steps and stages followed in the MATLAB design. This function takes as input multiple

parameters: the complex samples from the EPIRB signal, the length of these samples buffer, the

name of the callback function that will be called to send the detected signal (typically to the

EPIRB decoder) and a context variable.

The callback function receives the detected data signal, the burst detection timestamp and the

noise floor power.

Figure 4.5 shows the static and global variables used in epirb-detect.c. It follows the design of the

EPIRB detector in MATLAB. Among them we can find:

• Sample rate.

• Sizes for the Kaiser window, WOLA and FFT buffers.

• FFT bins used for EPIRB channel power and noise power computing.

• Decimation values and filters coefficients for the initialization function.

Figure 4.4 File header for EPIRB detector (epirb-detect.h).

#ifndef _EPIRB_DETECT_H_

#define _EPIRB_DETECT_H_


typedef void (*epirb_detect_callback)(liquid_float_complex *data, int nsamples, float noiseLevel, void *context);

void epirb_detect_init();

void epirb_detect_uninit();

int epirb_detect(liquid_float_complex *data, int nsamples, epirb_detect_callback cb, void *context);

#endif /* _EPIRB_DETECT_H_ */

/// @}


59

Figure 4.5 Global variables and definitions for epirb-detect.c component.

#define MAX_BURSTS 1000 #define FS 384000 // Sample rate

#define FRES 200 // Frequency resolution between FFT bins

#define M 1920 /* FS / FRES: Window size */

#define W 15

#define N 128 /* M / W: Wola vector size */

#define EPIRB_COUNT 4 // Epirb active channels

#define NOISE_COUNT 13 // Noise bin length

// FFT bins indexes in which levels will be calculated

static const int EPIRB_BINS[EPIRB_COUNT] = { 8, 9, 12, 13 };

static const int NOISE_BINS[NOISE_COUNT] = { 113, 114, 115, 116, 117, 118, 119, 120, 121,

122, 123, 124, 125 };

static float window[M];

static float complex *ol[EPIRB_COUNT];

// Local oscillators to downconvert the isolated signal to baseband

static const int OL_SIZES[EPIRB_COUNT] = { 16, 128, 32, 128 };

static const int OL_FACTORS[EPIRB_COUNT] = { -1, -9, -3, -13 };

// Filtering and sample rate decimation

#define R_CIC 24

#define N_CIC 5 #define M_CIC 1

static void *cic = NULL;

#define R_LPF 2

#define LPF_NCOEFS 49

static float LPF_COEFS[LPF_NCOEFS] = {

6.5316e-04, -1.3480e-03, -3.4837e-03, -1.9483e-03, 2.9890e-03, 3.9208e-03, -

2.6167e-03, -7.0760e-03,

2.8635e-04, 1.0208e-02, 4.4927e-03, -1.2108e-02, -1.1929e-02, 1.1151e-02,

2.1678e-02, -5.3726e-03,

-3.2817e-02, -7.7787e-03, 4.3960e-02, 3.3002e-02, -5.3499e-02, -8.6045e-02, 5.9937e-02, 3.1133e-01,

4.3779e-01, 3.1133e-01, 5.9937e-02, -8.6045e-02, -5.3499e-02, 3.3002e-02,

4.3960e-02, -7.7787e-03,

-3.2817e-02, -5.3726e-03, 2.1678e-02, 1.1151e-02, -1.1929e-02, -1.2108e-02,

4.4927e-03, 1.0208e-02,

2.8635e-04, -7.0760e-03, -2.6167e-03, 3.9208e-03, 2.9890e-03, -1.9483e-03, -

3.4837e-03, -1.3480e-03,

6.5316e-04,

};

static firdecim_crcf lpf;

#define COMPF_NCOEFS 31

static float COMPF_COEFS[COMPF_NCOEFS] = {

0.0275368, -0.0219564, 0.0088191, 0.0086820, -0.0209589, 0.0356515, -

0.0402038, 0.0340173, -0.0166045,

-0.0108095, 0.0445829, -0.0796495, 0.1083805, -0.1170880, 0.0472193,

1.0196830, 0.0472193, -0.1170880,

0.1083805, -0.0796495, 0.0445829, -0.0108095, -0.0166045, 0.0340173, -

0.0402038, 0.0356515, -0.0209589,

0.0086820, 0.0088191, -0.0219564, 0.0275368,

};

static firfilt_crcf compf;

#define min(a, b) ((a) < (b)) ? (a) : (b)

#if 0

#endif


60

The Figure 4.6 shows the source code used to validate the library epirb-detect. This is a simple

program which opens and reads the file that contains floating-point complex data from a recorded

EPIRB signal (the same file used to validate the MATLAB modules), initializes EPIRB detector

and sends these samples to the EPIRB detector. The compiled binary execution will indicate the

noise floor and the samples where EPIRB burst signal was detected. The elapsed time for this

process is also printed for profiling purposes (see Figure 4.7).

Figure 4.6 Source code for EPIRB detector example.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <math.h>

#include <complex.h>

#include <sys/time.h>

#include "epirb_detect.h"

int main() {

// Read input file samples

FILE* fid2 = fopen( "samples/epirb_jotron_384ksps_agc_406.001mhz.dat", "rb");

float complex *fileSamplesBuffer;

int fileSamplesBufferSize;

if (!fid2){

printf("Error opening file\n");

return 0;

} else {

fseek(fid2, 0L, SEEK_END); int fileSize = ftell(fid2);

rewind(fid2);

fileSamplesBufferSize = fileSize / 8;

printf("File size %d\n", fileSamplesBufferSize);

fileSamplesBuffer = (float complex*)malloc(fileSamplesBufferSize * sizeof(float

complex));

for (int i = 0; i < fileSize / 8; i++) {

float realPart, imagPart;

size_t readRes;

readRes = fread(&realPart, sizeof(float), 1, fid2);

readRes = fread(&imagPart, sizeof(float), 1, fid2); fileSamplesBuffer[i] = realPart + I * imagPart;

}

fclose(fid2);

}

int fileSamplesReadSize = 0;

epirb_detect_init();

struct timeval stop, start;

gettimeofday(&start, NULL);

epirb_detect(fileSamplesBuffer, fileSamplesBufferSize, NULL, NULL);

free(fileSamplesBuffer); gettimeofday(&stop, NULL);

printf("took %lu usecs\n", (stop.tv_sec * 1000000 + stop.tv_usec) - (start.tv_sec * 1000000 +

start.tv_usec));

epirb_detect_uninit();

return 0;

}


61

Figure 4.7 Results from EPIRB detector example.

4.2.1.2 EPIRB demodulator

This library will implement the state machine defined in Figure 3.13 during the EPIRB

demodulator design. The header file, epirb-demod.h, can be seen in Figure 4.8.

Figure 4.8 File header for EPIRB demodulator.

The only function in this component, epirb_demod(), will take as input the detected/isolated signal

coming from EPIRB detector and the measured noise floor, the samples per symbol defined for

this kind of signal (20 samples per symbol for EPIRB) and the payload pointer where the

demodulated bits returned by the function will eventually be stored. This buffer will be as big as

bitPlayloadMaxSize defines.

EPIRB demodulator example can be found in Figure 4.9. In this case, the EPIRB burst signal

isolated by the EPIRB detector was stored in file epirb_burst.dat. This program will open and

read this file and will send samples to epirb_demod() function, together with the noise floor (also

calculated by the EPIRB detector) and the bit buffer pointer.

Execution outcomes of the compiled program can be seen in Figure 4.10. It can be checked that

the payload binary value is the same as the one we obtained by executing the EPIRB’s

demodulator in MATLAB. This result validates both the EPIRB detector and the demodulator

implementations.

#ifndef _EPIRB_DEMOD_H_

#define _EPIRB_DEMOD_H_


#define PHASE_THRESHOLD_1 0.7

#define PHASE_THRESHOLD_2 1.5

int epirb_demod(liquid_float_complex *inputBuffer, int inputBufferSize, int samplesPerSymbol, float

noiseThreshold, char *bitPlayload, int bitPlayloadMaxSize);

#endif /* _EPIRB_DEMOD_H_ */


62

Figure 4.9 Source code for EPIRB demodulator example.

#include <stdio.h> #include <stdlib.h>

#include <string.h>

#include <math.h>



#include "epirb_demod.h"

int main(int argc, char **argv) {

float noiseThreshold = 0.000005;

char *file = "samples/epirb_burst.dat";

int bitPayloadMaxSize = 200; unsigned char bitPayload[bitPayloadMaxSize];

int samplesPerSymbol = 20;

if (argc == 2) {

file = argv[1];

}

//Read input file samples

FILE* fid2 = fopen(file, "rb");

float complex *fileSamplesBuffer;

int fileSamplesBufferSize; if (!fid2){


return 0;

} else {

fseek(fid2, 0L, SEEK_END);

int fileSize = ftell(fid2);

rewind(fid2);

fileSamplesBufferSize = fileSize/8;

fileSamplesBuffer = (float complex*) malloc(fileSamplesBufferSize*sizeof(float

complex));

for (int i=0; i<(fileSize/8); i++) {

float realPart, imagPart; size_t readRes;


readRes = fread(&imagPart, sizeof(float), 1, fid2);

fileSamplesBuffer[i] = realPart + I*imagPart;

}

fclose(fid2);

}

printf("fileSamplesBufferSize %d\n",fileSamplesBufferSize);

struct timeval stop, start; gettimeofday(&start, NULL);

memset(bitPayload,0,bitPayloadMaxSize * sizeof(unsigned char));

epirb_demod(fileSamplesBuffer, fileSamplesBufferSize, samplesPerSymbol,

noiseThreshold, bitPayload, bitPayloadMaxSize);

printf("Bit payload %s\n",bitPayload);

gettimeofday(&stop, NULL);

printf("took %lu\n", stop.tv_usec - start.tv_usec);

return 0;

}


63

Figure 4.10 Results from EPIRB demodulator example.

4.2.1.3 EPIRB decoder

This component will decode the bit sequence from EPIRB demodulator using the defined protocol

tables from EPIRB technical document [20]. Its header is portrayed in Figure 4.11. For

compatibility reasons with Protobuf, it has been written in C++.

Figure 4.11 File header for EPIRB decoder.

It only has one function, parseEpirbBinary(). This function takes a vector or buffer of bits,

decodes them in order to take all EPIRB information and generates a Protobuf binary message

with all the information serialized. It requires the compiled headers from EPIRB Protobuf

description file (Figure 4.3) in order to use the objects that store all data and functions required to

serialize the message to some data stream.

Figure 4.12 shows the source code of a test program that reads an input file with binary data (bit

array from EPIRB demodulator output), parses it via the EPIRB decoder function and generates

the corresponding Protobuf message.

The results from the execution of the compiled example can be found in Figure 4.13. It can be

checked that the decoded information is the same as that decoded by the official decoding tool

from COSPAS-SARSAT (Figure 3.20). Also, C/S TAC number and serial number are the same

as those in Figure 3.21. This outcome shows a correct behavior of EPIRB’s decoder component.

#include "epirb.pb.h"

using namespace epirb;

int parseEpirbBinary (std::vector<u_int8_t> bitVector, BeaconWrapperMessage * outMsg);


64

Figure 4.12 Source code for EPIRB decoder example.

Figure 4.13 Results from EPIRB decoder example.

#include "epirb-decoder.h" #include <iostream>

#include <fstream>

#include <math.h>

using namespace epirb_messages;

using namespace std;

int readInputFile(const char * fileName, std::vector<u_int8_t> * bitVector) {

std::ifstream is(fileName);

char c;

while (is.get(c)){ bitVector->push_back(c - 48);

}

bitVector->pop_back(); //Remove las file char

is.close();

return 0;

}

int main(int argc, char* argv[]) {

GOOGLE_PROTOBUF_VERIFY_VERSION;

std::vector<u_int8_t> bitVector; readInputFile("epirb_binarydata.txt",&bitVector);

BeaconWrapperMessage outMsg;

parseEpirbBinary(bitVector, &outMsg);

cout << outMsg.DebugString() << endl;

}


65

4.2.2 AIS

4.2.2.1 AIS detector and demodulator

In the implementation of AIS components, both detector and demodulator were grouped in the

same source code. The header file of this component is shown in Figure 4.14.

Figure 4.14 File header for AIS detector and demodulator.

/**

* Header for AIS detect and demodulation library

*/

#ifndef _AIS_DEMOD_H_

#define _AIS_DEMOD_H_


#include "../libcrtdsp/crtdsp.h"

#define SYNC_SIGNAL_SIZE 24

#define SYNC_IDEAL_SIZE 20

#define SYNC_CORR_SIZE 50

//Reference signals, filters and parameter for AIS demodulation

typedef struct {

int samplesPerSymbol;

//Gaussian filter float * lpfCoefs;

int lpfCoefsSize;

firfilt_crcf lpfObject;

//Sync ideal signal for correlation

float * syncIdeal;

} AisRefSignals;

int initRefSignals(AisRefSignals *refSignals, int samplesPerSymbol);

int clearRefSignals(AisRefSignals *refSignals);

int aisUnstuff(unsigned char * vector, int vectorSize); // Performs bit unstuffing following AIS spec int checkCrc16(unsigned char * inVector, unsigned short crc); // Computes and checks CRC

int packBitsToBytes(unsigned char *inVector, unsigned char *outVector, int inVectorSize);

int flipBytes(unsigned char * vector, int vectorSize); // Swaps byte order

int dataToAscii(unsigned char *vector, int vectorSize); // Converts bytes to ASCII characters (6 bits).

int buildNmeaSentence(unsigned char *aisVector, int vectorSize, unsigned char *sentence, const char

* designator, int padding, int *multiFrameIdx); // Builds the NMEA1803 sentence.

int ais_detect(liquid_float_complex *dataSamplesBuffer, int dataSamplesBufferSize, float *window,

liquid_float_complex *olTable, int olTableSize, float * lpfCoefs, int lpfCoefsSize, float minDuration,

BurstStruct *aisBurstStruct, int *aisBurstStructIdx, int maxAisBurstInCapture, int *needMoreSamplesIdx); // Detects AIS bursts from input signal

int ais_demod(AisRefSignals refSignals, int *multiFrameIdx, liquid_float_complex

*inputSamplesBuffer, int inputSamplesBufferSize, int typeOfChannel, int samplesPerSymbol, int

*aisMessageSizeBytes, unsigned char *aisMessage, int *needMoreSamples); // Demodulates the AIS

burst signal.

#endif /* _AIS_DEMOD_H_ */


66

In this component, you can find the definition of a struct (AisRefSignals) which stores the

coefficients for the low pass filter used in the detection stage and ideal synchronization preamble

signal used in the correlation process of the AIS detector. The number of samples per symbol is

also stored.

This struct is initialized via initRefSignals() function that reads the files where both LPF

coefficients and ideal synchronization preamble samples are stored in different data buffers.

The inverse function is clearRefSignals() which are used to free the allocated memory used by

the data buffers.

The main functions in this header are ais_detect() and ais_demod(). These functions are the

implementation of MATLAB components designed in 3.2.2.

There are multiple utility functions as the following:

• aisUnstuff(): It performs the unstuffing process defined in AIS technical document [1].

• packBitsToBytes(): It just packs bits in bytes.

• checkCrc16(): It creates the CRC value from the demodulated message and check its

value against the CRC bits demodulated to validate the message.

• flipBytes(): It flips the byte order before building the NMEA sentence.

You can find the implementation of a function that will build the NMEA1083 sentence from each

decoded AIS burst via the buildNmeaSentence() function. The reason to build NMEA sentences

is that they are compatible with open-source AIS decoding libraries at the receiver end.

The process to build an NMEA sentence from the demodulated data is covered in [1] and [23]. It

is important to realize that the NMEA data payload is represented by 6-bit-long ASCII characters

as mentioned in section 2.2.1. Table 4.1 shows the entire transformation table for each ASCII

character.

The conversion from 8 bits ASCII to 6 bits ASCII is carried out by dataToAscii() function.

Figure 4.15 shows the source code of the AIS detector and demodulator example. This program

will open and read the file that contains floating-point complex data from the AIS burst signal

(the same file used in section 3.2.3), initializes all variables (such as filters and ideal synchronous

signals) and sends these samples to the AIS detection function.

Each detected AIS burst will be sent to the demodulation function, whose outcome will be the

valid NMEA sentences.


67

Table 4.1 Six bit ASCII characters [1].

6-Bit ASCII 6-Bit ASCII

Chr Dec Hex Binary Chr Dec Hex Binary

@ 0 0x00 00 0000 ! 33 0x21 10 0001

A 1 0x01 00 0001 ” 34 0x22 10 0010

B 2 0x02 00 0010 # 35 0x23 10 0011

C 3 0x03 00 0011 $ 36 0x24 10 0100

D 4 0x04 00 0100 % 37 0x25 10 0101

E 5 0x05 00 0101 & 38 0x26 10 0110

F 6 0x06 00 0110 ` 39 0x27 10 0111

G 7 0x07 00 0111 ( 40 0x28 10 1000

H 8 0x08 00 1000 ) 41 0x29 10 1001

I 9 0x09 00 1001 * 42 0x2A 10 1010

J 10 0x0A 00 1010 + 43 0x2B 10 1011

K 11 0x0B 00 1011 , 44 0x2C 10 1100

L 12 0x0C 00 1100 – 45 0x2D 10 1101

M 13 0x0D 00 1101 . 46 0x2E 10 1110

N 14 0x0E 00 1110 / 47 0x2F 10 1111

O 15 0x0F 00 1111 0 48 0x30 11 0000

P 16 0x10 01 0000 1 49 0x31 11 0001

Q 17 0x11 01 0001 2 50 0x32 11 0010

R 18 0x12 01 0010 3 51 0x33 11 0011

S 19 0x13 01 0011 4 52 0x34 11 0100

T 20 0x14 01 0100 5 53 0x35 11 0101

U 21 0x15 01 0101 6 54 0x36 11 0110

V 22 0x16 01 0110 7 55 0x37 11 0111

W 23 0x17 01 0111 8 56 0x38 11 1000

X 24 0x18 01 1000 9 57 0x39 11 1001

Y 25 0x19 01 1001 : 58 0x3A 11 1010

Z 26 0x1A 01 1010 ; 59 0x3B 11 1011

[ 27 0x1B 01 1011 < 60 0x3C 11 1100

\ 28 0x1C 01 1100 = 61 0x3D 11 1101

] 29 0x1D 01 1101 > 62 0x3E 11 1110

^ 30 0x1E 01 1110 ? 63 0x3F 11 1111

– 31 0x1F 01 1111

Space 32 0x20 10 0000


68

Figure 4.15 Source code for AIS detector and demodulator example.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <math.h>



#include "ais_demod.h"

int main() {

//Read input file samples

FILE* fid2 =

fopen("doc/ais_bouzas_200k_g76_162mhz_1_burst.dat",

"rb");

liquid_float_complex *fileSamplesBuffer;

int fileSamplesBufferSize;

if (!fid2){


return 0;

} else {

fseek(fid2, 0L, SEEK_END);

int fileSize = ftell(fid2);

rewind(fid2);

fileSamplesBufferSize = fileSize/8;

printf("File size %d\n",fileSamplesBufferSize);

fileSamplesBuffer = (liquid_float_complex*);

malloc(fileSamplesBufferSize*sizeof(liquid_float_comple

x));

for (int i=0; i<(fileSize/8); i++) {

float realPart, imagPart;

size_t readRes;


readRes = fread(&imagPart, sizeof(float), 1, fid2);

fileSamplesBuffer[i] = realPart + I*imagPart;

}

fclose(fid2);

}

int fileSamplesReadSize = 0;

//Initialize detect params

int M = 960;

float beta = 6.9;

float window[M];

loadFile("ref_signals/kaiser_M960_9-6.dat", window,

M);

float sumWindow = sumVector(window, M);

for (int i=0; i<M; i++) {

window[i] = window[i] * M / sumWindow;

}

int olTableSize = 96; //Assuming sample rate 96Ksps.

25KHz is the offset of the AIS channels (162.025 161.975)

float olFactor = 25.0 / olTableSize;

liquid_float_complex olTable[olTableSize];

for (int i=0; i<olTableSize; i++) {

olTable[i] = cexpf(I * 2 * M_PI * olFactor * i);

}

int lpfCoefsSize = olTableSize / 2;

float lpfCoefs[lpfCoefsSize];

loadFile("ref_signals/lpf.dat", lpfCoefs, lpfCoefsSize);

int fs = 48000*2;

float minDuration = 0.022; //Min AIS burst duration

int maxAisBurstInCapture = (int)

ceil((fileSamplesBufferSize * 1.0) / fs / minDuration * 2);

struct timeval stop, start;

gettimeofday(&start, NULL);

int multiFrameIdx = 0; //Ais index % 10 for multiframe

indexing

int needMoreSamples = 0;

int aisMessageSizeBytes = 1024;

BurstStruct aisBurstStruct[maxAisBurstInCapture];

memset(aisBurstStruct, 0,

maxAisBurstInCapture * sizeof(BurstStruct));

int aisBurstStructIdx = 0;

AisRefSignals aisRefSignals;

int samplesPerSymbol = 5;

initRefSignals(&aisRefSignals, samplesPerSymbol);

unsigned char

aisMessage[aisMessageSizeBytes];

int demodCount = 0;

// Detects all AIS bursts in the signal

ais_detect(fileSamplesBuffer, fileSamplesBufferSize,

window, olTable, olTableSize, lpfCoefs, lpfCoefsSize,

minDuration, aisBurstStruct, &aisBurstStructIdx,

maxAisBurstInCapture, &needMoreSamples);

printf("AIS bursts detected: %d\n", aisBurstStructIdx);

// Each detected AIS burst is demodulated

for (int burstIdx = 0; burstIdx < aisBurstStructIdx;

burstIdx++) {

ais_demod(aisRefSignals, &multiFrameIdx,

aisBurstStruct[burstIdx].samples,

aisBurstStruct[burstIdx].samplesSize,

aisBurstStruct[burstIdx].typeOfChannel,

samplesPerSymbol, &aisMessageSizeBytes, aisMessage,

&needMoreSamples);

printf("NMEA:

%s\n",aisBurstStruct[burstIdx].samplesSize,

aisMessageSizeBytes, needMoreSamples, aisMessage);

if (aisMessageSizeBytes != 1024) {

demodCount++;

}

aisMessageSizeBytes = 1024;

memset(aisMessage ,0 ,aisMessageSizeBytes *

sizeof(unsigned char));

}

clearRefSignals(&aisRefSignals);

cleanBurstStruct(aisBurstStruct, maxAisBurstInCapture);

return 0;

}


69

Figure 4.16 shows the result after running this example. The NMEA generated is the following:

! 𝐴𝐼𝑉𝐷𝑀, 1,1, , 𝐵, 13𝑠𝐷𝑁@0000𝑤𝐺𝑗 < 𝐷𝐻; 𝑃? 𝑊𝐾𝐹: 𝑁0@9𝑡, 0 ∗ 33

Figure 4.16 Result from AIS detector and demodulator example.

This NMEA can be decoded by any NMEA decoding tool that can be found online. For the

validation, we are going to use http://ais.tbsalling.dk/.

Figure 4.17 a) Introducing the NMEA sentence in AIS decoding tool from http://ais.tbsalling.dk/. b) Decoded AIS message.

Figure 4.17b) shows the decoding results. It can be checked that the decoded parameters are the

same as the decoded information from MATLAB scripts (Table 3.13). This outcome shows a

correct behavior of the AIS detector and demodulator components.

http://ais.tbsalling.dk/

http://ais.tbsalling.dk/


70

4.3 Implementation in REDHAWK

This section describes how to integrate the previously described and tested C components into

REDHAWK to finally implement the SDR system. To achieve that the REDHAWK components,

waveforms and node must be defined. Next subsections describe the REDHAWK elements

designed.

4.3.1 REDHAWK components

The reader should read the APPENDIX I: REDHAWK components creation concepts to

understand all the concepts related to the creation of a SCA component in REDHAWK.

4.3.1.1 EPIRB

In these section two REDHAWK components for the EPIRB part will be presented, the EPIRB

demodulator and the decoder.

4.3.1.1.1 EPIRB demodulator component

The first component is the epirb_demodulator. This component will wrap the functionality of

both EPIRB detector and demodulator via construct() and serviceFunction() methods from

epirb_demodulator.cpp file.

The properties of this component are the following:

• EPIRB_message_event: this is a struct property of type message that has five different

parameters:

o time_start_sec (double): indicates the instant in UTC seconds when the EPIRB

burst was detected.

o time_start_fracsec (double): this value is the fraction of seconds of the previous

property.

o data (string): this property contains the bits demodulated from the EPIRB burst

as a string.

o rssi (float): this is the EPIRB burst power value in dBm.

o epirb_frequency_hz (ulong): this is the frequency channel value of the detected

EPIRB burst in Hz.

• Hb_message_event: this is a struct property of type message with only one parameter

named is_alive, which is a Boolean that indicates whether the component is working and

processing samples. This heartbeat is useful to detect if the component stop running.

Three ports have been defined in this component:

• dataFloat_in: this input port of type BULKIO/float is used to inject the complex samples.

• event_out: this output port of type MessageEvent is used to send the

EPIRB_message_event structs.


71

• hb_event_out: this output port of type MessageEvent is used to notify that

Hb_message_event structs are sent.

Figure 4.18 shows the file hierarchy and component block for the EPIRB demodulator.

Figure 4.18 EPIRB demodulator REDHAWK component file hierarchy and block.

4.3.1.1.2 EPIRB decoder component

The second component is the epirb_decoder. This component will wrap the functionality of the

EPIRB detector presented in 4.2.1.3.


• EPIRB_message_event: it is the same struct property that was defined in 4.3.1.1.1

• Proto_message_event: this is a struct property of type message with only one parameter

named data. This parameter contains the serialized Protobuf message with the decoded

data from the EPIRB burst. The Protobuf description file that defines this message is

shown in Figure 4.3.

Two ports have been defined in this component:

• epirb_event_in: this output port of type MessageEvent is used to inject the

EPIRB_message_event structs.

• proto_event_out: this output port of type MessageEvent is used to send the

Proto_message_event structs.

Figure 4.19 shows the file hierarchy and component block for the EPIRB decoder.

epirb_demodulator/

├── build.sh

├── cpp

│ ├── build.sh

│ ├── configure.ac

│ ├── epirb-demodulator

│ ├── epirb_demodulator_base.cpp

│ ├── epirb_demodulator_base.h

│ ├── epirb_demodulator.cpp

│ ├── epirb_demodulator.h

│ ├── epirb-detector

│ ├── main.cpp

│ ├── Makefile.am

│ ├── Makefile.am.ide

│ ├── reconf

│ └── struct_props.h

├── epirb_demodulator.prf.xml

├── epirb_demodulator.scd.xml

├── epirb_demodulator.spd.xml

├── epirb_demodulator.spec

├── ref_signals

│ ├── ventana_ol0Hz_sintetica_EPIRB.dat

│ └── ventana_ol900Hz_sintetica_EPIRB.dat

└── tests

└── test_epirb_demodulator.py


72

Figure 4.19 EPIRB decoder REDHAWK component file hierarchy and block.

4.3.1.2 AIS

In these section two REDHAWK components for the AIS part will be presented.

4.3.1.2.1 AIS demodulator component

The first component is the ais_demodulator. This component will wrap the functionality of both

AIS detector and demodulator through contstruct() and serviceFunction() methods from

ais_demodulator.cpp file.


• AIS_message_event: this is a struct property of type message that has five different

parameters:

o time_start_sec (double): it indicates the instant in UTC seconds when the AIS

burst was detected.

o time_start_fracsec (double): this value is the fraction of seconds of the previous

property.

o data (string): this property contains the NMEA0183 sentence generated from the

demodulated bits.

o rssi (float): this is the AIS burst power value in dBm.

o epirb_frequency_hz (ulong): this is the frequency channel value of the detected

AIS burst in Hz.

epirb_decoder/

├── build.sh

├── cpp


│ ├── compile


│ ├── epirb_binarydata.txt

│ ├── epirb_decoder_base.cpp

│ ├── epirb_decoder_base.h

│ ├── epirb-decoder.cc

│ ├── epirb_decoder.cpp

│ ├── epirb_decoder.h

│ ├── epirb-decoder.h






├── epirb_decoder.prf.xml

├── epirb_decoder.scd.xml

├── epirb_decoder.spd.xml

├── epirb_decoder.spec

└── tests

└── test_epirb_decoder.py


73

• Hb_message_event: this is a struct property of type message with only one parameter

named is_alive, which is a Boolean that indicates whether the component is working and

processing samples. This heartbeat is useful to detect if the component stops.

Three ports have been defined in this component:

• dataFloat_in: this input port of type BULKIO/float is used to inject the complex samples.

• ais_event_out: this output port of type MessageEvent is used to send the

AIS_message_event structs.

• hb_event_out: this output port of type MessageEvent is used to send the

Hb_message_event structs.

Figure 4.20 shows the file hierarchy and component block for the EPIRB demodulator.

Figure 4.20 AIS demodulator REDHAWK component file hierarchy and block.

4.3.1.2.2 NMEA to Protobuf component

This is a simple component that gets the NMEA0183 sentence sent by the AIS demodulator

component and serializes it into a Protobuf message described by Figure 4.2. Unlike previous

components, the NMEA to Protobuf component was written in Python for simplicity.


• AIS_message_event: it is the same struct property defined in section 4.3.1.2.1.

• Proto_message_event: this is a struct property of type message with only one parameter

named data. This parameter contains the serialized Protobuf message with the generated

NMEA1803 sentence from the AIS burst. The Protobuf description file that defines this

message is shown in Figure 4.2.

ais_demodulator/

├── ais_demodulator.prf.xml

├── ais_demodulator.scd.xml

├── ais_demodulator.spd.xml

├── ais_demodulator.spec

├── build.sh

├── cpp

│ ├── ais-demodulator

│ ├── ais_demodulator_base.cpp

│ ├── ais_demodulator_base.h

│ ├── ais_demodulator.cpp

│ ├── ais_demodulator.h




│ ├── libcrtdsp






└── tests

├── ais_demod_example.c

└── test_ais_demodulator.py


74

Two ports have been defined in this component:

• ais_event_in: this output port of type MessageEvent is used to inject the

AIS_message_event structs.

• proto_event_out: this output port of type MessageEvent is used to send the

Proto_message_event structs.

Figure 4.21 shows the file hierarchy and component block for the EPIRB decoder.

Figure 4.21 NMEA to Protobuf REDHAWK component file hierarchy and block.

4.3.1.3 Message dispatcher component

The REDHAWK waveforms (which will be described later) have an additional component that

allows to send the serialized Protobuf messages to another system through a defined server socket.

This component is named Message Dispatcher.


• Proto_message_event: this is a struct property. It is the same as the defined in 4.3.1.1.2

and 4.3.1.2.2.

• Remote_parameters: this is a struct property that defines the IP (string) and port (integer)

of the remote system that will receive the forwarded data.

Only one input port has been defined in this component:

• proto_event: this input port of type MessageEvent is the port through

Proto_message_event structs are injected.

Figure 4.22 files hierarchy and component block for the Message Dispatcher.

nmea_to_proto/

├── build.sh

├── nmea_to_proto.prf.xml

├── nmea_to_proto.scd.xml

├── nmea_to_proto.spd.xml

├── nmea_to_proto.spec

├── python

│ ├── aclocal.m4

│ ├── autom4te.cache


│ ├── configure


│ ├── install-sh



│ ├── Makefile.in

│ ├── missing

│ ├── nmea_to_proto_base.py

│ ├── nmea_to_proto.py

│ ├── proto

│ └── reconf

└── tests

└── test_nmea_to_proto.py


75

Figure 4.22 Message dispatcher REDHAWK component files hierarchy and block.

4.3.2 REDHAWK waveforms

In this section the integration of all REDHAWK components into two waveforms, one for EPIRB

and the other one for AIS, will be described.

All REDHAWK waveforms are completely defined by the Software Assembly Descriptor (SAD)

file. This is an XML file where all components and devices to be instantiated are defined (as well

as their configuration) and all interconnections between them are set. These waveforms are

launched in the running SCA domain.

4.3.2.1 EPIRB waveform

Figure 4.23 shows the block diagram of the EPIRB waveform. This waveform is composed by

four components and one frontend tuner device:

• USRP_UHD_1: This is a frontend tuner device that interacts with the physical hardware.

In this case, this instance will be the abstraction of the USRP registered in the Device

Manager. The frontend tuner device allows to configure radio parameters (RX/TX mode,

center frequency, sample rate…) as shown in Figure 4.24, where the USRP is set in RX

mode, center frequency to 406.001 MHz and sample rate to 384 kHz.

• DataConverter_1: This is a REDHAWK core component that transforms input data

format into another data format. In this case it is used to change the USRP output

dataShort into dataFloat.

• epirb_demodulator_1: This an instance of the component described in section 4.3.1.1.1.

• epirb_decoder_1: This is an instance of the component described in section 4.3.1.1.2.

• message_dispatcher_1: This is an instance of the component described in section 4.3.1.3.

message_dispatcher/

├── build.sh

├── cpp







│ ├── message_dispatcher_base.cpp

│ ├── message_dispatcher_base.h

│ ├── message_dispatcher.cpp

│ ├── message_dispatcher.h



├── message_dispatcher.prf.xml

├── message_dispatcher.scd.xml

├── message_dispatcher.spd.xml

├── message_dispatcher.spec

└── tests

└── test_message_dispatcher.py


76

Figure 4.23 EPIRB waveform block diagram.

Figure 4.24 Frontend tuner device configuration for the EPIRB waveform.

4.3.2.2 AIS waveform

Figure 4.25 shows the block diagram of the AIS waveform. This waveform is composed by five

components and one frontend tuner device:

• USRP_UHD_1: This is a frontend tuner device that interacts with the physical hardware,

as it was described in the previous section. Figure 4.26 shows the radio configuration for

this waveform: RX mode is set for the USRP, center frequency is set to 162 MHz and

sample rate to 200 kHz.

• DataConverter_1: This is an instance of the REDHAWK core component that transforms

input data format into another data format. In this case it is used to change the USRP

output dataShort into dataFloat.

• ArbitraryRateResampler_1: This an instance of the REDHAWK core component that

performs a resampling process to the input signal. The output signal will have the desired

sample rate. In this case this component is needed because the minimum sample rate that

can be set in the USRP is 200 kHz and the AIS demodulator component works at 96 kHz.

• ais_demodulator_1: This an instance of the component described in section 4.3.1.2.1.

• epirb_decoder_1: This is an instance of the component described in section 4.3.1.2.2.

• message_dispatcher_1: This is an instance of the component described in section 4.3.1.3.


77

Figure 4.25 AIS waveform block diagram.

Figure 4.26 Frontend tuner device configuration for AIS waveform.

4.3.3 REDHAWK node

REDHAWK nodes are Device Manager instances running in the SCA domain. In other words,

they are a set of devices and services that the domain can use as resources to assign components

from the waveforms. Nodes are completely defined by a Device Configuration Descriptor (DCD)

XML file.

The Device Manager uses the information contained in the DCD file to deploy, configure and

interconnect devices and services in the host computer. If a waveform is launched by the Domain

Manager, the involved components will be assigned to devices in the node.

This project requires a node to associate the two hardware devices used by the SDR, the PC and

the RF frontend (Figure 4.27):

• General Purpose Processor (GPP): this is the main device in the node. It is the

representation of the computer processor, which will be assigned for processing tasks for

each component in the waveform.

• USRP: this is the RF hardware device that is going to be configured to receive samples

from the desired signals during the execution of each waveform. It is important to define

the physical USRP via serial number and USRP model to ensure that the node registers

the device that we want to use.


78

Figure 4.27 Node GPP and USRP devices.


79

5 Results

In this chapter the results from executing both AIS and EPIRB waveforms are going to be

presented.

Firstly, the selected set-up for testing is explained. The decoding results are displayed both in the

terminal output and on a map through a Centum’s proprietary framework which is able to

deserialize and visualize Protobuf messages.

5.1 Set-up for testing

The set-up displayed in Figure 5.1 contains the following involved elements:

1. Personal laptop: This is the host PC which runs the SCA system designed and

implemented in REDHAWK. Firstly, it is booted the SCA domain and the REDHAWK

node via the binary nodeBooter and then it launches both waveforms (not at the same

time).

2. USRP B210: This USRP is the frontend device in the SCA node acting as receiver. It is

powered via the USB connection with the laptop by a USB 3.0 port. The data stream is

passed through this connection too.

3. USRP N210: This is the USRP assigned to transmit the test signals from both EPIRB and

AIS file samples. This device is not part of SCA, it is used only for testing purposes. It is

powered by an external power supply and the data stream of the test files is sent from the

laptop through an Ethernet connection. The samples are transmitted using the binary

tx_samples_from_file from UHD API.

4. SMA cable: This cable will connect the USRP N210 TX port to the USRP B210 RX1

port.

Figure 5.1 Physical set-up for final tests.


80

5.2 Launching the SCA domain

The SCA domain needs to be launched before to instantiate any designed waveform. REDHAWK

core library has a binary named nodeBooter that allows to launch the desired Domain Manager

and Device Manager at the same time.

In this case, the default Domain Manager that comes with REDHAWK is the selected one to

launch. The Device Manager to be instantiated is the node presented in section 4.3.3.

Figure 5.2 shows the nodeBooter output in terminal. Both GPP and USRP devices are detected

and registered in the domain.

Figure 5.2 Launching REDHAWK domain and node through nodeBooter.

5.3 Results from EPIRB waveform

Once that both domain and node are running, the EPIRB waveform can be launched from the

REDHAWK IDE. Figure 5.3 shows the waveform running in the IDE, where the dataFloat output

from DataConverter_1 is being monitored using the FFT representation of the samples in that

point. It can be observed the moment in which the USRP N210 is transmitting the EPIRB signal

in channel F (406.037 MHz).


81

Figure 5.3 EPIRB waveform running in REDHAWK IDE. The bottom graph is the FFT of the dataFloat output from DataConverter.

This signal is correctly detected and decoded by the EPIRB waveform as it is depicted in Figure

5.4. Also, as it was commented in section 4.2.1.3 and 4.3.2.1, the decoded information is serialized

in a Protobuf message which is sent through a socket to other system in the network.

Centum RT has developed a framework named Sensor Control System (SCS) which is able to

understand Protobuf messages from the description files commented in section 4.1.2 (Figure 4.2

and Figure 4.3). This framework gets the decoded messages from EPIRB and AIS waveforms and

represent them in a web-based graphic interface that uses Open Street Map (OSM) [29] layers to

draw local maps.

Figure 5.5 shows the EPIRB decoded message details. It can be checked that the serial number

and the operation mode are the same as the depicted in Figure 3.20 and Figure 4.13.


82

Figure 5.4 Terminal output in which EPIRB signal is being decoded by the EPIRB waveform.

Figure 5.5 SCS web console. EPIRB decoded message details.

5.4 Results from AIS waveform

The AIS waveform can be launched in the same way as the EPIRB waveform. Figure 5.6 shows

the waveform running in the IDE, where the dataFloat output from ArbitraryResampler is being

monitored through the FFT representation of the samples in that point. The FFT represent the

exact moment in which the USRP N210 is transmitting the AIS signals and a burst from AIS-1

channel (161.975 MHz) is detected. Figure 5.7 shows multiple AIS bursts being decoded.


83

Figure 5.6 AIS waveform running in REDHAWK IDE. The bottom graph is the FFT of the dataFloat output from

ArbitraryResampler.

Figure 5.7 Terminal output in which multiple AIS signals are being decoded by the AIS waveform

As in the case of EPIRB, SCS can represent AIS Protobuf messages in the web console as showed

in Figure 5.8. This figure shows details for the MMSI 263528000, the same vessel decoded in the

validation sections (Table 3.13 and Figure 4.16).


84

Figure 5.8 SCS web console. AIS decoded message details for MMSI 263528000.


85

6 Conclusions

In this master thesis, the design and implementation of an SCA-based SDR system to detect and

demodulate maritime distress signals (EPIRB and AIS) has been developed.

To achieve this goal, the study of multiple technologies (as SCA and SDR) and radio maritime

signals (EPIRB and AIS) has been carried out. This was an important step before undertaking

the system-level design of all the architecture that has been explained.

The use of MATLAB in the component design process has been critical for analyzing both

EPIRB and AIS real signals. This has made it possible to carry out the conditioning of the

signals before their detection and demodulation.

In this step, it has seen how important it is to correct the phase error introduced by frequency

deviation between TX and RX because when we are working with real RF devices, local

oscillators are not synchronized with each other. If this correction is not made before the

demodulation stage, the component will not work as expected.

Additionally, the study of each standard ( [1] [4]) has been essential to understand the

characteristics of the signals (frequency of each channel, timings, data formats…) and their

coding process. This has allowed to design the EPIRB decoder in the implementation stage and

has permit to create methods to generate the correct NMEA1803 sentences in the AIS part.

Furthermore, for the implementation stage, the study of open-source libraries has been carried

out. In this respect, Liquid-Dsp with a wide range of easy-to-use API functions, has proven to

be an excellent choice for implementing C signal processing designs.

The samples of the EPIRB and AIS signals, captured with the aid of the USRP, have been

useful to validate the designed and implemented components. It has been proven the decoding

results in each part were correct and met with the data displayed in the physical EPRIB beacon.

For the AIS part, the MMSI decoded could be entered in maritime tracker web to check if the

vessel does exist.

On other hand, the study of the SCA standard has been an essential step to understand all the

architecture from a system-level view. This has allowed to accelerate the learning on

REDHAWK framework and his core elements.

The design of each component has been easier due to the use of REDHAWK IDE, which

implements the necessary interfaces in a simple way. The developer only must worry about the

implementation of the processing element to be wrapped.

Finally, the correct functioning of the system has been demonstrated. The two designed

waveforms have been able to decode the input signal without problems and the results have

been displayed on an external web-based interface from the SCS framework. In this final stage

it was possible to highlight the utility of Protocol buffers. This is an excellent library that allows

to reduce development time for sharing messages between independent systems.


86

7 Future lines

This project is not considered closed, but it is expected to continue working in this subject.

One of the future lines or lines of improvement is the design and implementation of SCA

components that allow processing AOA-type measurements (Angles of Arrival) in order to

geolocate the signal transmission source.

In the case of the AIS signal, some boats that are carrying out illegal activities sometimes forge

the AIS signal, modifying the actual position or the cargoes declared in the encoded data. These

fake data can mislead the authorities that are monitoring the maritime traffic.

If the SDR system, in addition to monitoring the AIS signals, has a component that can carry out

the AOA of the signal, then the position information can be corroborated. This system would need

an antenna array in which the location of the elements has to be carefully studied in order to get

good AoA measurements.

The AOA measurements can also be useful to track the EPIRB analog signal that is transmitted

by some EPIRB beacons in the frequency of 121.5 MHz.

Finally, another future line or improvement could be the use of the REST-API that REDHAWK

provides to design a control layer in the system. REST is the acronym of Representational State

Transfer, which is a software architectural style that defines a set of constraints to provide

interoperability between computer systems on the internet. This layer could configure

dynamically both RF devices and waveforms in the SCA domain from a remote location.


87

8 Bibliography

[1] International Telecommunication Union, "Technical characteristics for an automatic identification

system using time division multiple access in the VHF maritime mobile frequency band," ITU,

2014.

[2] SOLAS, "Code of federal regulations implementing the AIS provisions," 2002.

[3] GPSD, "NMEA revealed," [Online]. Available: https://gpsd.gitlab.io/gpsd/NMEA.html.

[4] COSPAS-SARSAT, "Specification for COSPAS-SARSAT 406 MHz distress beacons C/S T.001

Issue 3 Revision 14," October 2013. [Online]. Available: https://www.cospas-

sarsat.int/images/stories/SystemDocs/Current/cs_t.001_oct_2013.pdf.

[5] J. H. Reed, Software Radio: A Modern Approach to Radio Engineering, Prentice Hall, 2002.

[6] Pantech Solutions, "Software Defined Radio," [Online]. Available:

https://www.pantechsolutions.net/blog/software-defined-radio/.

[7] Ettus Research, "USRP N210 User manual," [Online]. Available:

https://files.ettus.com/manual/page_usrp2.html.

[8] Ettus Research, "USRP B210 User Manual," [Online]. Available:

https://files.ettus.com/manual/page_usrp_b200.html.

[9] "Ettus Research GitHub repository," [Online]. Available: https://github.com/EttusResearch/uhd.

[10] J. T. N. Center, Software Communications Architecture Specification, San Diego, 2016.

[11] E. Englund, "REDHAWK Eclopse as a Software Defined Radio Development Environment," 2013.

[Online]. Available:

https://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/files/REDHAWK.pdf.

[12] C. R. A. Gonzalez, Design and Implementation of an Efficient SCA Framework for Software-

Defined Radios, Blacksburg, Virginia, 2006.

[13] S. Sayed, Black-box Fuzzing of the REDHAWK Software Communications Architecture,

Blacksburg, Virginia, 2015.

[14] F. d. Vigna, Implementation of a suite of components for Software Defined Radio using an SCA-

compliant framework, 2013.

[15] Joint Tactical Radio System, "Software Communications Architecture Specification version 2.2.2,"

15 May 2006. [Online]. Available:

https://sds.wirelessinnovation.org/assets/sca_version_2_2_2.pdf.

[16] REDHAWK, "REDHAWK Manual - 2.2.6," [Online]. Available:

https://redhawksdr.org/2.2.6/manual/.


88

[17] Object Management Group, "About the Common Object Request Broker Architecture specification

3.4 beta," May 2020. [Online]. Available: https://www.omg.org/spec/CORBA/About-CORBA/.

[18] International Telecommunication Union, "Radio Regulations," ITU, 2004.

[19] International Telecommunication Union, "Transmission characteristics of a Satellite Emergency

Position-Indicating Radio Beacon (Satellite EPIRB) system operating through a low polar-orbiting

satellite system in the 406 MHz band," 1990. [Online]. Available:

https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.633-1-199006-S!!PDF-E.pdf.

[20] European Telecommunications Standards Institute, "Electromagnetic Compatibility and Radio

Spectrum Matters (ERM); Float-free maritime satellite Emergency Position Indicating Radio

Beacons (EPIRBs) operating on 406,025 MHz; Technical characteristics and methods of

measurement," ETSI, 2000.

[21] J. Lilington, "Comparison of Channelisation Architectures," 2003. [Online]. Available:

https://pdfs.semanticscholar.org/f3af/7acf516685ad04b3ebe19eb79db4dc3feb39.pdf.

[22] Electronic Notes, "What is GMSK Modulation - Gaussian Minimum Shift Keying," [Online].

Available: https://www.electronics-notes.com/articles/radio/modulation/what-is-gmsk-gaussian-

minimum-shift-keying.php.

[23] GPSD, "AIVDM/AIVDO protocol decoding," [Online]. Available:

https://gpsd.gitlab.io/gpsd/AIVDM.html.

[24] J. D. Gaeddert, "Liquid-DSP webpage," [Online]. Available: liquidsdr.org.

[25] J. D. Gaeddert, "GitHub repository for liquid-dsp," [Online]. Available:

https://github.com/jgaeddert/liquid-dsp.

[26] J. D. Gaeddert, "Documentation for liquid-dsp," [Online]. Available: https://liquidsdr.org/doc/.

[27] Google, "Protocol Buffers developer documentation," [Online]. Available:

https://developers.google.com/protocol-buffers/.

[28] Google, "Protocol Buffers GitHub repository," [Online]. Available:

https://github.com/protocolbuffers/protobuf.

[29] Open Street Map, "Open Street Map documentation," [Online]. Available:

https://www.openstreetmap.org/help.

[30] GNU, "Autoconf manual," [Online]. Available: https://www.gnu.org/savannah-

checkouts/gnu/autoconf/manual/autoconf-2.69/index.html.

[31] GNU, "Automake manual," [Online]. Available:

https://www.gnu.org/software/automake/manual/automake.html.


89

[32] GNU, "Autotools FAQ," [Online]. Available:

https://www.gnu.org/software/automake/faq/autotools-faq.html.

[33] RPM, "RPM Packaging Guide," [Online]. Available: https://rpm-guide.readthedocs.io/en/latest/.

[34] N. Hayes, "Software Communication Architecture," July 2003. [Online]. Available:

https://www.omg.org/news/meetings/workshops/RT_2003_Manual/Tutorials/T2_SCA_Hayes.pdf.

[35] S. M. Biçer, A Software Communications Architecture Compliant Software Defined Radio

Implementation, Boston, 2002.


90

APPENDIX I: REDHAWK components creation concepts

In this section, general concepts about the creation and structure of any generated component in

REHAWK will be commented. This will be useful to understand the REDHAWK component

implementations explained later.

REDHAWK framework can encapsulate basic processing elements as component wrappers. The

creation of these components is carried out using the REDHAWK IDE via the built-in generators

or wizards, which auto-generate much of the code for control and I/O. Figure 0.1 shows the

encapsulation of any processing element into a wrapped REDHAWK component.

Figure 0.1 Encapsulation process for any processing element into an auto-generated REDHAWK component wrapper [16].

The project wizard leads the developer through all the necessary steps to create a component and

the result will be the auto generation of component descriptors, build files, unit test files and code.

The first files generated are the component descriptors. They are a set of three XML files:

• Properties File (PRF): this file contains information about all the properties supported

by the component.

• Software Component Descriptor (SCD): this file contains information about all input

and output ports of the component.

• Software Package Descriptor (SPD): this file describes all the files that are associated

with the component (PRF and SCD files, all binaries and data files).

Later on, code generators will create the following files for building and installing the component:

• build.sh – this file defines a set of process that allows to compile the project.

• configure.ac - a standard Autoconf configuration file. More information can be found in

[30].

• Makefile.am - a standard Automake configuration file. More information can be found in

[31].

• reconf – script used in the Autotools chain [32].

• *component_name*.spec – Provides rpmbuild configuration information. More

information can be found in [33].

Code generators also create implementation-specific code for each component. The files the tool

generates depend on the language selected for this component. For example, for a REDHAWK

component written in C++, these files are generated:


91

• *component_name*_base.h and *component_name*_base.cpp – They provide interface

implementations for the component based on the component’s properties and ports. It is

not recommended to modify these files.

• *component_name*.h – this is the appropriate place where the developer can put header-

related code.

• *component_name*.cpp – this is the appropriate place where the developer can add the

processing behaviour. In this file, three methods need to be implemented:

o serviceFunction() – here resides the core functionality of the component. It is

called recurrently each time the input buffer has any data.

o constructor() – when this function is invoked, properties are initialized to their

default or overloaded state.

• main.cpp – contains the function that is used to create an instance of the component. It is

not recommended to modify this file.

• struct_props.h – contains support classes for struct properties defined in the code-

generation interface. It is not recommended to modify this file.

Lastly, code generator will create a unit test file named test_*component_name*.py for testing

components. This unit test is built in Python through the unittest framework. The developer can

add more tests to check any algorithm in the component.

Design and implementation of a SCA- based SDR system for ...

Documents

Transcript of Design and implementation of a SCA- based SDR system for ...