Sounding Rocket Telemetry Compression · 2017-12-07 · This thesis investigates the design and implementation of a real time, low computational complexity, lossless data compression

Master thesis in Electronics

and Computer Science,

Microelectronics

Sounding Rocket

Telemetry

Compression

Marius Elvegård

Department of Physics

Faculty of Mathematics and Natural

Science

UNIVERSITY OF OSLO

15. May/2016

Abstract

This thesis investigates the design and implementation of a real time,low computational complexity, lossless data compression system for theInvestigation of Cusp Irregularities (ICI) series of sounding rocketsused by the University of Oslo (UiO) at Andøya Space Center (ASC). Theconstructed algorithm is implemented on a FPGA, and a Linux driventesting environment is developed for the design at UiO.

The sounding rocket is a scientific instrument-carrying rocket. Itperformes measurements and experiments while in flight and transmitsthe data to the ground. The transmitted data is measurements from sci-entific sensors measuring: electron density, electric and magnetic fields,the rockets attitude, and housekeeping signals like rocket voltage andtemperature. Its purpose is to perform measurements and collect datafrom irregularities in the plasma in the ionosphere that leads to globalnavigation satellite system (GNSS) scintillations.

The compression algorithm exploits the sensor continuity data andthat frequently sampled data tends to vary little from one measurementto the next. Compression is then achieved by transmitting the value ofthe distance from one measutement to another. With the addition ofcontrol bits in the data stream, lossless telemetry compression can beachieved, with a maximized reconstruction possibility, even in the caseof package loss or data corruption in the transmission.

i

ii

Acknowledgments

The work in this thesis was carried out in the period from September2014 to May 2016, under the supervision of Associate professor PhilippDominik Häfliger at the Research group for Nanoelectronic systems andAssociate professor Ketil Røed at the Electronics group at the Univer-sity of Oslo.I would like to thank Philipp Dominik Häfliger for the opportunity towork on this interesting project. Our discussions regarding compres-sion robustness and the structure of the design have been essential.During the work with my thesis I have learned a lot.I’m very grateful for the help and guidance from Ketil Røed; your knowl-edge and review of my work has been essential and highly appreciated.Senior engineer Espen Trondsen at the Plasma and Space Physics hasassisted me with greatly needed information and insight to the sound-ing rockets and instruments.My fellow students at 333, Ivar, Snorre, Kim and Vegard, thank you foryour support and great fun.Finally, I will tank my wife, Ida. I am incredible lucky to have you inmy life and I would never have managed this without you.

iii

iv

Nomenclature

ADC Analog to Digital Converter

ASC Andøya Space Center

ASC I I American Standard Code for Information Interchange

ASIC Application-Specific Integrated Circuit

C E Compression Encoder

C MOS Complementary metal-oxide-semiconductor

C R Compression Ratio

C RC Cyclic Redundancy Check

D AQ Data Acquisition

DC F I FO Dual Clock FIFO

DSS Digital Sun Sensor

DSS2 Digital Sun Sensor 2

F I FO First In First Out

F PG A Field Programmable Gate Array

GLON ASS Globalnaja navigatsionnaja sputnikovaja sistema

GN SS Global Navigation Satellite System

GPIO General-purpose input/output

GPS Global Positioning System

HPS Hard Processor System

I 2C Inter-Integrated Circuit

IC Integrated Circuit

IC I Investigation of Cusp Irregularities

LI FO Last In First Out

v

vi

LSB Least Significant Bit

LZ Lempel-Ziv

LZ W Lempel-Ziv-Welch

ME MS Microelectromechanical systems

mN LP multi-Needle Langmuir Probe

MSB Most Significant Bit

N R Z Non-return-to-zero

OS Operating system

PAM Pulse-Amplitude Modulation

PC B Printed Circuit Board

PC M Pulse-Code Modulation

PLB Programmable Logic Block

PSD Position Sensitive Device

RLE Runlength Encoding

RN R Z Randomize-non-return-to-zero

RPS Revolutions per Second

R Z Return-to-zero

S AR Successive approximation

SC F I FO Single Clock FIFO

SoC Systen On Chip

SR ADS2 Sounding Rocket Attitude Determination System v2

T DM Time Division Multiplexing

T E Telemetry Encoder

T M Telemetry

U ART Universal asynchronous receiver/transmitter

UiO University of Oslo

V HDL VHSIC Hardware Description Language

V HSIC Very High Speed Integrated Circtuit

V LC Variable-Length Codes

Contents

1 Introduction 11.1 4DSpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Ionosphere . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Global Navigation Satellite System . . . . . . . . . . 21.1.3 GNSS scintillations . . . . . . . . . . . . . . . . . . . . 3

1.2 Background and motivation . . . . . . . . . . . . . . . . . . . 31.2.1 Goals of this thesis . . . . . . . . . . . . . . . . . . . . 4

1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Sensors and Telemetry 72.1 Data sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 ICI Sounding Rockets . . . . . . . . . . . . . . . . . . . . . . . 92.3 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Sounding rocket telemetry . . . . . . . . . . . . . . . . 132.3.2 Data loss . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Multi-Needle Langmuir Probes . . . . . . . . . . . . . . . . . 162.5 E-field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Sounding Rocket Attitude Determintaion System v2 . . . . 19

2.6.1 Magnetometer . . . . . . . . . . . . . . . . . . . . . . . 202.6.2 Gyroscope . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6.3 Sun sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7 Payload daughters . . . . . . . . . . . . . . . . . . . . . . . . . 242.8 Sensor telemetry data . . . . . . . . . . . . . . . . . . . . . . . 242.9 System integration . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Compression 293.1 Compression methods . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.1 Runlength encoding . . . . . . . . . . . . . . . . . . . . 303.1.2 Dictionary based . . . . . . . . . . . . . . . . . . . . . . 313.1.3 Relative compression . . . . . . . . . . . . . . . . . . . 313.1.4 Prediction based . . . . . . . . . . . . . . . . . . . . . . 323.1.5 Statistical compression . . . . . . . . . . . . . . . . . . 333.1.6 Telemetry compression . . . . . . . . . . . . . . . . . . 34

3.2 Compression algorithm . . . . . . . . . . . . . . . . . . . . . . 353.2.1 Signed numbers . . . . . . . . . . . . . . . . . . . . . . 363.2.2 Algorithm robustness . . . . . . . . . . . . . . . . . . . 383.2.3 Changing bit size . . . . . . . . . . . . . . . . . . . . . . 40

vii

Contents viii

3.2.4 Encode1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.5 Encode2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.1 Possible encountering data corruption . . . . . . . . 47

3.4 Digital Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.1 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.2 Sequential system . . . . . . . . . . . . . . . . . . . . . 503.4.3 State machine . . . . . . . . . . . . . . . . . . . . . . . 503.4.4 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4.5 VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.5 Testing Environment . . . . . . . . . . . . . . . . . . . . . . . . 593.6 Development process . . . . . . . . . . . . . . . . . . . . . . . . 603.7 Testing the digital design . . . . . . . . . . . . . . . . . . . . . 62

3.7.1 Hard processor system . . . . . . . . . . . . . . . . . . 623.7.2 Testing system . . . . . . . . . . . . . . . . . . . . . . . 633.7.3 FPGA communication . . . . . . . . . . . . . . . . . . . 64

3.8 Resource usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Results 694.1 Achieved compression . . . . . . . . . . . . . . . . . . . . . . . 70

5 Summary and conclusion 755.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.1.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.1 FIFO multiplexing of data channels . . . . . . . . . . 78

A Pictures 83

B Matlab code 85B.1 Encode 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85B.2 Encode 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87B.3 Decode 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.4 Decode 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91B.5 Encode Prediction . . . . . . . . . . . . . . . . . . . . . . . . . . 93B.6 Decode Prediction . . . . . . . . . . . . . . . . . . . . . . . . . . 95

C Program code 97C.1 VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

C.1.1 Encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . 97C.1.2 FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100C.1.3 Data Handler . . . . . . . . . . . . . . . . . . . . . . . . 102C.1.4 Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . 111C.1.5 Interface module . . . . . . . . . . . . . . . . . . . . . . 113

C.2 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

List of Figures

2.1 PCM encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Sketch of the main sections of a sounding rocket. . . . . . . 102.3 Commutation and frame construction. . . . . . . . . . . . . . 152.4 Uncalibrated raw data from ICI-2 mNLP. . . . . . . . . . . . 172.5 Mounting of e-field and m-NLP. . . . . . . . . . . . . . . . . . 182.6 Uncalibrated raw data from ICI-2 e-field sensor. . . . . . . 192.7 Uncalibrated raw data from ICI-3 magnetometer. . . . . . 202.8 Uncalibrated raw data from ICI-4 gyro. . . . . . . . . . . . . 212.9 Digital sun sensor design. . . . . . . . . . . . . . . . . . . . . . 232.10 Digital sun sensor sun view. . . . . . . . . . . . . . . . . . . . 232.11 Prototype of daughter. . . . . . . . . . . . . . . . . . . . . . . . 252.12 System integration of the compression encoders. . . . . . . 27

3.1 Huffman tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Added signals to the bit stream when a change in bit sizes

is executed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3 Compression frame build up example. . . . . . . . . . . . . . 423.4 Encode1 delta value construction. . . . . . . . . . . . . . . . 433.5 Encode1 frame header example. . . . . . . . . . . . . . . . . . 433.6 Encode1 algorithm flow chart . . . . . . . . . . . . . . . . . . 453.7 Encode2 delta value construction. . . . . . . . . . . . . . . . 463.8 Encode2 frame header example. . . . . . . . . . . . . . . . . . 463.9 Top module encoder with sub modules. . . . . . . . . . . . . 513.10 Encoder module with input and output ports. . . . . . . . . 523.11 FIFO circular buffer . . . . . . . . . . . . . . . . . . . . . . . . 543.12 Single clock FIFO module with input and output ports. . . 543.13 Data Handler module with input and output ports. . . . . . 563.14 Wrapper module with input and output ports. . . . . . . . . 583.15 The Cyclone V DE1-SoC development board. . . . . . . . . . 603.16 Development process. . . . . . . . . . . . . . . . . . . . . . . . 603.17 Test setup of digital design with HPS system. . . . . . . . . 65

4.1 Encode1 bit size distribution after compressing mNLPprobe 1 data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2 Encode2 bit size distribution after compressing mNLPprobe 1 data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

ix

List of Figures x

4.3 Encode1 bit size distribution after compressing e-fieldchannel 2 data. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.4 Encode2 bit size distribution after compressing e-fieldchannel 2 data. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1 Sensor stream example. . . . . . . . . . . . . . . . . . . . . . . 795.2 FIFO multiplexer system. . . . . . . . . . . . . . . . . . . . . . 80

A.1 mNLP FPGA and PCB . . . . . . . . . . . . . . . . . . . . . . . 83

List of Tables

2.1 Scientific instruments carried on the ICI-4 campaign. . . . 72.2 ICI-4 main frame data of one telemetry link. . . . . . . . . . 162.3 ICI-4 campaign data rate for UiO sensors. . . . . . . . . . . 25

3.1 Huffman compression . . . . . . . . . . . . . . . . . . . . . . . 343.2 Binary number representation. . . . . . . . . . . . . . . . . . 373.3 Ones’ complement number representation with positive

and negative numbers. . . . . . . . . . . . . . . . . . . . . . . 383.4 Relative compression values in ones’ complement. . . . . . 403.5 Encode1 flow chart identification. . . . . . . . . . . . . . . . . 443.6 Errors in received data. . . . . . . . . . . . . . . . . . . . . . . 493.7 Encoder input and output connection ports. . . . . . . . . . 533.8 FIFO input and output ports. . . . . . . . . . . . . . . . . . . 553.9 Data Handler input and output ports. . . . . . . . . . . . . . 583.10 Wrapper input and output ports. . . . . . . . . . . . . . . . . 593.11 HPS and FPGA register interfaces. . . . . . . . . . . . . . . . 643.12 HPS commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.13 Cyclone 5 usage and resources . . . . . . . . . . . . . . . . . . 663.14 Max 10M50 usage and resources . . . . . . . . . . . . . . . . 663.15 Cyclone 4 usage and resources . . . . . . . . . . . . . . . . . . 66

4.1 Compression results of raw data. Results are compressedsize relative to uncompressed raw data size. . . . . . . . . . 70

4.2 Average bit size from encode1 and encode2. . . . . . . . . . 71

xi

List of Tables xii

Chapter 1

Introduction

This thesis describes the design and implementation of a low complex-ity, lossless compression algorithm to be used on instrument measure-ments for the Investigation of Cusp Irregularities (ICI) sounding rock-ets. The risk of lost data packages from the data transmission from thesounding rocket to the ground is described in chapter 3.3, and loss ofpackages can make it hard to decompress data. Because of this, thecompression algorithm must assign logic to the compressed data thatgives the ability to decompress the received data even when some datapackages have been lost.

1.1 4DSpace

4DSpace is a research group, involving the Department of Physics,Mathematics and Informatics, at the Faculty of Mathematics and Nat-ural Science, at the University of Oslo. The group investigates the roleof plasma instabilities and turbulences in the ionosphere.

Solar flares eject clouds of electrons, ions and atoms into space. Whenthese high amounts of electric particles come towards the Earth alongits magnetic field and collide with the upper part of the atmosphere, au-rora borealis is created. Scintillations in the ionosphere, a result of theionospheric irregularities, lead to backscattering irregularities of coher-ent HF radars and global navigation satellite systems (GNSS) [1].

Prior to the sounding rockets, the measurements to investigate the iono-sphere were performed with satellites and radars. The need for exper-imental measurements with a better resolution from the ionosphericplasma is achieved by the ICI sounding rockets. These rockets providethe scientists with an in situ exploration of the ionosphere [1]. Spaceweather and its influence on the Earth’s upper atmosphere is beyondthe scope of this thesis, and only a brief introduction to the topic is given.Nevertheless, how the upper atmosphere is affected by space weathermight provide a better understanding of why exploration and an inves-tigation of the ionosphere is of interest. Gerd W. Prölss’ “Physics of the

1

Chapter 1. Introduction 2

Earth’s Space Environment” [2] is a book recommended for readers in-terested to learn more about the topic.

1.1.1 Ionosphere

The ionosphere is a region of the Earth’s upper atmosphere, locatedfrom about 50 km to about 1000 km altitude. In this region, the atmo-sphere gets ionized by radiation from the Sun. Ionization means thatthe atmosphere contains free electrons and ions, and hence is electri-cally conductive. We can divide the ionosphere in the three layers D, Eand F, where the D layer is located below 90 km altitude, the E layeris between 90 km and 170 km altitude, and the F layer from 170 kmto 1000 km altitude [2]. The F layer can further be divided in two lay-ers, F1 and F2. The ionization of the D layer is due to ultraviolet (UV)radiation, the E layer gets ionizated from x-ray and UV radiation, andionization of the F layer arise from extreme ultraviolet (EUV) radiation[3].

Photoionization of thermospheric gases by solar UV and X-ray radiationis the main contributor for making the ionosphere electrically conduc-tive. Solar flares are dependent on solar activity that operates in anapproximately 11-year periodic cycle. Radiation intensity is inverselyproportional to the square of the distance between the Sun and theEarth. The distance from the Sun to the Earth is at its minimum inJanuary and reaches its maximum in July. In addition to the distance,the amount of ionization is also affected by the Suns radiation angle to-wards the Earth. Moreover, both time of day and season will have animpact. As a result, the Southern Hemisphere receives more radiationthan the Northern Hemisphere during the summer, and less radiationthan the Northern Hemisphere during the winter [2].

1.1.2 Global Navigation Satellite System

There are various satellite navigation systems that exist today, andmost known is probably the American global positioning system (GPS).Other examples include a Russian version, globalnaya navigatsionnayasputnikovaya sistema (GLONASS), and systems from Europe, India,China, France and Japan are under development.

GPS navigation is used to determine position. It is used in navigationof ships, flights, cars and even used in handheld devices. GPS providevery accurate position in latitude, longitude and elevation, and velocityand time. The concept of GPS navigation is based on the exactly knownposition of the GPS satellites and time. Each satellite transmits its ownposition and time to base stations on the Earth. With an orbital pe-riod of approximately 12 hours, and more than 24 satellites distributed

3 1.2. Background and motivation

in six orbital planes, there are at any time and at any point on theEarth, at least four visible satellites. A minimum of four satellites arerequired to obtain the three-dimensional position and the correct clockof the receiver [4], and the GPS receiver can use the signals to calculateits velocity from the Doppler shift in the signal.

1.1.3 GNSS scintillations

The ionospheric irregularities result from the Sun’s radiation effectson the ionosphere. Backscattering of high frequency (HF) waves is aresult of the ionospheric irregularities that lead to GNSS scintillations.The GNSS signal from the satellites get exposed to delays and phasefluctuations when propagating through the ionospheric irregularities,which leads to signal degradation. These signal disturbances affectboth navigation and communication satellites, and the consequence ofthe disturbances is difficulties in both navigation and positioning. Thedegradation of the signal is a safty concern for airspace and seafaringactivity in the affected areas. Sometimes the disturbances can be seenas aurora borealis, or more commonly known as northern lights, in highnorthern latitudes.

1.2 Background and motivation

The previous ICI missions have experienced limitations with the mea-surements when using a sounding rocket as a platform for the instru-ments. All measurements are done on the trajectory of the rocket, limit-ing the measurement area. To get a wider measurement area, a systemwhere the sounding rocket carries a sub payload system that containsinstruments is under development. Tresvig and Lindem [5] propose asystem consisting of several sub payloads called daughters that are de-ployed from the rocket when in flight.

To stabilize and keep its trajectory, the sounding rocket spins at 4 to 6revolutions per second (RPS), and the sub payloads uses the centripetalforce to leave the sounding rocket at a speed of approximately 7m/s.Depending on the maximum altitude of the rocket, the active time ofmeasurement for the sub payload system is around 3 minutes.

The sub payload systems perform measurements simultaneously andtransmit the measurements along with its housekeeping data back tothe sounding rocket. The sounding rocket is responsible for the air toground transmission of the data. By the multipoint measurements ob-tained from the sounding rocket and its daughters, the scientists get a3D view of the plasma structures surrounding the rocket from the in-creased amount of instrument data.


The telemetry system, described later in chapter 2, provides no methodof data compression today. Even though the current telemetry systemis capable of transmitting the amount of measurement data from thesounding rockets, the increase of sensors in future ICI missions willproduce much more data than today’s missions.

1.2.1 Goals of this thesis

The purpose of this thesis is to investigate a solution for compressingtelemetry data on board the ICI campaign sounding rockets used forscientific measurements in the ionosphere by 4DSpace at the Universityof Oslo. A compression of sensor data will allow for more data transferfrom the sounding rockets to the ground. A central goal of the algorithmis that a major part of the data retrieved from the rocket should bepossible to reconstruct, even with loss of some of the data packages1.To achieve this, a suitable compression algorithm was selected. Next,methods were developed for increased robustness of the compressionto withstand possible data loss. After developing two solutions for acompression algorithm in Matlab, one of the algorithms was written inVHDL and implemented in a digital design. A testing environment wasconstructed to verify the functionality of the digital design.In sum, the major contributions of this thesis are:

• Develop a compression algorithm in Matlab.• Test the algorithm on data from previous missions.• Implement the algorithm in digital logic on a FPGA.• Develop a testing environment for the FPGA.

An encoder is a device or software that transforms a code from one for-mat to another and encoder is used both in telemetry and in compres-sion. To distinguish the two from each other, I will use telemetry en-coder (TE) and compression encoder (CE) in this thesis.

1.3 Outline

This section presents the content of the proceeding chapters in bullet-points.

Chapter 2 - Sensors and Telemetry• Introduction to sounding rockets, data sampling and telemetry.• A brief overview of the scientific instruments developed by UiO for

the ICI campaign, along with their data consumption.• The integration of the compression encoder into the existing

system.

1Data package is a fixed number of bits that is grouped together.

5 1.3. Outline

Chapter 3 - Compression• An insight to some data compression techniques.• A presentation of the two developed compression algorithms.• Possible problems encountered from data loss and methods of

reconstructing data.• A presentation of FPGA and digital design, followed by the

realization of the compression system and a testing environment.• Resource usage of the digital design and scaling to relevant FPGAs.

Chapter 4 - Results• Achieved compression of the various sensors and an analysis of how

the compression algorithm performs with the individual data sets.• Comparison of the compression results to the performance of two

common compression schemes.

Chapter 5 - Summary and conclusion• A summary of the work presented in this thesis, along with a

critical review of the compression system and suggestions forimprovements.

• Challenges that needs to be dealt with before integrating thecompression encoder is addressed.

• A suggestion for a possible solution to one of the challenges ispresented.


Chapter 2

Sensors and Telemetry

The goal of the ICI rockets is to perform measurements in flightand transmit the measurements to a ground station where they areprocessed further by scientists. Scientific instruments, carried bythe rocket’s payload, performs measurements that are sent to thetelemetry encoder (TE) and transmitted along with housekeeping 1

data. The ICI sounding rocket campaign is a collaboration project, andthe instruments are developed by researchers at the University of Oslo(UiO), Institute of Space and Astronautical Science/Japan AerospaceExploration Agency (ISAS/JAXA), Laboratoire de Physique des Plasmas(LPP) and University of Alberta (UAlberta). Table 2.1 lists the sensorsand developers on the ICI-4 campaign.

Sensor ResponsibilityFixed Bias Langmuir Probe (FPB) ISAS/JAXALow Energy Particle experiment (LEP) ISAS/JAXAmulti-Needle Langmuir Probe (mNLP) UiODigital Sun Sensor (DSS) UiOSounding Rocket Attitude Determintation System v2(SRADS2)

UiO

Electric Field and Wave Experiment (E-Field) UiOSensor for Wideband Magnetic Field Measurement(SwiMM)

LPP

Fluxgate Magnetometer UAlberta

Table 2.1: Scientific instruments carried on the ICI-4 campaign.

The available bit rate on the ICI campaign sounding rockets is 3333.333Kbit/s, and Table 2.3 lists data consumption of the UiOs sensors on theICI-4 flight.

A major part of the available telemetry bit rate is consumed by the datafrom the mNLP and the e-field sensors, while the sensors used for atti-tude determination occupy a great deal of the remaining bit rate. Theattitude sensors are part of the Sounding Rocket Attitude Determina-

1Housekeeping data is internal information about the status and health of therocket.

7

Chapter 2. Sensors and Telemetry 8

tion System V2 (SRADS2), that includes gyroscopes, magnetometer anda sun sensor. The importance of the SRADS2 and its sensors are ex-plained more in depth in chapter 2.6. UiO have the responsibility for 4of the scientific instruments listed in Table 2.1; multi-Needle LangmuirProbe (mNLP), Digital Sun Sensor (DSS), Sounding Rocket Attitude De-termination System v2 (SRADS2) and the Electric Field and Wave Ex-periment (E-field).

An understanding of how the sensor measurements will behave is vital.This is because the compression algorithm, that will be explained inchapter 3.2, exploits the correlation in the data sampled from a sensor.Sensor measurement data that do not fit the algorithm well will re-sult in poor compression of the data set, or even result in an increasedsize of the data set. With raw data from previous ICI campaigns theexpected behavior of the sensors can be studied and tested on the com-pression algorithm. Because the sounding rocket is spinning duringits entire flight, some of the instruments will have oscillating measure-ments, with rapidly alterning measurement values. This is especiallytrue for the measurements from the e-field and the magnetometer, aswill be seen in chapter 2.5 and chapter 2.6.1.

The sample data from the instruments are uncalibrated raw data, butthis does not influence the compression tests. We are only interested ina relative change when testing the compression algorithm on the datasets. The raw instrument measurements are calibrated before they areused by the scientists on the ground.

2.1 Data sampling

Analog signals measured by the payload instruments are continuoussignals. The analog signals are sampled by instruments and quantifiedto a discrete signal that can be processed by the sounding rocket’s digi-tal system.

An analog to digital converter (ADC) is responsible for converting theanalog values to a digital representation. Pulse code modulation (PCM)is a common technique to represent the analog signal as a digital signal.The analog signals are sampled at fixed intervals with pulse amplitudemodulation (PAM). PAM is a method that assigns each sample an inte-ger value within a range set by the number of bits of the ADC. A 16 bitADC will have 216, or 65536 possible values, and the PCM encodes eachinteger value as a 16 bit binary value.

Encoding of PCM signals for serial transmission can be done withtechniques such as return-to-zero (RZ), non-return-to-zero (NRZ) orManchester coding. A RZ coding is a self-clocking signal that returns

9 2.2. ICI Sounding Rockets

to zero between each bit in the data stream2. A NRZ-Level coding onlychange levels in case of bit level change, and is therefore dependent ofanother synchronization technique as well. Some of the versions of NRZcoding are NRZ-Level, NRZ-Mark, NRZ-Inverted and NRZ-Space, withdifferent methods of representing bit change.In Manchester coding, the transition is always in the middle of eachbit period. Manchester coding is a self-clocking PCM encoding likeRZ. Because of the clocking transition in each bit period, Manchesterencoding uses more bandwidth than NRZ encoding [6]. Examples ofthe three PCM encoding techniques transmitting “10110” are shownin Figure 2.1. In Figure 2.1, each of the vertical lines represent a bitperiod and the thick horizontal lines represent a zero level. The PCMcoded signal follows the red line in Figure 2.1, with a logic 1 over thezero level and a logic 0 below the zero level.

Manchester1

0

1 1

0

NRZ-L1

0

1 1

0

RZ1

0

1 1

0

Figure 2.1: PCM encoding.

When an analog signal has been PCM encoded, it is called a data word.The size of a data word depends on the number of bits from its source,and is typically 8 or 16 bits.

2.2 ICI Sounding Rockets

Sounding rockets are scientific rockets with a body that can be dividedinto two parts, the engine and the payload. Figure 2.2 display thesounding rocket build-up. The sensor electronics and the telemetry sys-tem are located in the payload section of the rocket. The cone section in

2A data stream is a sequence of coded data or data packages.


front of the rocket is covering the mNLPs and e-field probes. When therocket reaches enough altitude and the measurements begin, the coneseparates from the rocket. The engine part is a two-stage engine, whichmeans that when the first engine has burned out, it is separated fromthe rocket and the second engine fires. Separation of an engine from therest of the rocket is done with pyrotechnics. The explosive force that iscreated during separation will affect the rocket’s trajectory and stabil-ity if done while the rocket is without any other engine thrust. Thus,only the first stage engine is separated from the rocket, while the sec-ond stage engine is attached to the rocket during its entire flight.

The ICI sounding rockets are spin stabilized rockets that spins with 4to 6 RPS and the spin is created by fins on the rocket.

Motor Payload Cone

Figure 2.2: Sketch of the main sections of a sounding rocket.

Depending on the type of sounding rocket used, the rocket flies in aparabolic trajectory with an apogee3 from 100 km to 1500 km. The flighttime will vary with the rocket’s apogee. After reaching its apogee, therocket is in a free fall state before crashing into the ocean. Figure 2.8show measurement data from the gyro instrument on board the ICI-4rocket. From this yaw plot, one can recognize engine firing, burnout andseparation, and when the rocket re-enters the atmosphere, by lookingat the large spikes in the beginning and the end of the plot.

The sounding rocket used on the ICI-4 campaign was a 10 meter longrocket, weighing 140 kg with a 2.9 meter payload. The rocket hadseveral scientific instruments, and a two-stage solid-fuel engine. Thesounding rocket was launched from Andøya Space Center (ASC) 19.February 2015, with an apogee of about 350 km and a flight time of al-most 600 seconds. It carried two TEs, each with a bit rate of almost 3.2Mbit/s, transmitting measurement and housekeeping data. Data fromthe sounding rocket is transmitted simultaneously by the two TEs, eachresponsible of transmitting data from different sensors. On the groundstation, several antennas are equipped with decoders that receives thetransmissions from the rocket simultaneously, and the received teleme-try data is stored for further processing by scientists.

Tresvig and Lindem propose in [5] a sounding rocket system carryingseveral daughters for future ICI campaigns. The daughters do not have

3Apogee is the point in orbit of an object when it is at its greatest distance from theEarth

11 2.3. Telemetry

any motors giving them speed to control their direction, but use themother rocket’s spin to expel and drift away while performing measure-ments. As mentioned earlier, the rocket has a spin of 4 to 6 RPS, andthe daughters are expected to escape the rocket with a speed at 5 to 7m/s. With an expected travel speed of 7 m/s and 3 minutes of measur-ing time before the daughters re-enters the atmosphere, the daughterswill travel about 1260 meters away from the rocket. In Tresvig andLindem’s system the data rate between the daughters and the motherrocket is 230Kbit/s for each daughter, and each of the daughters willproduce more than 40.4 Mbits of data within the flight time.

On the upcoming ICI-5 campaign, the goal is to have 6 sub payloaddaughters performing and transmitting scientific measurements to theICI rocket. Two of the daughters will carry magnetometers from theUniversity of Alberta, and four of the daughters will carry multi-NeedleLangmuir probes (mNLP) from the University of Oslo.

2.3 Telemetry

The purpose of compressing data is to reduce the size of the data set.Consequently, an overview of how the rest of the data processing systemand data transfer works is necessary. Each of the sensor systems on thesounding rocket produces measurement values of an exact length. Therocket’s telemetry system transmits data packages of fixed length andthe telemetry system expect sensor data of correct sizes at regular in-tervals. Altering the size of the sensor data therefore has an impact onother systems on the sounding rocket.

This section will give a short presentation of telemetry and general datatransmission, followed by how data transmission is done from soundingrockets.

Telemetry is the process of measuring the characteristics of an object,like an aircraft’s velocity, and transmitting the data to a distant recep-tion station where the data is further analyzed. For satellites, aircraftsand rockets, the transmission media may be air or space [7].

Using a separate transmission channel for each data signal is too costlyand impractical. To solve this, the telemetry system group data sig-nals by organizing the data with time division multiplexing (TDM).The TDM method allows several data signals to share a single chan-nel, where each signal only appears in a fraction of time, and all of thedata can be transmitted as one single data stream. At the receptionstation, the data stream is decoded back to its original data signals andthe measurements are then ready for analysis [7].


Bekkeng gives a concise introduction to data transfer and telemetry inhis PhD thesis [8]. A short introduction based on his work will be givenhere. For a deeper understanding of how data transfer and telemetryworks, readers are encouraged to read about the IRIG 106 telemetrystandard online [9].

Data transfer is done in parallel or serial communication. In paralleltransmission, multiple bits are transferred at the same time and oftenrequire a bus. In a serial communication, the data is a stream with onlyone bit at the time. A parallel communication is an advantage whenmuch information needs to be transmitted, with the cost of more wiresrequired for the transmission. Each of the wires represent a transmis-sion channel and using many transmission channels are not applicablefor telemetry.

Usually when data is transmitted on a serial communication channel,a clock signal has to be transmitted along with the data, making it asynchronized communication. The transmitter and receiver shares aclock signal for data transfer synchronization. A communication pro-tocol like the inter-integrated circuit (I2C) is a common synchronizedserial communication for short distances, and uses only two wires forits communication. In an I2C serial communication one of the wires isused for the bit transfer while the other wire is used for the clock signal.In an asynchronous serial communication, no clock signal is transmit-ted along with the data on the serial line. Hence, other methods ofsynchronizing the bits in the data stream are needed. When no sharedclock is applied, the receiver does not know when the transmitted datais coming. Reading the transmitted bits in the data stream at a differ-ent speed than they are transmitted, may lead to errors like reading thesame bit several times or missing some of the bits. To allow for a com-munication without a shared clock, synchronization information needsto be added to the data stream by adding extra bits or by coding datasignals to include the clock signal, as done in Manchester coding.

Protocols may implement error detection in the form of extra bits to re-duce the amount of corrupted data. For the error detection to work, thereceiver must use the same error detection algorithm as the transmit-ter. When the receiver has received data from the transmitter, it usesthe algorithm and compares the result with the error detection bits thatis transmitted along with the data. If the received error detection bitsdo not correspond with the result from the algorithm, the receiver canthen ignore the error, discard the received data or request for a retrans-mission. There are also techniques that allows for the receiver to re-construct the corrupted data [10], but error correction techniques arebeyond the scope of this thesis.

There are several methods for error detection with various complexityand redundancy added to the stream. The redundancy added to the

13 2.3. Telemetry

data stream can take the form of a few control bits or repetitive datasequences. A simle method used to detect errors is to transmit the dataseveral times and have the receiver compare incoming data. By group-ing the data in packages and by transmitting the package, for examplethree times in a row, the receiver can compare the three packages anddetect if an error has occurred. The receiver can then use majority vot-ing and select bits that should be treated as correct. Peterson and Davie[10] describe some of the popular error detection methods in computernetworks. Cylindric redundancy check (CRC) is one of the most commonmethods for error detection, but simpler methods like two-dimensionalparity and checksums can also be applied. In a two-dimensional parity,there are two types of practices, odd and even parity, and they use anextra bit to indicate the number of occurrences of a high or low bit4 in apackage of data.

As an example of a two-dimensional parity error detection, if a packageinside a frame of data transmitted consists of one byte5, an even paritymethod will use the eight bit for parity and the remaining seven for theactual data to be transmitted. If the number of high bits in the byte iseven, the parity bit will be set high, otherwise it will be set low. Now,if the frame6 is built up by four bytes, an extra bit can be added to theframe, indicating even or odd occurrences of high bits within the frame.The receiver will count the number of high bits within each package andframe, and compare its result with the transmitted parity bit.

When data is transmitted on a network, the sender must include thereceivers’ address to the data being sent, and usually every device onthe network is equipped with a unique network address. This overheadis necessary when the transmitted data can be received by multiple re-ceivers but is not intended for everyone. For point-to-point connectionswith only one transmitter and one receiver, an address is not necessaryas is the case for sounding rocket telemetry, explained more in detail inthe next subsection.

2.3.1 Sounding rocket telemetry

The sounding rocket telemetry communication is a simplex7 communi-cation channel, meaning that the rocket can send information to theground, but no data can be transmitted from the ground to the rocketafter launch. Hence, there is no possibility for the ground station to re-quest for a retransmission of the data from the rocket if corrupted datahas been detected, and other methods of reconstructing the data must

4A high bit is a 1 and a low bit is a 05A byte is a set of eight bits6A frame is a packet of data with a synchronizing method that marks the start and

the end of the frame.7Simplex is a one directional communication channel


be carried out.

The PCM encoded data from the sounding rocket is transmitted ona serial communication channel, which requires a clocking signal tobe transmitted along with the data signal. On the ICI-4 campaign,the randomized-non-return-to-zero-level (RNRZ-L) coding was used. ARNRZ-L PCM signal is a self-synchronized signal that is based on theNRZ-L PCM coding method, with an additional randomizer trying toproduce an equal number of 1’s and 0’s in the NRZ-L PCM coded data.The randomizer operation is deterministic, and when decoding the self-synchronized RNRZ-L PCM coding back to its original NRZ-L PCM cod-ing, an equivalent derandomizer is used by the receiver.

All the instruments’ and housekeeping data words that are being sentfrom the sounding rocket shares a communication channel. The sharedchannel requires that the data words are combined into a single datastream. With TDM, several data words can be grouped together andshare a communication channel, and each of the data words occur onlyin portions of the total transmission time.

A commutator8 is responsible for combining the data words into framesthat can be transmitted. Because the data words are placed in a spe-cific order inside the frame, no sensor address or indicator needs to beadded to the data words. When the telemetry frame is decommutatedon ground, the decoder knows exactly where in the frame each sensordata is located.

A synchronizing ID marks the beginning of a frame, and a unique wordsync is added at the end of each frame. This frame information is usedwhen the data is decommutated on ground. Because some of the sensorshave different sampling rates, the corresponding sensor data words willappear more often than data words from other sensors inside the frame.When a sensor data word appears several times inside a frame, the sen-sor is said to be supercommutated. Sensors that require a higher datatransfer are thus supercommutated. Data words that occur less thanonce within a frame, is called a subcommuted data words. Sensors thatappear only once in each frame are called commutated sensors [7].

Figure 2.3 illustrates how a telemetry frame is constructed. The framesynchronization is added between sensor 2 and 1 as a decommutatingreference, which means that the first word in the frame is from sensor1, and that one frame is constructed after one revolution. Sensors 1, 2and 6 are commuted once inside a frame (1:1), while sensor 2 and 4 aresupercommuted and appear two times inside a frame (2:1). Sensor 5have 4 channels and is subcommuted, thus each channel appears onceinside every fourth frame (1:4).

8A commutator is a multiplexer.

15 2.3. Telemetry

TelemetryFrameCommuted

Subframecommuted

Sensor 1 Sensor 3

Sensor 2 Sensor 4

Sensor 4

Sensor 6

Sensor 2

Sensor 5

Channel 1 Channel 2

Channel 4 Channel 3

Frame sync

Figure 2.3: Commutation and frame construction.

It is important to have knowledge about commutation and frame con-struction because this has consequences for how the compressed datadata must appear when it is sent to the sounding rocket’s commuta-tor and telemetry. A telemetry frame is constructed continously, andthe commutator expects sensor data of a fixed size and at a specificrate. Each location in the telemetry frame is reserved for a sensor orhousekeeping data, and each frame consists of a fixed number of bits.Changing the order of appererance of the data inside a frame causesdifficulties for the receiving decoder on ground, as the decoder will notknow what data in the frame that belongs to which sensor.

The main frame information for the ICI-4 campaign is listed in Table2.2, where one frame consists of 142×8 bit words, giving a total of 1136bits in one single frame. The total data rate is almost 3210 Kbit/s, closeto the available bit rate of 3333 Kbit/s. The TE system consisted of twoseparate telemetry links, each responsible for transmitting frames ofdata from different sensors.


Available bit rate 3333.333 Kbit/sUsed bit rate 3210 Kbit/sFrame rate 2893.5 Frames/sFormat rate 45.2 Format/s8 bit Words/Frame 142 bit/FrameFrames/Format 64 Frame/Format

Table 2.2: ICI-4 main frame data of one telemetry link.

Several receiver antennas, equipped with decoders for each transmis-sion link, are tracking the rocket during its flight from ground and col-lect the sent data. This gives the telemetry link some redundancy incase some of the antennas should lose any packages, or lose track of therocket.

2.3.2 Data loss

When transmitting data with a one-way only communication, the risk ofdata loss is present. On the ICI campaigns prior to the ICI-4, the dataloss experienced from each of the two TE systems on ground were al-most 20%, but most of the data could be reconstructed by rebuilding thedata from all the receiving decoders. The main reason for data loss onthe earlier ICI campaigns was old equipment on the ground. Moreover,some of the data were lost due to equipment writing too slowly to a stor-ing device. Another cause of data loss were old and poorly terminatedtransmission lines between the receiving antennas and the decoders.

The receiver system has now been upgraded, resulting in a remarkablereduction in data loss. On the ICI-4 campaign, the data loss were inthe range of parts per million (ppm) 9. Although the data loss has beenreduced to a fraction, the danger of data loss persists, as any loss couldmake a decompression of data hard or even impossible without any im-plemented redundancy.

2.4 Multi-Needle Langmuir Probes

The multi-Needle Langmuir Probes (mNLP) measures the electron den-sity in the ionosphere, and are designed and built at UiO. The in-strument consists of 4 probes with a diameter of 0.51mm and 25mmlength. The probes are biased at different voltages, and measures acurrent range from 1n A to 1µA and with an electronic density range ofne = 109m−3 to ne = 1012m−3 [11]. Figure 2.5 shows the mounting of themNLP on the knee-joints on the e-field booms, located in front of therocket.

91 ppm = 0.0001%.

17 2.4. Multi-Needle Langmuir Probes

The measurements of the plasma with a Langmuir probe is done by bi-asing the probe to a potential, relative to the potential of the plasma,and measure the current collected [11]. The relationship between thebias voltage of the probes and the square of the collected current is usedto calculate the electron density ne [12].

ne =√

k∆(I 2

c )

∆V(2.1)

The formula 2.1 gives the expression for electron density where the con-stant K is me /2q(q2r l )2, me the electron mass, q is the electron charge, ris the radius of the cylinder, l is the cylinder length, ∆(Ic )2 is the differ-ence in collected probe currents and ∆V is the difference in probe bias[12][13].

In Figure 2.4, mNLP measurement data from the 4 biased probes onthe ICI-2 sounding rocket is shown. The signals from the four probesare changing rather slowly for the lower biased probes, and moderatefor the probe biased on the highest voltage. The signal has no largespikes, except at the end of the measurements. For this launch, thesampling rate for the mNLP was set to 5787Hz and the total flight timewas 574 seconds. The collected currents by the probes are convertedto voltage, filtered and digitized, before transmitted to the rocket’s TE.The digitizer is a 4 channel 16 bit successive approximation (SAR) ADC,capable of sampling all 4 channels simultaneously [12].

Figure 2.4: Uncalibrated raw data from ICI-2 mNLP.

When the rocket flies through the plasma in the ionosphere while per-forming its experiments, the electron density in proximity of the rocket,measured by the mNLP, will tend to be uniformly distributed. Although


the rocket flies with a spin through the ionized plasma, the sensors mea-surement will not change noticeably because of the rocket spin.

2.5 E-field

A measurement of the electric field in the ionosphere is performed bythe e-field instrument. This measurement give informatin about theelectric field’s direction and size.

The ICI-4 sounding rocket was equipped with 4 probes, mounted at theend of the instrument booms in front of the rocket, as seen in Figure2.5. About 60 seconds after takeoff, the nose cone ejects and the boomsare extended from the rocket by centripetal force. The e-field sensorsdelivers their measurements on 6 channels. Two of the channels providedifferential measurements from two opposite mounted probes. Theadvantage with differential measurements is that the sounding rocket’sbody is not needed as a a voltage reference [14]. The remaining fourchannels provide single ended measurements of the electric field.

m-NLPE-field

m-NLPE-field

m-NLP

E-field

m-NLP

E-field

Payload

Figure 2.5: Mounting of e-field and m-NLP.

E-field instrument data from the ICI-2 campaign is seen in Figure2.6. Although the measurements stay within a constant range, thesignals are of an oscillating nature with swiftly changing values. Theoscillating signal arise because the electric field is a vector field, andwhen the e-field sensor is aligned at various angles relative to theelectric field, because of the rocket spin, its measurements will varyand look oscillating.In the beginning of the flight, the nose cone on the rocket is still attachedand the booms holding the e-field sensors are not yet unfolded. In Figure2.6, this captivity is seen from the areas before the measurement datastarts to oscillate, in the beginning of the plot.

19 2.6. Sounding Rocket Attitude Determintaion System v2

Figure 2.6: Uncalibrated raw data from ICI-2 e-field sensor.

2.6 Sounding Rocket Attitude DetermintaionSystem v2

The Sounding Rocket Attitude Determination System v2 (SRADS2) in-strument combines internal and external 3-axis magnetometers, a dig-ital sun sensor and a MEMS 10 3-axis rate gyroscope. With the use ofthese sensors, SRADS2 can determine the orientation of the soundingrocket so that the scientific measurements can be studied in a referenceframe related to the Earth, instead of to the rocket. Because the datafrom the SRADS2 are used when reconstructing the data from the sci-entific instruments, the processing of the SRADS2 data through conver-sions and algorithms are performed on the ground. The transmissionof data from the rocket to the ground station reduces the on-board com-putational complexity from the calculations in the SRADS2. Because ofthe complex calculations involved in determining the orientation of thesounding rocket, the data have to be absolute and compressed withoutany loss of information.

Attitude determination is performed with inertial and reference sen-sors. Inertial sensors, like accelerometers and gyros, are used for mea-suring movement without an external reference. Sun sensors and mag-netometers are sensors that measures movement relative to a knownvector [15].

10MicroElectroMechanical Systems


2.6.1 Magnetometer

A magnetometer is a vector sensor, and the strength and direction ofa magnetic field can be found with such an instrument. Magnetome-ters as attitude sensors in spacecraft are common, and magnetometersbenefit from their good reliability, low weight, ability to operate over awide temperature range, and the lack of movable parts and low powerconsumption [16].

The Earth’s magnetic field is not completely known, and this limits theaccuracy of a magnetometer used as an attitude sensor. When movingaway from the Earth, its magnetic field strength is reduced by 1

r 3 , wherer is the distance to Earth. At distances above a couple of thousand kilo-meters from the Earth, the magnetic field from the spacecraft will startto dominate, but this is not a problem when magnetometers are used insounding rockets operating in low-earth orbit [16].

To be able to determine the orientation of the rocket, the magnetometerdata have to be compared to a reference model [14]. With analyses ofmagnetic fields all over the world, a mathematical model creates a ref-erence model that is used for comparison.

Magnetometer instrument data from the ICI-3 campaign is plotted inFigure 2.7. The results from the magnetometer clearly show how themeasurements are affected by the rocket spin, giving measurementswith an oscillating appearance. This oscillation is caused by the sound-ing rocket spinning while flying through the vector field.

Figure 2.7: Uncalibrated raw data from ICI-3 magnetometer.


2.6.2 Gyroscope

A minimum of 3 gyroscopes (gyros) are needed for the attitude determi-nation system, and Bekkeng, Booij and Moen [15] suggests the use ofcommercial, low cost MEMS gyros. The 3-axis STIM210 gyro modulefrom Sensonor was chosen for the SRADS2.

A gyro is an instrument that is useful for measuring orientation, and itoperates according to the conservation of angular momentum. Threetypes of gyros are being used on spacecrafts: Rate gyros and rate-integrating gyros are used for measuring the change in spacecraft orien-tation, while control moment gyros are used to generate control torquesto control the orientation of the spacecraft [16].

Three gyros are needed to get a three dimensional orientation in space,and they must be mounted in a strap down mode11 orthogonally rel-atively to each other [15]. When the gyros are firmly attached to therocket, depending on the type of gyro used, an angular rate or displace-ment of the rocket can be registered when a change in orientation oc-curs.

Figure 2.8: Uncalibrated raw data from ICI-4 gyro.

The gyro measures the rocket’s pitch, roll and yaw12, and measurementdata from the ICI-4 campaign are shown in Figure 2.8. During launch,the rocket experiences a lot of vibrations and the vibration noise aremeasured by the gyros. For the most of the flight, the yaw axis has arather constant angular velocity, while the pitch and roll axes will ex-perience effects from nutation13. On re-entering the atmosphere, the

11In a strapdown mode the gyro is mounted tightly to the object being measured.12Pitch, roll and yaw are lateral, longitudinal and vertical axis13Nutation is a nodding motion in the rotation axis.


rocket will start rotating around the pitch or roll axis, rather than theyaw axis.

The first large spike in Figure 2.8 is from when the first engine hasburned out, and the second spike is from when the second engine hasburned out. After this, the rocket is in a free-fall state with no enginetrust and the measured values from the three-axis gyro are stable formost of the flight. When reentering the atmosphere, the gyro begin tomeasure the change in rotation, and we get large spikes in the measure-ments again. The absolute value of these events might not be crucial,but being able to identify them is, because they provide informationabout the flight and when the measurements of interest begins. Thisinformation can be of importance when the data are further processedon ground.

2.6.3 Sun sensor

Several reference sensors are available for attitude determination. Allsensors have both advantages and disadvantages. The most accuratereference sensor is a star sensor, but this type of sensor is too expensiveand complex for a low cost system such as the ICI sounding rockets. AGPS has a slow update frequency and civil receivers are subjected torestrictions on velocity and altitude accuracy. The horizon sensor com-pares the thermal radiation from the Earth or the Moon with emptyspace. An uncertain transition point between the Earth and emptyspace, due to the Earth’s atmosphere, limits the accuracy of the hori-zon sensor. Thus, neither a GPS nor a horizon sensor is suitable forattitude determination on the ICI sounding rockets. Instead, Bekkeng,Booij and Moen suggest the use of a digital sun sensor (DSS) [15].

Sollien [14] suggests the use of a lens-less pinhole line camera in hiswork with the development of a DSS for the prior SRADS. Informationabout the sun angle, spin frequency, coning frequency and coning anglecan be acquired from the DSS. The DSS in Figure 2.9 is based on Sol-lien’s work and the DSS has a field of view of approximately 120◦, with aposition sensitive device (PSD) consisting of a high speed CMOS lineararray with 2048×1 pixels. The solar angle is calculated by the detectionof the light on the PSD. The formula is given in Equation 2.2, whereL = XC −XM .

α= t an−1(

L

d

)(2.2)

Only wavelengths λ= 780nm to λ= 1100nm are detected by the PSD, dueto the filter in front of the pinhole.


d

Light sensitive area

CMOS line camera

PinholeFilter

Sun ray

α

XM XC

Figure 2.9: Digital sun sensor design.

The sun sensor is mounted with the pinhole opening in parallel to therocket’s spin axis, as shown in Figure 2.10. During the flight, the spin-stabilized rocket keeps a spin of 4 to 6 RPS around the roll axis. Hence,the sun sensor only sees the sun for a short time and will most of thetime have nothing to report.

Rotation

Figure 2.10: Digital sun sensor sun view.

On the ICI-4 campaign, the rocket was equipped with two digital sunsensors. The new DSS2 was intended for the SRADS2 system, whilethe older DSS was used on the previous SRADS. The use of the DSS2for the SRADS2, which is a two-dimensional sun sensor that can makethe calibration of the system easier is presented by Furevik [17].

Unfortunately, no sensor data from the sun sensors were available forexploration and testing because the rocket was launched right beforemidnight, and did not reach enough altitude to see the sun.


2.7 Payload daughters

Satellites and ground-stationed antennas were used for measurementsprior to the use of ICI sounding rockets as instrument carrying devicesperforming measurements. The sounding rockets made in situ measure-ments possible by performing the measurements directly in the iono-sphere and providing a better resolution of the observations [1]. Be-cause the sensors are mounted to the rocket, measurements are per-formed in the proximity of the rocket and its trajectory, narrowing themeasuring range. Payload daughters represent a further improvementto the scientific measurements. A multipoint measurement, giving a3D view of the plasma, is realized with instrument carrying daughtersthat are deployed from the sounding rocket during its flight [5]. Thedaughters are simultaneously performing measurements and transmit-ting data to the sounding rocket.

A prototype of one of the daughters are shown in Figure 2.11. The proto-type’s dimensions are 43 mm height and 100 mm diameter, which limitsthe available space for on-board electronics and sensors. In the next ICIcampaign flight, the sounding rocket is planned to be equipped with sixdaughters, where four of them will be carry mNLP from UiO and twowill carry magnetometers from UAlberta. A daughter has enough roomto carry four mNLPs, but whether the daughters shall be equipped withfour, three or only one probe is yet indecisive. A decision awaits a testflight during the summer of 2016.

The amount of data per probe, producing 2×8 bit words with a 1k sam-ple/s, will be in the order of 16 Kbit/s. With four daughters, carryingfour mNLPs each, the amount of data from the mNLP system alone willincrease with 256 Kbit/s. The increased data amount will come in addi-tion to the data produced by the system mounted on the sounding rocketalready.

2.8 Sensor telemetry data

As already mentioned, many of the sensors will have measurement datathat have an oscillating appearance because of the rocket’s spin rate.From the plots of the sensor data in the previous sections, we see thisoscillation produces a rapidly changing measurement data for many ofthe sensors.

The amount of data received from the instruments depend on the in-struments sample rate and the size of the words produced. The amountof sensor data on the ICI-4 campaign is listed in Table 2.3. A major partof the data is produced by the mNLP and the e-field measurements.Consequently, a good compression of these signals is important to free

25 2.8. Sensor telemetry data

Figure 2.11: Prototype of daughter.

space for more data. With future ICI campaigns carrying even moreof the mentioned instruments, or with an increased sample rate, theamount of data created can get very large.

Sensor system Commuted Data/frame Data/smNLP Super 3:1 384 bit/frame 1.06 Mbit/sE-field Super 6:1 576 bit/frame 1.59 Mbit/sMagnetometer Sub 1:4 32 bit/frame 0.088 Mbit/sGyro Sub 1:4 16 bit/frame 0.044 Mbit/sDSS2 Super 2:1 64 bit/frame 0.176 Mbit/sDSS Super 2:1 32 bit/frame 0.088 Mbit/s

Table 2.3: ICI-4 campaign data rate for UiO sensors.

The ICI-4 campaign had a total of eight mNLPs, producing 2 × 8 bitwords per sample. The mNLP system was supercommuted three timesin the main frame of the telemetry, which produces a total of 384 bit-s/frame from the eight probes. With a frame rate of 2893.5 frames/s, theprobes all together produced almost 1.06 Mbits/s. In addition, two wordsproviding probe DC bias voltages are commuted once in a frame, adding16 bits extra per frame, which sums up to approximately 45.2KBits/s.

The e-field sensor system was supercommuted six times within themain frame on the ICI-4 campaign, and the system produced twelveeight bit words, giving a total of 12× 8 bits ×6 = 576 bits in each mainframe, and almost 1.59 Mbits/s.

On ICI-4, the SRADS2 had two 3-axis magnetometers, one internal andone external. Each of the magnetometers produced 2×8bit words, andwere supercommuted two times in the main frame, producing a total of2×2×8 bit ×2893.5 frames/s = 92592 bit/s, or almost 90.5Kbit/s.


The gyro was subcommuted once in each frame on the ICI-4 campaign,producing 2× 8 bit words. Data sent from the gyro to the main framecame from the gyro’s own subframe. Each of the gyro’s 4 sensors ap-peared in every fourth main frame.

Both of the digital sun sensors on the ICI-4 flight were supercommutedtwo times inside one frame. However, the DSS2 produces twice theamount of data compared to the DSS. DSS2 produces 8× 8 bit wordswhere the DSS produced 4×8 bit words in each frame.

2.9 System integration

The instrument cards on the ICI sounding rockets are stacked togetherin the payload section of the sounding rocket. Each of the sensor sys-tems on the sounding rocket is connected to its own instrument card,which contains an ADC for each of the sensor channels, a Cyclone 4FPGA14, and other electronics needed to operate the sensor instrument.A picture of the electronics card for the ICI-4 mNLP system, with eightADCs and a Cyclone 4 FPGA, is attached in appendix A.

The compression encoder (CE) must be integrated in the existing systembetween the sensor data acquisition15 (DAQ) and the commutator con-structing the telemetry data frames. After the sensor DAQ has digitizeda measurement into a binary word, the CE can compress the measure-ments before they are gathered into frames and transmitted by the TE.

The earlier review of the sensors and their sample data, shows thereare big differences in the data sets from the various sensor systems,and also from the various measurement from each sensor. This is mostobvious in the plot for the mNLP in Figure 2.4, where the four probeshave signals that consists of different magnitude.

The CE system, described in chapter 3.2, gains its compression fromexploiting the continuity of the instrument measurements. Because ofthe variations in magnitude, an attempt to use one encoder to compressmultiple sensor channels can lead to poor compression results. Each ofthe sensor channels should thus have their own CE to ensure the bestachievable compression, though this can raise other concerns regardingincreased power use and available FPGA resources.

In Figure 2.12, an arbitrary sensor with four measurement channels isdrawn along with corresponding ADCs and a FPGA with a MUX. The

14Field-programmable gate array is a device that contains programmable logic15Data acquisition is the process of sampling and digitizing analog signals

27 2.9. System integration

MUX is responsible for the TDM of the four channels, giving the com-mutator the sensor data in a serial format.The four ADCs are digitizing the sensor measurements to words of fixedlengths, and transmit the digital sample values to the FPGA. On theFPGA, the four CEs receives the sample values and compress the datain packages of the same length as the ADC produces, and passes it tothe subsequent system on the FPGA. The system in Figure 2.12 is asimplified illustration, as the real FPGAs and the instrument cards willcontain more digital modules and electronics.

SENSOR ELECTRONICS CARD

CYCLONE 4FPGA

ADC

ADC

ADC

ADC

SEN

SOR

Ch1

Ch2

Ch3

Ch4

CE 1

CE 2

CE 3

CE 4

MU

X COMMUTATORAND

TELEMETRY

Figure 2.12: System integration of the compression encoders.

A system that replaces the MUX should be introduced between the CEsand the commutator gathering the data. This system is needed becauseof the non-deterministic behavior of the compressed data stream. Thedesign and integration of such a solution is beyond the scope of thisthesis, but a suggestion is provided in the final chapter. A module thatsynchronizes the incoming data with the CE system, to ensure that sig-nals are stable while being read by the CE, must be added in front ofthe CE. Although the synchronizing module is not part of this thesis,knowledge of the need for such a module is an advantage when testingthe CEs and when integrating the CEs to the sounding rocket.

For a sounding rocket with a flight time of no more than 10 minutes,power consumption should not be a concern, but the limited space areafor on-board electronics can be of concern when selecting system chips.The cost of integrating one CE in a digital design is summarized inchapter 3.7.


Chapter 3

Compression

Data compression is the process of encoding a data set into a smallerdata set. The compression can be performed either lossless, meaningthat the compressed data can be reconstructed back to its exact originalform, or lossy, where the compressed data is an approximation of theoriginal data. The compression is performed by an encoder and the de-compression is performed by a decoder [18]. To distinguish the teleme-try encoder and the compression encoder, the compression encoder isdenoted CE, as stated in the introduction.

A measurement of how much information that is encoded in a messageis called entropy in Information Theory, and the higher the entropy ofa message, the more information it contains [18]. The entropy metricwas developed by C.E.Shannon and is defined as the average amount ofinformation per source output [6].

Lossy compression can be suitable for many applications, e.g. compres-sion of sound, images and video, where some degradation of the decom-pressed data is negligible for later use. When the compressed data isreconstructed, some of the information will be lost and the data will bean approximation of the original data. A selection of popular lossy com-pression products are JPEG for image compression, MPEG and H.261for video compression, and MP3 for compression of sound. Lossy com-pression ususally outperforms lossless compression in compression ra-tio (CR) 1 because lossy compression have the possibility of removingredundant information.

In other applications where no degradation of the data is tolerated, loss-less compression is applied. A degradation of data reduces the accuracyand can be significant, for instance when used in precise calculations,satellite telemetry or on text. In a compressed text file, a lossy compres-sion could make the decompressed text file hard to read; words couldchange meaning or be impossible to understand because letters couldbe missing or changed. In a scientific experiment, where the scientists

1Compression ratio is the compressed size relative to the uncompressed size

29

Chapter 3. Compression 30

might not know in advance what they are looking for in the data set, alossy compression might remove interesting information.

In the process of compressing data one looks for redundancies in thedata set in the form of patterns or structures. By reducing the num-ber of patterns, or removing them fully, a compression of the data set isachieved. Only non-random data sets can be compressed, because ran-dom data sets contain no patterns [19]. There is no universal techniquefor compressing data and the technique used depends on the data to becompressed. But, the general technique is to assign short codes to thecommon events and longer codes for the rare events.

The complexity, time consumption and CR differs between the variouscompression techniques. Therefore, an a priori knowledge of thedata is important when selecting a compression method, i.e. whetherthe data set is text, sound, an image, a wave form or any othermeasurement. Each type of data will have different structures, patternsand redundancies that are exploited when the algorithm compresses thedata. An image may have repetitive pixel colors, while a sample valuein a sound wave might be close to its neighboring sample values.

3.1 Compression methods

Because lossy compression is unsuited for our telemetry data, only loss-less compression algorithms are explored in this thesis. Lossless com-pression attempts to encode a large data set of information with the useof less bits. Compression methods based on suppression of repetitive se-quences, dictionaries with substitution, relative in number sequences,prediction and statistics are some of the many techniques used, and Iwill only present some of the techniques that are most relevant for thecompression method developed in this thesis. Moreover, some of thepresented compression methods will need separators between the codedwords to make it possible to distinguish the compressed information.This separation is especially important when the result is compressedas a binary stream; however, it will not be addressed in the presenta-tions given here.

3.1.1 Runlength encoding

Runlength encoding (RLE) is a compression method that operates bysuppressing repetitive sequences. Instead of sending a sequence ofidentical characters, the method sends one character followed by thenumber of repetitions. For example the input stream “AAAAAABB-BCBBBBBAAAAAAA”, consisting of 22 characters, would be encodedto “A6B3CB5A7”, consisting of 9 characters. The repetitive sequencemust consist at least 3 characters to achieve compression. A CR of

31 3.1. Compression methods

922 ×100 ≈ 41% was achieved by compressing the string in this example.

3.1.2 Dictionary based

The Lempel-Ziv-Welch (LZW) compression method uses dictionariesand substitutes a string sequence with different characters. In a textfile, many words, phrases or syllables may occur several times, and thisrepetition is exploited by the dictionary based compressors. The dictio-naries can be either static or adaptive, and the dictionary from a staticdictionary compression will have to be transmitted along with the com-pressed data [18]. In an adaptive dictionary based compression method,the dictionary is created while encoding the data sequence. The adap-tive dictionary based algorithm has an empty dictionary in the begin-ning of the compression. The first input to the compressor is stored inthe empty dictionary and written to the output of the compressor. Thedata on the output of the compressor can be written to a file that is con-tinuously groving as data is written to it, or the output can be writtento a data stream. In the dictionary, a token is assigned to the data. Thecompressor keeps building up the dictionary while reading the input,and if an input matches data in the dictionary, the corresponding tokenis written to the output instead. The more frequent the occurrence, andthe longer the match of input data with the dictionary data, the betteris the gained CR.

When decompressing the data, the compression decoder tries to matchsequences in the data with the tokens stored in the dictionary. If amatch is found, the token is replaced with the data stored in the dictio-nary. The size of the dictionary varies among the compression methodsand will affect the achieved CR. Because the compressed data will lookrandom [19], tokens from the dictionary added to the compressed datamust be unique to be distinguished from the rest of the data that buildsup the text.

3.1.3 Relative compression

A method based on relative compression techniques can be consideredfor continuous data with moderate variations. The compression worksby first outputting the actual value of the first input sample, and thenreplace the following outputs with the difference from the current inputand the preceding input. For example, if the input data samples are“1100, 1097, 1105, 1120, 1107, 1107”, the output would be “1100, -3, 8,15, -13, 0”. For this example the CR was 13

24 ×100 ≈ 54% if we only countthe number of integers and the minus signs, and disregard the needfor separators between the numbers in both data sets. Decompressionis done with simple calculations on the coded differences in the data set.


3.1.4 Prediction based

Prediction based compression is a method that uses differences indata values. This method uses a number of preceding values andpredicts a difference for the next input. After calculating the actualdifference from the last value and the new input value, the error fromthe prediction is calculated and written on the output.

Xer r or = Xpr edi ct − (Xpr evi ous −Xcur r ent ) (3.1)

Usually, the absolute difference between the original value and thepredicted value is much smaller compared with the original value. Ifthe prediction is good, and the difference in value is large, a good CRcan be achieved. The compression decoder uses the same approach todecompress the data.

Xcur r ent = Xpr edi ct +Xpr evi ous −Xer r or (3.2)

As an example, consider a memory containing the previous 4 inputs:

32375 32376 32375 32387

and a new uncompressed input value of 32396. A predicted value willbe calculated based on the 4 previously uncompressed input values bycalculating their average difference. The actual difference of the newinput value and the previous values is calculated and compared withthe predicted difference. The error one get by comparing the predicteddifference with the actual difference is then written on the output. Inthis example, the predicted difference is 3 and the actual difference is9, which gives the error value -6 that is placed on the output of thecompressor.

Xpr edi ct =(32376−32375)+ (32375−32376)+ (32387−32375)

4= 3 (3.3)

Xer r or = 3− (32396−32387) =−6 (3.4)

The compression decoder performs the same calculations based onits previously decompressions and calculates the correct value fromequation 3.2 with the help of the Xer r or value

Xcur r ent = 3+32387− (−6) = 32396 (3.5)

After decompressing, the value is stored in memory and the compres-sion decoder is ready to decompress its next input value.

32376 32375 32387 32396

33 3.1. Compression methods

3.1.5 Statistical compression

Statistical compression can be used if the statistical properties of thedata are known in advance. Some letters may occur more often thanothers in a text book. Compression can the be avhieved by exploitingthe probability of each letter appering in the text. Frequently used let-ters are given short codes, while rarely used letters are given longerones.

Algorithms like Huffman coding and arithmetic coding uses statisticsto compress data. Huffman coding uses a tree structure, where eachcharacter is assigned a unique code of a length that is based on itsprobability. Consider the text string “AABABCDEABACDBC” wherethe occurrence of the characters are A:5, B:4, C:3, D:2 and E:1.An example of building the three from bottom-up, starting with thecharacters with lowest occurrence, is shown in Figure 3.1.

E(1)

D(2)

P(3)

C(3)

P(6)

B(4)

P(10)

A(5)

P(15)

1 0

1 0

1 0

1 0

Figure 3.1: Huffman tree

From the Huffman tree, the coded binary number of each of the lettersstarts from the top of the tree, and is read by following the branchesdownwards to the letter. Each branch going to the left adds a 1 to thecoded string, while a branch going to the right adds a 0. The tree iscoded so that the letters with low probability is located far from thethree top, involving many branches adding bits to their coding, whileletters with high probability is located close to the top. By coding thedata set in this manner, we get a sequence of bits that is easily de-coded without the need of any separators in between the coded words,and with a short representation of frequently occurring source symbols.When decoding, one reads the number of 1’s from the top of the tree, andif the sequence of 1’s is 4, the letter is an E, otherwise one stop when en-countering a 0 and the associated letter is found from the tree structure.


If the text string “AABABCDEABACDBC” was coded with an ASCII2

7-bit alphabet, the text string would need 15× 7 bit = 105 bits withoutany compression. In Table 3.1, the encoding of each character in thetext string before and after compression by Huffman coding is listed.The compressed string needs 5 × 1 bit + 4 × 2 bits + 3 × 3 bits + 2 ×4 bits + 1 × 5 bits = 35 bits, giving a CR of 35

105 ×100 = 33.33%. The sizeand structure of the tree depends on the statistics of the data set, andwill therefore be different for various sets of data. Decompressing ofthe compressed string is impossible without the statistical informationused when building the Huffman tree and the compression decoder hasto be provided with this information from the CE. In a text file, thestatistical information can for example be written in the beginning ofthe compressed file.

Character ASCII HuffmanA 100 0001 1B 100 0010 10C 100 0011 110D 100 0100 1110E 100 0101 1111

Table 3.1: Huffman compression

3.1.6 Telemetry compression

Logeswaran and Eswaran have investigated the performance of algo-rithms when compressing telemetry data [20]. They state that the pre-diction based algorithms are best suited for lossless, real-time applica-tions because of low processing time and good compression. Algorithmscombining compression strategies achieve the best CR with the cost ofhigher processing time, while the statistical Huffman coding algorithmwas the fastest.

The most obvious advantage of compressing data is that more data canbe transferred in the same time period. Another advantage could beenergy saving, because data can be transmitted in less time and reducethe active period of telemetry.

Because the measurements from the scientific instruments are un-known, the compression ratio is non-deterministic. The word lengthof the compressed measurements from the instruments on the sound-ing rocket is thus unknown. Because the frames in the sound-ing rocket telemetry demand data words of a fixed length, the non-deterministic compression presents a challenge when developing a com-pression method.

The compression is achieved by reducing redundancy in the data.

2American Standard Code for Information Interchange

35 3.2. Compression algorithm

A compressed data transmission is even more vulnerable to dataloss when compared to an uncompressed transmission, and telemetrytransmissions from the sounding rocket may experience data loss. Theconsequences of losing one uncompressed word from the telemetryframe is that only one measurement value is lost. If a compressed wordis lost from the telemetry frame, several measurement values might belost if the CR is good. The decompression of the received sensor data canalso be harder or even implossible when sensor words are lost from thetelemetry frame. These vulnerabilities demand that the compressionmust be robust against data loss.

3.2 Compression algorithm

The compression algorithm proposed in this thesis exploits the conti-nuity in measurement data. Instead of transmitting sample values, ittransmit change in values, which will is denoted delta, while activelyadapting the bit length to small deltas. Values from a gradually chang-ing signal will have small deltas, and small deltas will occupy fewer bitsthan its source values.

Because the algorithm compresses by coding delta values into thetelemetry data stream, it operates as a relative compression methodlike the one described chapter 3.1.3. Because the data words in thetelemetry frame are built up by a fixed number of bits, delta values offewer bits can be grouped together into words and transmitted.

I suggest two versions of building up the delta values that can improveboth the robustness against data loss and the CR. Both methods are de-scribed and Matlab codes for the two versions are in the appendix; onlyone of the methods are written in VHDL and tested on a FPGA.

The robustness that is implemented in my developed compressionmethod, comes from the introduced frame headers in the compresseddata stream. A compressed data stream consists of frame headers addedat regular intervals. The frame headers are constructed in such a waythat the data stream can be decompressed by starting the decompres-sion from any of the added frame headers.

In the first method, which will be denoted encode1, the delta values arecalculated by their distance to a sample value stored inside the frameheader. This sample value will be called a reference value, denoted ref.The ref value is at regular intervals when a new frame header is cre-ated. It is then added to the data stream. The reason for selectinga new reference value when adding a new frame header is to preventlong distances between the selected reference in the frame header andthe successive measurement values, as this would create unnecessar-ily large deltas. In contrast to a regular relative compression method,


the delta values in encode1 does not depend on each other, but dependon the reference sample value that is being stored inside a frame header.

In the second compression method, denoted encode2, the delta representthe distance from the previous sample value. Encode2 thus resemblesregular relative compression methods. The frame header in encode2also contains a reference value, which is the uncompressed measure-ment value one should obtain when decoding the last delta value insidethe previous frame.

Both of the developed compression methods will be further described inthe sections about encode1 and encode2.

A prediction based compressor was also written in Matlab as part of theperformance check of encode1 and encode2. It implemented the sameredundancy as encode2 and was tested on sample data that should fitthe algorithm well. Because the test showed no CR gain over the en-code2 algorithm, the prediction based algorithm was not further devel-oped. The test result is shown in chapter 4.1 and the Matlab codes forthe compressor and decompressor are attached in appendix B.

3.2.1 Signed numbers

As explained in chapter 2.3.1, data communication for sounding rocketsis one-way only, from the rocket down to the receiver station, withoutany error correcting methods. Consequently, some redundancy must beadded to the compression to ensure that most of the data words can bedecompressed if a transmission fault occurs. For a compression methodbased on relative encoding, the loss of a delta value would cause anaccumulative offset and make the succeeding data impossible to decom-press to its precise original value, if possible to decompress at all.

The compression methods proposed in this thesis group together a num-ber of delta values inside a frame. The frame header in the data streammarks the beginning of a new frame and the ending of a prior frame.Because the compressed data stream consists of a long sequence of bits,the frame header is marked by a unique bit sequence.

The continuous sampled signal from a sensor will move up and down,and delta values can thus be both positive and negative numbers. Val-ues from the sensors are unsigned, meaning that all values are evalu-ated as positive numbers, including zero [21]. In binary signed num-ber representation, a sign bit is used to represent positive and negativenumbers. Usually the MSB3 is used for sign representation, where a0 indicate a plus for a positive number, and a 1 indicate a minus for a

3Most Significant Bit


negative number [21]. By using a bit as a signed number, one can onlyrepresent half the magnitude of an unsigned number.

Two common ways of representing singed binary numbers are ones’complement and two’s complement, where both methods use the MSBbit as a sign bit. The conversion from a positive number to a negativenumber in ones’ complement is done by inverting all of the bits. In two’scomplement, a negative number is constructed by inverting all of thebits of the positive number and add 1 to the inverted result. Anothermethod of representing signed numbers is called signed magnitude. Insigned magnitude, the MSB bit is used to represent the sign of the num-ber, while all of the other bits are equal for both positive and negativenumbers. Table 3.2 lists the number representation for 4 bits to helpdistinguish the representation methods.

Decimal Unsigned 2’s complement 1’s complement Signed magnitude+7 0111 0111 0111 0111+6 0110 0110 0110 0110+5 0101 0101 0101 0101+4 0100 0100 0100 0100+3 0011 0011 0011 0011+2 0010 0010 0010 0010+1 0001 0001 0001 0001+0 0000 0000 0000 0000-0 —- —- 1111 1000-1 —- 1111 1110 1001-2 —- 1110 1101 1010-3 —- 1101 1100 1011-4 —- 1100 1011 1100-5 —- 1011 1010 1101-6 —- 1010 1001 1110-7 —- 1001 1000 1111-8 —- 1000 —- —-

Table 3.2: Binary number representation.

Both signed magnitude and ones’ complement numbers have a positiveand a negative representation of zero. The negative zero is coded as“1000” with signed magnitude coding and “1111” with ones’ complementcoding. A positive and negative representation of zero is worthless, butthe negative zero can be utilized as a unique marker in the data stream.The frame header in the compressed data must be of a unique sequencethat can be distinguished from the other bits in the data stream, andthe negative zero can be used for this purpose. The appearance of theframe header marker is explained more in detail in chapter 3.2.2.

The numbers of bits of the measurement values are set by the ADCon the sensor electronics digitizing the measurements, as described inchapter 2. To describe the compression algorithms in this thesis, we willconsider a 16 bit unsigned number as an output from a sensor’s ADC asan example. An unsigned 16 bit number can represent values in the


range of 0 to 65536, while a ones’ complement signed number represen-tation have a range of −216−1−1 (-32767) to +216−1−1 (+32767). Table 3.3lists the positive and negative maximum numbers with various bit sizes.

A change in bit size in the compression algorithm must be done sequen-tially; hence, it is not possible to skip any bit sizes when increasing ordecreasing the number of bits. Information about change of bit size isadded to the bit stream, where the positive and negative maximum val-ues listed in Table 3.3 are used to indicate an increase or decrease inthe bit size.

Ones’ complement maximum valusBit size Positive Negative Positive bits Negative bits16 32767 -32767 0111111111111111 100000000000000015 16383 -16383 011111111111111 10000000000000014 8191 -8191 01111111111111 1000000000000013 4095 -4095 0111111111111 100000000000012 2047 -2047 011111111111 10000000000011 1023 -1023 01111111111 1000000000010 511 -511 0111111111 10000000009 255 -255 011111111 1000000008 127 -127 01111111 100000007 63 -63 0111111 10000006 31 -31 011111 1000005 15 -15 01111 100004 7 -7 0111 10003 3 -3 011 1002 1 -1 01 101 0 -0 0 1

Table 3.3: Ones’ complement number representation with positive andnegative numbers.

In the algorithm, an S notation is applied for the numbers of bits thatare used for coding a number. Measurement values that are coded with16 bits by the ADC will then have S = 16 and the absolute delta valuescannot be larger than S −1 bits because of the sign bit.

3.2.2 Algorithm robustness

Because the sounding rocket telemetry system can be exposed to dataloss, the compression method must implement robustness. The com-pression methods presented in this thesis provides improvements overregular relative compression. First, the added frame headers in thecompressed data stream offer the ability to start the decompressionfrom multiple starting points. Secondly, the signals for change of bitsize give the opportunity to code bit size information in the data stream.These improvements are of great advantage should any loss of dataarise.


The relative compression example in chapter 3.1.3 can be used as anillustration. In this example, the numbers “1100, 1097, 1105, 1120,1107, 1107” were compressed to “1100, -3, 8, 15, -13, 0”. Several er-rors can make the decompression of this number sequence impossible.Firstly, if the first number is lost, we only have a relative sequence of“-3, 8, 15, -13, 0”, which is meaningless. Secondly, should instead oneof the numbers in the middle get lost, for example the number 15, wewould receive the sequence “1100, -3, 8, -13, 0”, and the rebuild will missone sample and give us the incorrect sequence “1100, 1097, 1105, 1092,1092”, where only the three first values are correct. Relative compres-sion has thus little robustness against loss, and other methods must beimplemented if this compression method is to be used in telemetry com-pression.

Increased robustness can be implemented in the general relative com-pression method with a little redundancy added to the compressed data.By adding the actual value of the last relative number to the end, thecompressed data occurs now as “1100, -3, 8, 15, -13, 0, 1107”. This cod-ing comes with the cost of decreased CR, but for a long data sequencethis reduction will be little and can be neglected. The added redundancyenables decompression of the coded data from two points, the start andthe end, and a loss of one single number has no effect on decompressingthe rest of the data set. Again, considering the first example, withoutthe first sample value, the compressed data set is now “-3, 8, 15, -13,0, 1107”. A reconstruction is then performed in the opposite direction,starting with the last value, 1107, and adding 0 to get the second lastnumber 1107, then by adding 13 to get 1120, subtracting 15 from 1120to get 1105 and so on and so forth.

Should one of the numbers in the middle of the sequence be missing, onejust combines a reconstruction from both end points of the compressednumber sequence. In both cases, the actual value that is lost is not pos-sible to reconstruct with this method, and one has no knowledge wherein the data set the error is located. In my compression algorithm, byadding an uncompressed value to a relative compressed data streamat fixed intervals, the compression has gained some robustness againstdata loss.

Relative compression achieve its CR by transmitting values that arerelative to each other, and those values can be coded shorter than theiroriginal values. The uncompressed number sequence in the above ex-ample consists of 66 bits, while the relative compression with the addedrobustness from an uncompressed number at the end, coded as ones’complement signed numbers, consists of 42 bits. Table 3.4 shows thebinary number representation of the uncompressed numbers and theones’ complement relative numbers.


Decimal Uncompressed Compressed1100 100 0100 1100 100 0100 11001097 (-3) 100 0100 1001 1 001105 (+8) 100 0101 0001 0 10001120 (+15) 100 0110 0000 0 11111107 (-13) 100 0101 0011 1 00101107 (0) 000 0000 0000 0 01107 100 0101 0011 100 0101 0011

Table 3.4: Relative compression values in ones’ complement.

The delta values in the relative coding stream will vary in size, andthe number of bits representing the deltas between two uncompressednumbers will vary accordingly. Therefore, a frame header is thenneeded to indicate when an uncompressed value is occurring in the bitsequence, and the frame header must not be misinterpreted as one ofthe other delta values. The shifting number of bits that is used to codea delta value also introduces a challenge for the decompressor, and bitsize information must therefore be added to the compressed stream.With ones’ complement as signed number representation, the negativezero number is used in the creation of a unique frame header. Thelongest sequence of 1’s in a stream can come from a 16 bit positivemaximum value followed by a 16 bit negative 1:

0111.1111.1111.1111 1111.1111.1111.1110

This is a sequence of 30 bits of 1’s with a 0 at both ends. Using

1111.1111.1111.1111 1111.1111.1111.1110

for a 16 bit ones’ complement encoding, a unique sequence of bits thatcan never appear in the bit stream from any of the coding combinationsis constructed. The 16 leftmost bits in the 32 bit data sequence is thenegative zero from ones’ complement. The dots in the two bit sequencesare added to ease the reading of the 32 bit signal, and are not part ofthe actual signal.

By using this binary sequence as a frame header indicator in the datastream, it will always be possible to recognize the frame header, un-less any bits in the frame header itself have been lost or changed. Theframe header is always coded in an uncompressed size, and the numberof deltas inside a frame is called Counter_max in the algorithm.

3.2.3 Changing bit size

The delta values comes in a stream of 1’s and 0’s, and a method of tellinghow many bits a delta value is coded with, has to be implemented. With-out any compression, the values are read sequentially 16 bits at a time,and the numbers are distinguished by that every number occupies 16


bits. In the data stream of compressed values and frame headers, thealgorithm starts by representing the delta values with 16 bits and si-multaneous checks if the delta values can be represented with at leastone bit less. A sequence of uninterrupted deltas that can be representedwith at least one bit less have to occur before a bit size reduction is exe-cuted. In the algorithm, the length of this sequence is called C_max. Asstated in chapter 3.2.3, from the signed number representation of ones’complement, a negative maximum value of the current bit size can beused to indicate a decrease in bit size, and a positive maximum to indi-cate an increase in bit size.

In situations of data loss, when a rebuild of the data set must be per-formed, the data stream will be read in the opposite direction, startingfrom the frame header of the successive frame. Thus, every negativeand positive maximum value must be added two times in a row; oncewith the current bit size and once with the new bit size. This makesit possible to read the changed bit size information from both sides ofthe bit size domains. To read the bit size signals in reversed directionmeans that they are interpreted differently as well. A positive maxi-mum, read in the reversed direction, indicates a decrease in bit size,while a negative maximum indicates an increase. The upper part ofFigure 3.2 shows how signals for a reduction of bit size from 6 to 5 bitsare performed. The lower part of Figure 3.2 shows how an increase from5 to 6 bits will appear, where S denotes the current bit size. Signals thatindicate an increasing bit size must be added to the data stream priorto the delta value needing more bits to be coded. Should a delta valueneed an increase of more than one number of bits, signals indicatingeach increase in bit size must be added consecutively, meaning that ajump from e.g. 7 bits to 9 bits must first signal an increase from 7 to 8bits, and then from 8 to 9 bits, before the 9 bit long delta value can bewritten to the data stream.

Decrease bit size

S bi t (S −1) bi t

100000 10000

Increase bit size

S bi t (S +1) bi t

01111 011111

Figure 3.2: Added signals to the bit stream when a change in bit sizesis executed.

A typical frame produced by the CE is then constructed by combining


the frame header together with a fixed number of delta values and sig-nals for bit size change. A new frame header that follows in the datastream marks the beginning of a new compressed frame. Figure 3.3shows an example of how a frame appears. This example contains 500deltas and only one bit size change, although it would probably consistof even more bit size signals.

Frame 1 Delta 1 Delta 2 Delta 3 ### Size ### Delta 499 Delta 500 Frame 2

Figure 3.3: Compression frame build up example.

A frame header should hold enough information to allow for decom-pressing the rest of the data set, starting from the location of a frameheader in the data stream. The reference is an absolute measurementvalue that ensures that the decompressions do not get any offset, andthat the delta values can be decompressed in upstream and downstreamdirection. The current bit size, stored in the frame header, ensures thatthe deltas are being read with the correct number of bits, while a frameID helps by ensuring that the frames are decompressed in the right or-der.

3.2.4 Encode1

In the basic relative compression method with the added robustness inchapter 3.1.3, a data loss of two or more deltas inside a single frame willmake a reconstruction from the delta values in between the outermostlost deltas impossible. This is due to the way the deltas are calculatedfrom their prior measurement value. The number sequence from theprevious example, “1100, -3, 8, 15, -13, 0, 1107”, with the last numberadded for robustness, a loss of delta value -3 and 0 will make it impossi-ble to reconstruct the three numbers in the middle. The effect of losingthe two numbers results in a total loss of four numbers for this example.

In version encode1, robustness to withstand this problem is imple-mented by the way the delta values are calculated. Unlike regular rela-tive compression, where the deltas are calculated as their distance fromthe previous number, all deltas inside a frame in encode1 are calculatedas their distance from a common reference value, which is stored insidethe frame header. The reference value is the first measurement valuesampled when the frame is created, and a new reference is set each timea frame header is created. This is done to prevent the subsequent mea-surement values in the following frames from being at a great distancefrom the reference value, which could occur if the sample data drift, or ifthe selected reference should be a spike in the measurements. Equation3.6 shows how the deltas inside the frame of encode1 is calculated fromthe reference, with i as the absolute measurement value index and X asthe input measurement value stream to the CE. An illustration of the al-gorithm is shown in Figure 3.4. The absolute measurement value, val1,


is set as reference value inside the frame, and the first delta value, delta1, is measurement value 2’s distance from the reference value. The sub-sequent delta values are calculated as the sample value’s distance fromthe reference.

VAL 1FRAME

VAL 2 VAL 3 VAL 4 VAL 5

DELTA 1

DELTA 2

DELTA 3

DELTA 4

Figure 3.4: Encode1 delta value construction.

del t a = X (i )− r e f (3.6)

Deltas created in this way benefit from not being dependent on the otherdelta values, but the distance from the reference value can be largerthan from their neighbouring values. This robustness then comes withthe cost of extra overhead from the reference values not being com-pressed values, and reduced CR because the deltas can become largerthan from a regular relative compression delta calculation.

The frame header of encode1 is built up with the unique bit sequencepresented earlier, followed by four bits indicating the current bit size forthe deltas, a 12 bit frame ID, a 16 bit reference value for the deltas inthe prior frame, and a 16 bit reference value for the current frame andits deltas. An example of a frame header is shown in Figure 3.5, wherethe current bit size is 9 (1001), frame ID is 2 (000000000010), previousreference value is 28679 (0111.0000.0000.0111) and the new referencevalue is 33115 (1000.0001.0101.1011).

Bit stream direction


11111111 11111111 11111111 11111110

Si g nal

10010000 00000010

Bi t si ze and f r ame I D

01110000 00000111

Downstr eam r e f er ence

10000001 01011011

Upstr eam r e f er ence

Figure 3.5: Encode1 frame header example.


A frame header, together with its information for encode1, is built upby five times the sensor bit size. The overhead from a frame header isthen four times the sensor ADC bit size, because the last reference inthe frame header is one of the absolute measurement values.A flow chart describing how the encode1 algorithm works is seen in Fig-ure 3.6, and the Matlab codes for the CE and the compression decoderare attached in appendix B.

There are several constants and counters in the flow chart. They areidentified in Table 3.5 to ease the reading and understanding of thechart.

Name Descriptioncounter number of deltas in framecounter_max frame sizeS current bit sizevalue input data streami input data stream indexC counter sequentially small deltasC_max small deltas counter maxnumb values number of input valuesframe a constructed frameID frame IDout output dataref1 downstream referenceref2 upstream reference

Table 3.5: Encode1 flow chart identification.


S=16ref1=ref2=value(1)

i=2,C=0,ID=1out=frame

counter=counter+1

counter ≥counter_max

counter=1ref1=ref2

ref2=value(i)i=i+1,ID=ID+1

out=frame

yes

delta=value(i)-ref2i=i+1

no

delta≤S

out=pos.maxS=S+1

out=pos.max

no

S=16 &S≤delta

no

yes

delta<Syes

out=deltaC=0

no

out=deltac=c+1

yes

C>C_max

out=neg.maxS=S-1

out=neg.maxC=0

yes

i≤numbvalues

no

no

Stop

yes

Figure 3.6: Encode1 algorithm flow chart


3.2.5 Encode2

The encode2 compression algorithm operates more similar to a basic rel-ative compression technique, as it was described in chapter 3.1.3. Thisis beacuse the delta values are calculated by their distance from theprevious measurement value as shown in Figure 3.7. In Figure 3.7, theconstruction of encode2 delta values are illustrated together with twoframe headers. The absolute measurement value, number 5 in frameheader 2, is the absolute measurement value one should get after cal-culating delta 4. The following delta 1 in frame 2 is calculated as thedistance of val 6 from val 5.

VAL 1FRAME 1 VAL 2 VAL 3 VAL 4 VAL 5 VAL 5

FRAME 2 VAL 6

DELTA 1 DELTA 2 DELTA 3 DELTA 4 DELTA 1

Figure 3.7: Encode2 delta value construction.

del t a = X (i )−X (i −1) (3.7)

The frame header contains almost the same information as the encode1frame header, the only difference is that the two reference values inencode1’s frame header are replaced by a single measurement value inencode2. A frame header example is shown in Figure 3.8, where thecurrent bit size is 9 (1001), frame ID is 2 (000000000010), and measure-ment value is 28679 (0111.0000.0000.0111). Because the measurementvalue stored in the frame headere is the value one gets after calculat-ing the last delta in the prior frame, the overhead of the encode2 frameheader is equal to encode1.



11111111 11111111 11111111 11111110

Si g nal

10010000 00000010

Bi t si ze and f r ame I D

01110000 00000111

V alue

Figure 3.8: Encode2 frame header example.

47 3.3. Reconstruction

3.3 Reconstruction

With the added signals to the data stream, a reconstruction of the com-pressed telemetry data should be possible. When decompressing thedata, one can check if the number of deltas is correct between eachframe header, and also check that the frame IDs are appearing sequen-tially. Should an ID be incorrect or missing, or if an incorrect number ofdeltas are found inside a frame, one knows that an error has occurredand that a rebuild of the data has to be carried out.

In cases where data is lost by the telemetry system, a rebuild of the datasets must be able to identify the number of delta values that have beenlost. This is crucial, as each sample value represents a time stamp thatis needed when the measurements are being used by the scientists.

3.3.1 Possible encountering data corruption

Possible events that can cause problems when decompressing the dataare numerous, and I will try to address them here.

Inside a telemetry frame, several signals are grouped together in anexplicit order, as described in chapter 2.3.1, and we now know thatloss of data occurs rarely with the upgraded receiver equipment. Byfocusing on the compressed data received from a single sensors channel,the problems from data loss can be summarized as:

• One delta value is lost• More than one delta value is lost• Frame header is lost• More than one frame header is lost• Information in frame header is lost• Bit size signal is lost• A changed bit value• Loss of some bits

The loss of a single delta value has little influence for decompressingdata from encode1, because the delta values are not dependent of eachother, only the reference value in the frame header. The loss of a singledelta will be detected from an incorrect number of delta values betweentwo frame headers. For the encode2 compression, the succeeding deltaswill have to be decompressed in the opposite direction, starting fromthe next frame header, because they are coded relative to their preced-ing number.

In situations where two or more deltas have been lost, the situation isunchanged for encode1, but encode2 will now lose all the samples be-tween the outermost lost delta values. This is because encode2 only


have the ability to perform a reconstruction until it reaches a missingsample value, and this can only be performed from one of the two frameheaders enclosing the sequence of deltas.

Should the TEs lose an unknown number of bits, without any informa-tion of where in the stream they are missing, the reconstructed mea-surement values between two frame headers must be considered as in-secure values. These values can then be wrong and with an offset, be-cause it is not possible to tell where the error is inside the frame.

A frame ID in the frame header is used to check if a loss of a frameheader has occurred, in which case additional actions have to be per-formed. If a frame header is lost, the number of deltas will also ex-ceed its limit before reaching the next frame header. Because the frameheaders’ function is to add robustness with the added information, a sin-gle loss of one header frame is not critical as the delta values, prior andsubsequent to the lost frame header, can be built up by the informationfrom their outermost frame headers. The same procedure is applied incases where information provided along with the frame header, e.g. bitsize or a reference value, are lost. In cases where two following frameheaders are lost, all delta values between the two missing frame head-ers are lost as well.

A data loss that prevents the detection of a signal that indicates achange in bit size can be identified in several ways. Firstly, if the deltavalues are read with a wrong number of bits, the total number of deltasread out before encountering a new frame header will most likely bewrong. Secondly, if the erroneously read out delta values are inspected,e.g. analyzed as a sequence of small deltas with compression possibil-ity of fewer bits, a missing bit size reduction signal in the compressedstream will uncover that an error has occurred. Thirdly, an extra num-ber of bits between the last delta and a frame header, that do not fitthe current bit size, will also tell the compression decoder that an er-ror has occurred. Finally, there is also a possibility that the current bitsize provided in the succeeding frame header do not match the one usedwhen reading out the delta values. A rebuild from the succeeding frameheader with the correct bit size, is then possible because the signals, in-dicating increase and decrease of bit size, are coded two times with bothbit sizes.

If the receiving TE system can tell how many and which bits are miss-ing in the data stream, as indicated with “Received 1” in Table 3.6, thisgives the possibility of knowing which deltas are legitimate, and hencea guaranteed correct decompression of the deltas measurement values.In the example in Table 3.6, a random set of bits have been used, and7 bits have been removed in the middle of the set in “Received 1” andin “Received 2”. “Received 2” indicates a situation where the TE has noknowledge of which bits that have been lost. As previously mentioned,

49 3.4. Digital Design

without knowledge of where in the data stream the data have been lost,the reconstructed data, within the two surrounding frames, must beconsidered insecure. The scientist will then have to decide if the inse-cure part of the data set can be used or not.

Correct 10000101011110011010101100000101000010Received 1 100001010111100________1100000101000010Received 2 1000010101111001100000101000010

Table 3.6: Errors in received data.

In situations, where only a few bits are changed in a received data word,e.g. changing the value of a delta slightly, the error could be impossibleto detect. An erroneously changed bit in a received data word wouldaffect uncompressed measurement data similarly.

3.4 Digital Design

A brief introduction to digital design is given here to ease the under-standing of the modules building up the encode1 CE. If a deeper insightis desirable, the text book “The Designer’s Guide to VHDL” by P. Ashen-den is a great resource, and there are also several web-pages coveringthe topic.

Programmable circuits can be made on a microprocessor based circuitor on a FPGA. A microprocessor is clock driven and register based, andperforms its tasks based on instructions that are stored in memory. Thenumber of clock cycles used to execute a task depends on the number ofinstructions involved.

3.4.1 FPGA

A FPGA is a programmable IC4 chip that consists of programmable in-terconnections, programmable logic blocks (PLB) and memory elements,which can be reconfigured by downloading a new bitstream file. Someof the advantages of using a FPGA when implementing a digital designover an application-specific integrated circuit (ASIC) are shorter timefrom design to finished product. Starting costs are cheaper for FPGAdesigns, but for a mass production, ASICs have lower unit costs. Inaddition, speed and power consumption are also much better on ASICdesigns.

4Integrated circuit


3.4.2 Sequential system

Digital designs are usually made sequential, operating in a specificmanner, and for the most they are made synchronous and controlledby a system clock. The behavior of a sequential system depends on itsinput values and on information stored in a memory element within thesystem. By designing a system synchronously, all registers and latchescan be updated simultaneously, and the behavior of the system can bepredicted. When a design only depends on its current input values,it is a combinational design. A combinational design does not haveany memory storage element and thus have no capability to store anystates. Examples of combinational designs are adders, multiplexers andencoders, where the output is implemented using Boolean circuits5. Inpractice, both sequential and combinational methods are used togetherwhen designing a digital system.

3.4.3 State machine

Both Moore and Mealy machines have states that changes and they areusually called state machines. A Moore machine type of a synchronoussequential system is when the outputs are only a function of thesystem’s present state. While a Mealy machine is a system where theoutput is dependent on the input in addition to the system’s presentstatet.

3.4.4 Process

A state machine is written inside a process, that consists of a sensitivitylist, a declarative part and a section for sequential statements. The pro-cess is written in the concurrent section of the VHDL code, which meansthat the VHDL code can have several processes running simultaneously.All code inside the process statement is executed sequentially, similar tohow regular computer programming languages operate. The sensivitylist of a process ususally contain a clock that synchronizes the regis-ters inside the process. By synchronizing at the clock edge, the inputdata to the registers only have to be stable at the clock edge, includinga specified clock setup and hold time, to reduce the risk of hazards fromoccuring6 [22].

To summarize, in a synchronous design, all signals should be evaluatedwithin a clock’s setup, edge and hold time. However, sometimes the cir-cuits’ reset signal can be of an asynchronous type, evaluated withoutclock synchronization, but this could lead to metastability issues. Thisis not releant for the design developed here, and I will not pursue theseissues any further.

5Examples of Boolean circuits are AND-gates, OR-gates, NAND-gates and inverters.6Hazards are undesired effects that occure due to delays in the circuit.


3.4.5 VHDL

The digital design of the CE is a synchronous design that evaluates allinput values on the rising edge of the system clock. By implementingthe design modular, the ability to make changes and add or removeparts of the design is made easier. The CE is called encoder in the digitaldesign and is the top design, encapsulating all of the four modules thatbuild up the CE system. In Figure 3.9, the encoder and the four modulesare shown. The Data Handler module calculates deltas, adds necessaryinformation to the data stream, and decides the number of bits neededto code the delta values. Beacuse the Data Handler module’s outputis dependent on internal counters and values on the input port, themodule is of a Mealy state machine type.

###

Data HandlerWRAPPER

###

ENCODER

Output InputFIFO inFIFO out

Figure 3.9: Top module encoder with sub modules.

VHDL code for encode1, FIFO, Data Handler and Wrapper, are attachedin appendix C.

Encoder

The encoder is the top module where the outer world connects to thedesign, and is responsible for distributing signals to the rest of the submodules inside it. For the system connecting to the top module, noneof the sub modules are visible, and the top module is treated as a blackbox with input and output connections. As shown in Figure 3.10, theencoder has 6 input ports and 3 output ports.


ENCODERCLK

ENABLA

RESET

WR

RD

DATAIN

DATAOUT

FAIL

READY

Figure 3.10: Encoder module with input and output ports.

In Table 3.7, the input and output signals are listed with direction, de-scription and bit size. The ENABLE, RESET, RD and READY portshave signals that are active when high. The ENABLE signal is broad-casted to the Data Handler module and the Wrapper module inside theencoder. Because the ENABLE signal is an active high signal, noneof the two listed modules will be running while this signal is set low.The two FIFOs7 are controlled by reading and writing signals from theother modules and dos not need the ENABLE signal to run. When thesynchronized RESET signal is set high, all modules resets to prede-termined values as the signal is broadcasted to all modules within theencoder. Output from the scientific instrument, e.g. producing a 16 bitmeasured value, is to be connected to the DATAIN port at the encoder.This 16 bit port is fed directly from the encoder input to an input port ofthe first FIFO module inside the encoder. The input values are storedinside the FIFO until they are being read by the Data Handler module.The compressed signal is received at the DATAOUT port of the encoderwhen the input port RD is set high. A RD request to the encoder shouldonly be carried out when the encoder has set the READY port high.While the RD port is set high and the encoder has set the READY porthigh, the encoder will output a new 16 bit compressed data stream ev-ery clock cycle. When the encoder has no more compressed data valuesready, it sets the READY signal low. The output port FAIL is set high ifone of the two FIFOs are full. If a full FIFO is written to it will start tooverwrite data that has not yet been read out. An overwriting of unreaddata in a FIFO will corrupt the data from the CE, and actions shouldbe carried out by another system monitoring the FAIL port. The mon-itoring system could for example reset the CE, which would make thesystem start its compression all over again, with new frame headers.

Because the encoder adds signals to the data stream, the system clockfor the encoder must run faster than the frequency of the input datato ensure that the input FIFO doesn’t overflow. The pause of reading

7First-In-First-Out


input data from the input FIFO, while adding information to the outputbit stream, can take several clock cycles. It is therefore necessary toempty the FIFO between the processes of adding signals.

Signal Direction Description SizeCLK In Clock signal 1 bitENABLE In Starting all modules 1 bitRESET In Synchron reset 1 bitWR In Input data write signal 1 bitRD In Read compressed data 1 bitDATAIN In Input data stream 16 bitDATAOUT Out Output data stream 16 bitFAIL Out Error indicator 1 bitREADY Out Compressed data ready 1 bit

Table 3.7: Encoder input and output connection ports.

FIFO

A FIFO is a well-known method for synchronizing and buffering datain a digital logic, as the first item stored is also the first item that isread out. A LIFO 8 is another way of buffering data and it operates as astack, where the last item stored is also the first item that is read out.

In digital logic, a FIFO has to be written so that the synthesis tool9,translating the VHDL code into digital logic, recognizes the design as aFIFO and implements it with a RAM10. If the FIFO is not recognizedby the synthesis tool, the FIFOs storage memory will be implementedin digital logic instead of with RAM and use much of the valuable re-sources on the FPGA.

The memory buffer is constructed as a circular storage with a fixed size.Once all storage locations have been written to, the FIFO will start tooverwrite the oldest data stored. When writing to the FIFO, the WRport is set high and an updated head pointer keeps track of where theitem is stored in the FIFO. The FIFO also needs a tail pointer thatpoints to the oldest item in the FIFO. A read request from the FIFO isdone by setting the RD port high. To prevent overwriting of items thathave not yet been read, an output port FULL signals when no morestorage is available. In addition, an output port EMPTY signals whenthe FIFO contains no unread items. In Figure 3.11, the concept of theFIFO memory buffer is shown. If the tail pointer catches up with thehead pointer, the EMPTY signal is set high, and if the head pointercatches up with the tail pointer, the FULL signal is set high.

8Last-In-First-Out9A synthesis tool is a software responsible for translating the VHDL code to digital

logic that can be downloaded to a FPGA.10Random Access Memory


Tail

Head

Direction

Figure 3.11: FIFO circular buffer

Synchronization of data is needed when data are crossing clockdomains, and FIFOs can be used for this purpose. A dual clock FIFO(DCFIFO) needs two clock inputs, where one of the clocks is used forthe reading process while the other clock is used for the writing process.Additional logic have to be added to the DCFIFO because of the clockdomain crossing. The added logic in a DCFIFO ensure that the headand tail pointers, that are operating in different clock domains, aresynchronized at all time. For a single clock FIFO (SCFIFO) both readingand writing are synchronized with the same clock.

FIFOCLK

RESET

WR

DATAIN

RD

DataOut

Empty

Full

Figure 3.12: Single clock FIFO module with input and output ports.

Because the compression is non-deterministic, another SCFIFO islocated at the output of the encoder. This allows the succeeding systemof the rocket telemetry to observe when compressed data is availableand to read it out when ready. In Table 3.8, the connection ports of theFIFO are listed.


Signal In/Out Description SizeCLK In System clock signal 1 bitRESET In Reset and empty FIFO memory 1 bitWR In Write data to FIFO memory 1 bitRD In Read from FIFO memory 1 bitDATAIN In Input data 16 bitDATAOUT Out Output data 16 bitEMPTY Out FIFO empty signal 1 bitFULL Out FIFO full signal 1 bit

Table 3.8: FIFO input and output ports.

The number of storage elements required in the FIFOs to prevent thesystem from overwriting unprocessed input data is different for the in-put FIFO than for the output FIFO. Input data to the encoder is acontinuous stream of measurements that is being written to the in-put FIFO. Because the Data Handler pauses its reading from the inputFIFO while it adds necessary information to the data stream, a worstcase scenario can be used to predict the size of the input FIFO. For aninstrument producing 16 bit words, such a scenario for encode1 will be areduction from 3 to 2 bits, followed by an increase from 2 to 15 bits andfollowed by a new frame header. A change in bit size signal require twoclock cycles, and a frame header requires five clock cycles. Because thelast reference in an encode1 frame header is a measurement value thatis read from the input FIFO, the number of clock cycles added from cre-ating a frame header is four. With S = 16 the FIFO size is thus calculated

2+ ((S −2)×2)−1+4 = 33 (3.8)

and each clock cycle will represent a new word written to the inputFIFO, if the encoder was operating at the same frequency as the in-put data rate. Without a higher operating frequency of the encoder, theFIFO will finally overfill.

The size of the output FIFO depends on several circumstances, fromhow well the data is compressed and how fast and how often the sub-sequent system reads the compressed data from the encoder. A simula-tion test with sensor data from the e-field sensor showed that the outputFIFO for encode1 had to have a depth of more than 28. The sensor datafrom the e-field sensor was the data set that required the largest FIFOof the available instrument sample data. This is a result of the e-fieldsensors oscillating measurements, which makes the CE add much over-head from bit size change signals into the compressed data.

Of the two compression encoders, encode1 was the algorithm that pro-duced most overhead in the data stream, as a result of how the deltasare created. When the reference value is selected, and the subsequentmeasurement values are oscillating or moving far away from the refer-ence, the delta values can get much larger than the deltas in encode2.


The consequences of writing to a full input FIFO is different fromwriting to a full output FIFO. If data is overwritten in the input FIFO,sensor samples would be lost. Writing to a full output FIFO will corruptthe compressed data stream. The actual behavior of the ionized plasmain the ionosphere is not known in advance, and choosing a FIFO with astorage depth of more than 28 would be recommended. Tests performedwith encode1 for all of the available sample data, read out from theencoder in twice the speed of the input to the encoder, showed notroubles with an output FIFO size of 100.

Data Handler

All calculations and control signals added to the bit stream areperformed by the Data Handler module. The module is constructedas a state machine, where each state has a specific task of addinginformation to the data stream. The only difference of the twocompression methods proposed in this thesis are performed here.

Data HandlerCLK

RESET

ENABLE

FULL

EMPTY

DATAIN

S

DATAOUT

READY

RD

Figure 3.13: Data Handler module with input and output ports.

In encode1, the delta values are calculated as the distance from a se-lected reference that is part of the frame header. The frame header alsoincludes the reference value for the preceding delta values for increasedrobustness. In cases where delta values are too large to be coded in ones’complement, signals for increasing bit size is coded until reaching thelimit of S−1 bits, where S is the instrument ADC output bit size. A newframe is then created, and the measurement value causing the largedelta is selected as a new reference instead. Although this presumablynever happens, or only happens because of measurement errors, theamendment to the code allows for a correct coding of the complete dataset. A disadvantage is that the number of deltas inside frames that arecreated when these occasions arise, is not fixed. However, by checkinghow large the reference would have been as a delta value, one can tellthat the frame consists of an inconsistent number of deltas.


Encode2 uses delta values that are relative to their prior measurementvalue, and the risk of encountering delta values that are too large forones’ complement coding are even lower than for encode1. In caseswhere a delta gets too large, encode2 will signal increase in bit sizein the same manner as encode1. When reaching the limit of S −1 bits, apositive or negative maximum of S −1 bits are outputted, depending onwhether the delta is positive or negative. Nevertheless, large changes inthe data can also carry information that are of interest to the scientists,as was for the gyros in chapter 2.6.2. In Figure 2.8, showing instrumentdata from the ICI-4 gyro, the large spikes from when the engines haveburned out and when the sounding rocket re-enters the atmosphere tellthe scientists when the experiments starts and ends.

The Data Handler module only reads from the input FIFO of the en-coder when the FIFOs EMPTY signal is set low, it stalls while theEMPTY signal is high, and it produces an output each clock cycle whenthe module is running. This makes the Data Handler not only depen-dent on the CE’s ENABLE signal to be active, but also the input FIFO’sEMPTY signal.

Of the four output signals on the Data Handler module, the RD signal isconnected to the input FIFO requesting to read, while the S, DATAOUTand READY signals are connected to the Wrapper module.

The DATAOUT signal is a S bit wide signal, e.g. 16 bit for mNLP, andthe four bit wide S output port tells the Wrapper how many bits in theDATAOUT port that is valid, starting from the LSB position. Due tothe stalling of the Data Handler module when the input FIFO is empty,a one bit READY signal is needed to tell the Wrapper module when anew output value is ready from the Data Handler.

As an example, consider an instrument with an S=16 bit ADC and adelta with a decimal value of +124, coded as “0000.0000.0111.1100”in ones’ complement binary. If the current bit size in the stream iseight, the Data Handler module outputs “0111” on the S port, telling theWrapper to only read the rightmost eight bits, “0111.1100”, and discardthe remaining eight leftmost bits. The reason why the output on theData Handler’s S port is a S-1 bit value, is because the maximum valuefor the 4 bit wide port is 15, and that using 0 as a bit size is worthless.Thus, when sending the current bit size on the S port, the Data Handlermodule subtracts 1 from the bit size, while the Wrapper module adds 1when reading it.


Signal In/Out Description SizeCLK In System clock signal 1 bitRESET In Reset and empty FIFO memory 1 bitENABLE In Start signal 1 bitFULL In Input FIFO full 1 bitEMPTY In Input FIFO empty 1 bitDATAIN In Intput data 16 bitS Out Current bit size 4 bitDATAOUT Out Output data 16 bitREADY Out Output data ready 1 bitRD Out Read signal input FIFO 1 bit

Table 3.9: Data Handler input and output ports.

Wrapper

The data from the Data Handler module is merged together inside theWrapper module to words of equal size as the sensor’s ADC. The inputport of the Wrapper module is connected to the output port of the DataHandler module, and the port is being read each clock cycle when theData Handler module sets its READY port high.

WRAPPERCLK

RESET

DATAIN

S

VALID

READY

DATAOUT

Figure 3.14: Wrapper module with input and output ports.

A memory storage of 2×S bits is used to merge the data, and an outputis written to the output FIFO when an S bit wide word is produced. Theoutput word must be of the same length as the digitized words from thesensors to fit the telemetry format, that is of a fixed length. This meansthat if a sensor ADC is producing 16 bit words, the Wrapper will pro-duce 16 bit outputs as well. For an instrument producing 16 bit words,and if the current bit size is eight, the Wrapper would need to combinetwo outputs from the Data Handler module to produce a word of cor-rect length. In cases where the merging of sample values produces aresult wider than the required S bits, the remaining bits are stored andmerged together with the subsequent input.

The number of clock cycles needed to produce an output from the

59 3.5. Testing Environment

Wrapper is not known in advance, and can vary from one clock cycle toS2 clock cycles, depending on how good the compression is at any givenmoment.

Signal In/Out Description SizeCLK In System clock signal 1 bitRESET In Reset and empty FIFO memory 1 bitDATAIN In Intput data 16 bitS In Current bit size 4 bitVALID In Ready signal from logic 1 bitREADY Out Write signal to FIFO 1 bitDATAOUT Out Output data 16 bit

Table 3.10: Wrapper input and output ports.

3.5 Testing Environment

There are several manufacturers of FPGAs, but Xilinx and Altera havethe largest market share. 4DSpace uses FPGAs from Altera in theirsounding rockets today, and Altera FPGAs are also planned to be usedon the daughters on the next flight. It was therefore a natural choiceto test the algorithm on a FPGA from the same manufacturer. The de-velopment board Cyclone 5 DE1-SoC 11 from Altera was available andselected for this thesis. The FPGA chip with the integrated hard proces-sor system (HPS) is shown in Figure 3.15 with a red circle to indicateits placement.

In later campaigns, 4DSpace are looking into the possibilities ofperforming more of the calculations on-board, e.g. calculating theelectron density from the mNLPs. The Cyclone 4 FPGA is used ontoday’s ICI sounding rockets, while the daughters are going to use theMax 10 FPGAs. A Max 10 FPGA have the ability to run the Nios 2soft core embedded processor12, to perform on-board calculations. Thiswill ease the implementation of on-board calculations on future ICIcampaigns.

11System-on-Chip12A soft core embedded processor is fully implemented by digital logic on the FPGA.


Figure 3.15: The Cyclone V DE1-SoC development board.

3.6 Development process

The development process of the two CEs, encode1 and encode2,have involved several steps. These steps include: finding a usefulcompression method, addressing weaknesses in the algorithm inregards of data loss, and implementing robustness and other neededsignals to the coded data stream. This section gives a brief review of thedevelopment and how the tests were performed at the various stages,from an idea to a digital design. The work flow is shown in Figure 3.16.

FPGA testing

VHDL simulation

Matlab testing

Algorithm idea

Figure 3.16: Development process.

The decision to develop a CE based on the relative compression methodwas made after investigating various compression methods. The re-search involved finding a method with low complexity and that presum-ably would give a satisfying speed of data throughput. The proceedingsteps involved realizing a regular relative compressor in Matlab, andtest the performance of the algorithm on sample data and produce a bi-

61 3.6. Development process

nary compressed data stream. After achieving satisfying compressionresults, a method for coding bit size information was figured out andimplemented to the algorithm.

Next, a decompressor was written in Matlab and extensive testing weredone to ensure that the compressed data stream was possible to de-compress. A crucial step in the development of encode1 and encode2involved the exploration of the shortcomings of relative compression, re-lated to how lost data values will influence how much information thatcan be decompressed. Frame headers were implemented to overcomethese problems and two versions of the compression algorithm were con-structed with associated decompressors. A CE and decompressor basedon the prediction based algorithm described in chapter 3.1.4 were writ-ten in Matlab. The prediction based CE was written to implement thesame redundancy as the encode2 CE.

Testing procedures involved testing each of the sample data sets onencode1 and encode2 CEs. Several tests with various settings forCounter_max and C_max for the CEs were run to explore how well theCEs behaved with the different sensor data. The tests gave knowledgeof which settings were best suited for each of the CEs and sensors toachieve the best CR. The decompressed data were compared to the sam-ple data without any faults or data loss.

The encode1 algorithm was written in VHDL and a testbench was madeto run simulations of the digital code. A testbench is an environmentthat gives the device under test (DUT) stimulus and is used to verifythe correctness of the design. With a simulation tool, the behavior ofthe design and its signals can be monitored in a wave form window. Atestbench simulation is a powerful tool when developing digital designs,but verification on real hardware is also needed to ensure that the de-sign behaves as intended.

Simulations were performed with the same sample data as in Matlab,and verification of the compressed data stream was done by comparingthe simulation results with the compressed streams produced in Mat-lab. The compression results were identical and without any errors.

The digital desgin was tested on the same sample data used for testingthe algorithms in Matlab and in simulations. The benefit is that theverification of the digital design can be performed in the same manneras when verifying the results from the simulations. An explanation ofthe testing environment for the digital design is given in chapter 3.7.

Test of the digital design on the FPGA was performed with all of theprovided instrument measurement data from the ICI-2, ICI-3 and ICI-4 campaigns. The compressed bit streams were compared with the bitstreams from running the algorithms in Matlab, and the results were


equal and without any faults.

3.7 Testing the digital design

The digital design on the FPGA could have been verified in several ways,for instance by connecting a sensor or an instrument that produces datafor the digital design to process, or by using previously gathered data.Regardless, the data has to be transmitted to the FPGA and its outputmust be read out and analyzed.

An instrument connected to a DAQ card can be connected to GPIO13

connections on the FPGA’s development board. These are unused con-nectors that have pins without a predefined function, but the pins canbe configured and programmed to perform needed tasks. By setting up aserial connection using GPIO pins and by writing code for an interface,communication can be established and data from a sensor or instrumentcan be sent to the CE.

It is best to use a computer to monitor the results from the digital de-sign because the data can then be written to a storage device, observeddirectly on a screen or analyzed further. Connecting the FPGA to anexternal computer involves e.g. using the UART14 connection on the de-velopment board and implementing UART communication code to thedesign. With UART, the data is transmitted in a serial form. The UARTstandard supports several transmission speeds, with a maximum datarate of around 20 Kbit/s for a RS-232 connection. Data can be exchangedbetween the FPGA and the computer with a serial communication pro-gram.

Because the available instrument sample data from past ICI campaignswere used during development of the algorithms in Matlab, a test setupthat used the same sample data was preferred. The possibility of com-paring the results from test runs in Matlab and test runs on the digitaldesign was favorable because it gave the ability to compare to a verifiedresult. Another advantage was that the algorithm could be tested withdata from the actual sensors on the ICI campaigns, simulating a morereal-life situation.

3.7.1 Hard processor system

SoC FPGAs are chips that have both a processor and a FPGA architec-ture integrated together on a single device. The processor can run as

13General-Purpose Input/Output14Universal Asynchronous Receiver/Transmitter

63 3.7. Testing the digital design

an independent system with an OS, without the need of any digital de-sign on the FPGA. The processor on the Cyclone 5 is a dual-core ARM15

Cortex-A9 HPS, with the ability to run the Linux operating system froma micro-sd memory card [23]. By setting up a HPS-to-FPGA bridge anda memory mapped area, the HPS and the FPGA can be programmed tocommunicate and exchange data.

A Linux driven testing environment was chosen for the digital designbecause of its flexibility of testing through an own-developed program.With memory mapping, the HPS and FPGA can communicate througha HPS program and a module on the FPGA.

A program that can communicate with the digital design was writtenin C and compiled to run on the HPS system. The HPS running pro-gram reads instrument measurements from a file and writes them tothe memory mapped area. Next, an interfacing module was writtenand downloaded to the FPGA. The interfacing module is designed toread and write to the same memory mapped area as the HPS runningprogram. Commands for writing and reading data were sent from theHPS program and the interfacing module was responsible for synchro-nizing data and signals, and reading and sending commands.

A HPS is an instruction based system, and the number of clock cy-cles before a command or data is written or read is non-deterministic.This property had to be taken in account when writing the interfac-ing module, to ensure that each command was performed only once bythe CE. Because the digital design performs its tasks much faster thanthe HPS system, without this synchronization data samples could havebeen read multiple times and commands performed several times morethan intended by the C program.

3.7.2 Testing system

The HPS system was set up to run Ubuntu Linux 12.04 LTS, and theLinux Board Support Package (BSP) was downloaded from the TerasicCyclone 5 DE1-SoC board resource page [23] and installed on an 8gbmicro SD 16 card. The programming was done on a MacBook Pro run-ning OS X 10.11.3 with an Ubuntu 14.04 LTS image running in Paral-lels Desktop 11. The HPS was set up with a static IP17, provided fromthe OS X operating system. A shared folder was mounted, allowing forfile transfer between the operating systems, and Linux commands weresent using a SSH18 connection.

15Advanced RISC Machine (ARM) is a reduced instruction set computing (RISC)architecture for computer processors

16Secure Digital17Internet Protocol18Secure Shell


3.7.3 FPGA communication

For the HPS and the FPGA to communicate, a bus interface bridge mustbe established, providing a communication channel between the twoportions of the chip. A lightweight HPS-to-FPGA AXI19 bridge is aninterface with 32-bit data width, which allows the HPS to communicatewith the FPGA via a memory mapped area.

Communication between the HPS and the digital design is done by read-ing and writing to 4 registers listed in Table 3.11.

Name Desctription SizeCtrl_reg Control register 32 bitAddr_reg Address register 32 bitData_reg Data input register 32 bitData2_reg Data output register 32 bit

Table 3.11: HPS and FPGA register interfaces.

The commands that are sent from the HPS to the digital design use thefour rightmost bits in the control registe, listed in Table 3.12, while theinterfacing module uses the fifth rightmost bit to send the DATAREADYsignal from the CE to the HPS program.

Binary Command0000 STOP0001 ENABLE0010 WRITE0100 READ1000 RESET

Table 3.12: HPS commands.

A loop in the HPS program reads a sample value from a file and sends itto the digital design once every loop. The program tries to make a readfrom the encoder two times for every loop by checking if bit number 5in the Ctrl_reg is set high. This is done to prevent the output FIFOfrom filling up and simulates a system where the CE and its proceedingsystem run at a frequency twice of the instruments’ data sampling fre-quency. Data read by the HPS from the digital design is stored in a filefor further analysis.

19Advanced eXtencible Interface

65 3.8. Resource usage

A Python script was used to compare the compressed data results fromMatlab with the compressed data results from the digital design. Allof the intrument measurements were tested and verified in the digitaldesign.

PC Cyclone 5 FPGAHPS

LinuxEncode1module

Interfacemodule

Monitor

Commands

Figure 3.17: Test setup of digital design with HPS system.

The VHDL and the C codes for the interfacing module and the HPS pro-gram are attached in appendix C.

3.8 Resource usage

A FPGA consists of a fixed number of registers, logic elements, PLLs20,memory, and the number of resources available will depend on whichFPGA is being used. A vital aspects when choosing type of FPGA, con-cerns the available space on the printed circuit board (PCB) that willhouse the FPGA. Using a larger FPGA than needed is a waste of valu-able space, and can also be a waste of money.

On the ICI-4 campaign, the sounding rocket used Cyclone 4 EP4CE15FPGAs from Altera. This is most likely the model that will be selectedas on-board FPGAs on the ICI-5 campaign as well. A decision regardingwhich FPGA to use on the ICI-5 sounding rocket has not yet been taken,and the possibility of using the larger Cyclone 5 FPGA on the next ICIcampaign is not unlikely. The instrument carrying daughters will beequipped with Max 10 10M50 FPGAs from Altera.

The available resources and estimated cost of implementing oneencode1 CE on the three FPGAs are listed In Table 3.13, Table 3.14 andTable 3.15. The various FPGAs implement different logic modules, andthe Cyclone 4 and the Max 10 FPGA has logic elements (LE), and theCyclone 5 has adaptive logic modules (ALM). An ALM on the Cyclone 5

20Phase-locked loop


contains an 8-input fracturable look-up-table (LUT), a couple of adders,four multiplexers and 4 registers. While on the Max 10 and the Cyclone4 FPGAs, a LE contains a four-input LUT, a programmable register andadditional connections and register support.

Resource Encode1 Cyclone 5Logic elements (LE) 3320 (7%) 49760Logic utilization in ALM 1610 (5%) 32070Registers 526 (<1%) 128300Block memory bits 3200 (<1%) 4065280

Table 3.13: Cyclone 5 usage and resources

Resource Encode1 Max 10Logic elements (LE) 3320 (7%) 49760Combinational functions 3271 (7%) 49760Registers 526 (1%) 49760Memory bits 3200 (<1%) 1677312

Table 3.14: Max 10M50 usage and resources

Resource Encode1 Cyclone 4Logic elements (LE) 3306 (21%) 15408Combinational functions 3254 (21%) 15408Registers 526 (3%) 15408Memory bits 3200 (<1%) 516096

Table 3.15: Cyclone 4 usage and resources

From Table 3.14 and Table 3.15, it is clear that the LEs limits how manyCE that one FPGA can hold. The ADC interface on the Max 10 and theCyclone 4 uses 202 LEs, which is less than 1% of the available resourceson the Max 10 and 1.5% of the resources on the Cyclone 4 FPGA. Eachof the channels from a sensor is connected to an ADC, and each of theADCs needs its own interfacing module on the FPGA. In addition, theremust be room for other designs on the FPGAs, which will vary with thetype of sensors connected and any other tasks performed by the FPGAs.

On the MAX 10, which most likely will be used on the sounding rocketsdaughters, a CE uses 7% of the available LE resources. This resourceusage sets a limitation to 7 or 8 CEs on a single Max 10 FPGA, using50-60% of its resources. A daughter will probably be carrying maximum4 mNLPs or e-field probes and the CE will need less than 30% of the re-sources. This is then scalable if the rest of the system can manage with70% of the resources.

67 3.8. Resource usage

On the Cyclone 4 FPGA, used on each of the instrument PCBs on thesounding rocket, a CE uses 21% of the available LE resources. This us-age will limit the system to implement 2, or maximum 3 CEs on a singleFPGA, depending on the resource need of the rest of the system. On theICI-4 campaign, there were 8 mNLPs, meaning that the system shouldbe capable of holding eight CEs, which is 172% more than the availableresources on the Cyclone 4. The CE is then not scalable to the numberof ADC channels connected to the Cyclone 4 FPGA, if more than 2-3ADCs are connected. A better solution would then be to use the Cyclone5, where one CE uses 7% of the resources. This is then scalable to eightADC interfaces, if the rest of the system can manage with the remain-ing 40% of the resources.


Chapter 4

Results

To add compression to the sensor data on the ICI campaign is reason-able if the obtained CR is efficient and resources are available. Compar-ing the achieved CR from the two suggested CE algorithms with morecommon compression schemes can reveal how effectively the data is be-ing compressed.

Matlab have the ability to perform GZip and Zip lossless compression ofdata. These compression algorithms uses the DEFLATE [24] algorithm.The algorithm treats the data as blocks, where each of the blocks arecompressed using a combination of LZ77 algorithm and Huffman cod-ing. In this testing, GZip and Zip compresses data files with the instru-ment measurements. This give GZip and ZIP the advantage of beingable to analyze the data set and utilize statistics in the compression,while encode1 and encode2 reads the data sample by sample as theywould occur in a real-time system on the rocket.

As seen in the description of the CE algorithm, there are two param-eters that will affect the compression ratio; how often a new referencevalue is selected and transmitted with a signalling extension by theframe header and how many sequentially small numbers are neededbefore bit size is reduced.

In the two algorithms, Counter_max tells the number of deltas that isinside a frame, and a frame’s size has multiple effects. From the sectioncovering the robustness of the algorithms, the importance of the frameheaders is described with regard to rebuilding data when informationhave been lost. But adding frame header information comes with a costof more bits added to the data stream. Encode1 creates deltas fromsample values relative to a reference value, stored in the frame headerand for an unstable signal, this reference can be selected in a greatdistance to the preceding sample value. The large distance between areference value and subsequent measurements will create unnecessar-ily large delta values, but can be avoided by using frames consistingof fewer delta values. Large frames should then be selected for steady

69

Chapter 4. Results 70

signals, while shorter frames could be an advantage for signals with amore altering behavior. The CR from encode2 benefits from the use offrames consisting of many delta values, and the frame headers only addrebuilding robustness to the compression.

A bit size reduction is performed when a sequence of C_max deltas,which could have been coded with at least one bit less, have beencalculated. Because there is a high probability that the deltas willcontinue to be small, we introduce little overhead to the stream withthe bit size signals. If the size of the deltas are stable, the compressorwill work its way towards the correct bit size and stay there until a largedifference occur. For a 16 bit signal, a reduction from 16 bits to 15 bitsintroduce a signal overhead of 31 bits, which will demand that the 32subsequent deltas can be coded with maximum 15 bits before we gainany compression.

4.1 Achieved compression

Compression results on test data from the mNLP, magnetometer,gyroscope and e-field sensor are listed in Table 4.1 together withcompression results from Matlab’s built in Zip and GZip compressionalgorithms. Table 4.1 reveals that encode2 almost always achievea better CR than what is achieved from the versatile Zip and GZipalgorithms, while the encode1 algorithm achieved equal CR as Zip andGZip for the most of the data. The best compression result is highlightedin the table.

Sensor Encode1 Encode2 GZip Zipm-NLP1 36.0% 24.2% 31.7% 31.7&m-NLP2 38.6% 25.1% 36.5% 36.5&m-NLP3 40.1% 25.9% 39.3% 39.3%m-NLP4 42.4% 27.2% 43.0% 43.0%E-Field2 88.9% 67.7% 81.4% 81.5%E-Field3 91.4% 69.9% 86.5% 69.9%Magnetometer1 65.0% 38.3% 65.7% 65.8%Magnetometer2 84.7% 54.6% 86.1% 86.1%Magnetometer3 83.9% 54.5% 85.9% 85.9%Gyroscope1 58.4% 37.4% 53.3% 53.3%Gyroscope2 58.7% 37.5% 53.2% 53.2%Gyroscope3 29.6% 27.3% 25.9% 25.9%

Table 4.1: Compression results of raw data. Results are compressed sizerelative to uncompressed raw data size.

The average bit size value for the compression of sensor data are listedin Table 4.2. The encode2 algorithm reduces the representation of thedelta values to fewer bits for all of the sensors when comparing it withthe encode1 algorithm.

71 4.1. Achieved compression

Sensor Encode1 Encode2m-NLP1 4.6 3.7m-NLP2 5.0 3.8m-NLP3 5.2 4.0m-NLP4 5.6 4.1E-Field2 13.3 10.6E-Field3 13.6 10.9Magnetometer1 9.9 5.9Magnetometer2 12.9 8.5Magnetometer3 12.9 8.4Gyro1 8.6 5.6Gyro2 8.5 5.6Gyro3 4.5 4.3

Table 4.2: Average bit size from encode1 and encode2.

By looking at the bit size distribution, the slowly varying signal fromthe mNLP confirm that the two algorithms performs best with a signalthat is changing slowly. Figure 4.1 shows that the majority of deltasfrom mNLP probe 1 are encoded from 4 to 6 bits with encode1, whileFigure 4.2 shows that encode2 codes the same data with mostly 4 bits.

Figure 4.1: Encode1 bit size distribution after compressing mNLP probe1 data.


Figure 4.2: Encode2 bit size distribution after compressing mNLP probe1 data.

For an oscillating signal, like the one from the e-field sensor, themajority of delta bit sizes are encoded with 14 to 16 bits with encode1 inFigure 4.3, and 10 to 13 bits with encode2 (Figure 4.4). The frequentlychanging value of this signal gives a poor compression rate as Table 4.2reveals.

Figure 4.3: Encode1 bit size distribution after compressing e-fieldchannel 2 data.

73 4.1. Achieved compression

Figure 4.4: Encode2 bit size distribution after compressing e-fieldchannel 2 data.

Testing on the mNLP probe 1 from the ICI-2 flight, with frames of 500delta values and sequence length of 10 small deltas before reducingbit size, showed that encode1 gained a CR of 36.4%, encode2 a CR of25.0% and the prediction based a CR of 25.6%. The prediction basedcompression do not outperform the encode2’s CR, but applied on amore steadily changing signal than used for testing in this thesis, theprediction based algorithm could be performing better.


Chapter 5

Summary and conclusion

This chapter sums up the work presented in this thesis, with its contri-bution to the 4DSpace research group, the results of the work and ideasfor further work.

5.1 Conclusion

In this thesis, I have investigated and developed a method for compres-sion of sounding rocket telemetry data for the ICI campaign. The com-pression method implements telemetry loss robustness, is customizedto be used for serial data, have low complexity and should be easy toimplement on a digital design. The method have been tested on sensordata from previous ICI campaigns, and the achieved CR have been com-pared with two typical compression algorithms with great results. Thetwo algorithms encode1 and encode2 outperformed or performed equallygood as the algorithms based on statistical analysis of the data. Finally,possible scenarios that can introduce problems with decompression andhow the robustness deals with these problems, have been explored anddiscussed.

This thesis makes the following contributions to the 4DSpace researchgroup:

• An introduction to the 4DSpace research group and its scientificinterest in the ionosphere have been given, along with a presenta-tion of the sounding rockets as instrument carrying devices and4DSpace’s scientific instruments. Telemetry format, data sam-pling and coding have been explained to give a better understand-ing of how the information is sent from the sensors to the teleme-try system and down to ground.

• Various compression methods have been explored and explained,along with typical usage and examples. From this analysis,two compression methods that use the continuous of analoginstruments have been developed and tested in Matlab. One of

75

Chapter 5. Summary and conclusion 76

the methods has in addition been implemented in a digital designand tested on a FPGA.

• The cost of implementing the digital design on a FPGA has beeninvestigated. The available resources on the sounding rocket andits daughter’s FPGAs have been studied. A scalability inspectionof the compression encoder with the instruments FPGAs has beeninvestigated.

• The compression performance of the two developed compressionalgorithms have been tested on sample data from instruments onprevious ICI flights. The compression results showed great resultsfor fairly stable signals and good results for rapidly changingsignals.

• Possible problems that may arise when decompressing the re-ceived data, introduced by lost data packages from the telemetrylink, have been addressed. Robustness to help withstand theseissues are proposed and implemented in the design.

• Possible methods for testing the digital design have been given. ALinux driven HPS system has been implemented to interact withthe digital design on the FPGA. An interface module has beendeveloped and integrated on the FPGA, which has given the abilityto synchronize communication between a HPS running programand the compression encoder. The testing of the digital designhas been performed with an own developed HPS running program.The implementation of a HPS system and an interfacing modulehas given the ability to run tests on a real-time system and hasgiven 4DSpace a test setup that can easily be adopted to otherdesigns.

• Concerns when integrating compression on to the instrumentsystems have been identified and explained.

The choice of what CE to use depends on two factors: the probabilityof data loss and how the signal measurements behave. If there is asubstantial possibility of loosing telemetry frames, the encode1 CE isrecommended. The encode1 CE is constructed to withstand some of thelimitations in regular relativ compression by the way the deltas are con-structed. An implementation of the encode2 CE is recommended if theexpected data loss is low. The encode2 algorithm achieve a much betterCR compared to the encode1 algorithm.

The implementation of encode2 CEs is recommended for the futureICI campaigns. The telemetry data loss has been greatly reduced andshould not be of concern. The studies of the instruments from the priorICI flights and the achieved compression with encode1 and encode2,show that encode2 is the algorithm that is best suited.

The scalability check of a CE on the Cylone 4 and Max 10 FPGAs revealsthat the Cyclone 4 FPGA is too small. I therefore recommend using an-other FPGA like the Cyclone 5 to integrate the CEs on the sounding

77 5.2. Future work

rocket. A Cyclone 5 FPGA will allow for on-board calculations of sensordata, which is desirable on the future ICI campaigns.

5.1.1 Challenges

By implementing the CE to the sounding rocket system, other chal-lenges are introduced as mentioned in the chapter 2, and a solution willhave to be established before the instrument data on the ICI soundingrocket can be compressed. A module that synchronizes the digitizeddata from the sensors to the CEs must be implemented, and a mod-ule between the CEs and the TE must be added so that the telemetryframes can be constructed.

A solution where data is written to a storage device like a FIFO, waitingfor the subsequent part of the system to read it out, will give problemsif data is not read out fast enough. The consequence of writing to a fullFIFO is that it will overwrite its oldest data, corrupting the compresseddata stream until a new frame header is transmitted.

If the sensor data is not possible to compress, e.g. if the signal al-ters rapidly and creates very large deltas, there are no solutions im-plemented to deal with this problem. In cases where the deltas get verylarge and compression is impossible, the size of the data set will in-crease because of the added frame headers.

5.2 Future work

Methods of increasing the compression even more are of interest, andI will here introduce some suggestions that can improve the CR withsmall adjustments to my proposed algorithm.

Both of the algorithms starts the compression from the ADCs bit size,slowly working its way towards a stable bit size range, one bit size at atime. By adding the ability for the CE to adapt its bit size faster, the CRcan be improved even more. Already at the point of the first reductionof bit size, the CE can probably get an idea of the bit size range of thedeltas. By allowing the CE to signal bit size reduction directly from, e.g.16 bits to 8 bits, a faster adaption to the deltas bit size is achieved.

The prediction based compression algorithm in chapter 4.1 should betested with an increased memory size. In the testing of the predictionbased algorithm, a memory depth of three was used. By increasing thememory holding the absolute values, the calculated predictions can becloser to the actual delta value. A small error from the calculated pre-diction will need even fewer bits.


An investigation of the possibility to reduce the needed resources of aCE on a digital design should be performed. One should look at im-provements to the VHDL code, so that the use of logic elements on theFPGA can be reduced. For a steady signal, this compression methodcould give good results.

Other methods of compressing abruptly oscillating measurement datashould be looked into. Steep curves on sample data can make the deltasquite large, preventing good compression with a relative compressionmethod.

As previously mentioned, the CE must run at a higher frequency thanthe sensor samples are produced. Thus, the CE needs a synchronizingmodule between itself and the sensor ADCs. The ENABLE signal tothe compression encoder is distributed to the Data Handler module andWrapper module in the digital design. Because the Wrapper module isonly active when the Data Handler module signals a valid output, andthe Data Handler is only active when the input FIFO’s EMPTY signalis low, the ENABLE signal is not needed by the Data Handler moduleand the Wrapper module. The ENABLE signal should instead be usedas a synchronized write signal to the input FIFO’s WR port, controlledby the synchronizing module. This will ensure that the sensor measure-ments, running at a slower frequency than the CE, will be synchronizedto the CE’s clock domain.

5.2.1 FIFO multiplexing of data channels

Data compression is non-deterministic, meaning that its outcome andCR cannot be known in advance if the uncompressed data set is alsounknown. The unknown CR is a challenge to the sounding rocket’stelemetry system that must be solved before the CE can be integrated tothe sensor system. PhD student G.A Subbarao at 4DSpace, UiO, is cur-rently working on possible solutions to this challenge and I will presentone of his ideas here.

The commutator system organizes the measurement data from the vari-ous sensors and instruments, and constructs frames of information thatare being transmitted to the ground. When the frames are received bythe decoders on the ground, the organized data are extracted and sensorwords are arranged in the same order as when they were digitized bythe sensor DAQ.

Consider a sensor with four measurement channels that is TDM intoa single stream as in Figure 5.1, where the data words (WS) are com-bined into a single stream. This is a simplified illustration of how thedata are grouped and sent to the TE, from the sensor card on the sound-

79 5.2. Future work

ing rocket.

Sensor ch 1 WS1

Sensor ch 2 WS2

Sensor ch 3 WS3

Sensor ch 4 WS4

WS1 WS2 WS3 WS4 WS1 WS2 WS3 WS4

Figure 5.1: Sensor stream example.

With FIFO buffers and a non-greedy arbiter controlling a MUX, as inFigure 5.2, compressed data can be sent to the commutator and teleme-try system in a frame-like fashion. Each of the FIFO buffers is assignedan identification number that is added to the data stream, introducinga fraction of an overhead to the compressed data. At system start uptime, the FIFO buffers will start to fill up at different speed, dependingon how well the signals compress. When one of the FIFOs reaches apredefined limit, it raises a signal and the system starts to empty theFIFO. At first, the identification is added to the stream, followed by anumber of data words read out from the FIFO. If the number of wordsread from the sensor’s channel 1, before the stream is overtaken by thesensor’s channel 2, is 3, and the channel number is used as identifica-tion, the TDM stream could now look like:

1 WS1 WS1 WS1 2 WS2 WS2 WS2

The regular sensor word assignment in the telemetry frame built by thecommutator will now have to be interpreted differently when decodingon ground.


Sens

orch

anne

ls Multiplexer

From arbiter

To commutator

FIFO buffers

Figure 5.2: FIFO multiplexer system.

In Figure 5.2, the FIFO buffers have been drawn with different amountof data stored as an illustration.

Bibliography

[1] J Moen et al. “"ICI-1: A new sounding rocket concept to observemicro-scale physics in the cusp ionosphere"”. In: EUROPEANSPACE AGENCY-PUBLICATIONS-ESA SP 530 (2003), pp. 543–550.

[2] G Proelss. "Physics of the Earth’s Space Environment: An Intro-duction". Springer, 2004. ISBN: 3540214267.

[3] E Hauge-Iversen. “"E-feltinstrument for sonderakett"”. MA the-sis. University of Oslo, 2012.

[4] F Landis Markley and J.L Crassidis. "Fundamentals of SpacecraftAttitude Determination and Control (Space Technology Library)".Springer, 2014. ISBN: 1493908014.

[5] J.L Tresvig and T Lindem. “"A miniaturized subpayload systemused for measurements in the ionosphere - A design concept"”. In:Aerospace and Electronic Systems Magazine, IEEE 30.4 (2015),pp. 24–28.

[6] B Sklar. Digital Communications: Fundamentals and Applica-tions (2nd Edition). Prentice Hall, 2001. ISBN: 0130847887.

[7] Payload Services Andoeya Rocket Range. "Telemetry Tutorial".Document revision C. Aug. 2009. URL: ftp : / / ftp . lpp .polytechnique.fr/robert/keep/Transfert/ICI/Telemetry_Tutorial_RevC.pdf (visited on 04/06/2016).

[8] J.K Bekkeng. “"Prototype Development of a Low-Cost SoundingRocket Attitude Determintaion System and an Electric FieldInstrument"”. PhD thesis. University of Oslo, Jan. 2007.

[9] Welcome to IRIG 106The standard for Digital Flight Data Recording. Online. URL:http://http://www.irig106.org/ (visited on 04/23/2016).

[10] L.L Peterson and B.S Davie. "Computer Networks, Third Edition:A Systems Approach, 3rd Edition (The Morgan Kaufmann Seriesin Networking)". Kaufmann, M, 2003. ISBN: 155860832X.

[11] T.A Bekkeng. “"Prototype Development of a Multi-Needle Lang-muir Probe System"”. MA thesis. University of Oslo, May 2009.

81

Bibliography 82

[12] T.A Bekkeng et al. “"Design of a multi-needle Langmuir probesystem"”. In: Measurement Science and Technology 21.8 (2010),p. 085903. URL: http://stacks . iop.org/0957- 0233/21/ i=8/a=085903.

[13] K.S Jacobsen et al. “"A new Langmuir probe concept for rapidsampling of space plasma electron density"”. In: MeasurementScience and Technology 21.8 (2010), p. 085902. URL: http://stacks.iop.org/0957-0233/21/i=8/a=085902.

[14] M Sollien. “"Prototypeutvikling av digital solsensor for sonder-aketter"”. MA thesis. University of Oslo, 2006.

[15] J.K Bekkeng, W Booij, and J.I Moen. “"Development of minia-turised low cost attitude determination system for sounding rock-ets"”. In: 17th ESA Symposium on European Rocket and BalloonProgrammes and Related Research. Vol. 590. 2005, pp. 281–286.

[16] J.R Wertz. "Spacecraft Attitude Determination and Control".Springer, 1978. ISBN: 9027709599.

[17] B.A Furevik. “"A Measurement System For Attitude Determina-tion on Sounding Rockets"”. MA thesis. University of Oslo, Aug.2013.

[18] M Nelson and J-L Gailly. "The data compression book". Vol. 2.M&t Books New York, 1996.

[19] D Salomon. "A concise introduction to data compression".Springer Science & Business Media, 2007.

[20] R Logeswaran and C Eswaran. “"Performance survey of severallossless compression algorithms for telemetry applications"”. In:International Journal of Computers and Applications 23.1 (2001),pp. 1–9.

[21] M. Morris Mano and M.D Ciletti. "Digital Design with andintroduction to the Verilog HDL (5th Edition)". Pearson, 2013.ISBN: 978-0-273-76452-6.

[22] M Zwolinski. "Digital System Design with VHDL (2nd Edition)".Pearson, 2004. ISBN: 013039985X.

[23] Terasic. "Cyclone 5 DE1-SoC Resources". URL: http : / / www .terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=836&PartNo=4 (visited on 02/11/2016).

[24] A Feldspar. An explentaion of the DEFLATE algorithm. Online.URL: http://www.gzip.org/deflate.html (visited on 05/01/2016).

Appendix A

Pictures

Figure A.1: mNLP FPGA and PCB

83

Appendix A. Pictures 84

Appendix B

Matlab code

B.1 Encode 1

1 function [res] = encode1(x, cons, counter_max)2 % Compress deltas with encode1 algorithm34 numb_bits = 16; % ADC bit size5 s = numb_bits; % Starting bit size67 sign = dec2bin(2^(32) - 2, 32); % Frame size89 ref = uint32(x(1)); % First reference value

10 prev = ref; % Old reference = first reference1112 res = [sign dec2bin(s-1,4)]; % Send 44 bit sign and 4 bit size13 res = [res dec2bin(1, 12)]; % Frame ID counter14 res = [res dec2bin(ref, numb_bits)];% Send 16 bit reference value.15 res = [res dec2bin(ref, numb_bits)];% Send 16 bit reference value again.16 signals = 1; % Frame counter17 frameID = 1; % Frame ID1819 c = 0; % Counter for sequence of small deltas20 i = 2; % Input value index21 counter = 0; % Frame deltas counter2223 length = size(x,2); % Number of inputs242526 while (i <= length)2728 % Construct new frame29 if (counter >= counter_max)30 signals = signals + 1; % Update frame counter3132 % Update frame ID33 frameID = frameID + 1;34 if frameID > (2^12-1)35 frameID = 0;36 end3738 % Add new frame39 res = [res sign]; % Frame signal40 res = [res dec2bin(s-1,4)]; % Current bit size41 res = [res dec2bin(frameID,12)];% Frame ID42 res = [res dec2bin(ref,16)]; % Old reference4344 % Update reference values45 prev = ref;46 ref = uint32(x(i));

85

Appendix B. Matlab code 86

47 res = [res dec2bin(ref,16)]; % New reference4849 counter = 0; % Reset frame delta counter50 else51 % Calculate delta52 d = int32(x(i)) - int32(ref);5354 % Delta to large for 1’s complement55 if (abs(d) >= (2^(15)))56 i = i - 1;57 counter = counter_max;58 c = 0;59 s = 16;6061 % Delta to large, increase bit size62 elseif ( abs(d) >= (2^(s-1)-1) ) & (s < numb_bits)63 res = [ res dec2bin(2^(s-1)-1,s)]; % Send pos.max with

current bit size64 s = s + 1; % Inc bit size65 res = [ res dec2bin(2^(s-1)-1,s)]; % Send pos.max with new

bit size66 i = i - 1;67 c = 0;6869 % Delta size ok70 else71 % Update counter for deltas in frame72 counter = counter + 1;7374 % Negative delta 1’s complement75 if ( d < 0 )76 neg = dec2bin(2^(s)+d-1, s);77 res = [res neg];78 % Positive delta79 else80 res = [ res dec2bin(d,s)];81 end;8283 % Check if delta could be coded with less bits84 if (abs(d) < (2^(s-2)-1)) | (d == 0)85 c = c + 1;86 else87 c = 0;88 end;8990 % Check for series of small deltas91 if (c >= cons) & (s > 2)92 res = [ res dec2bin(2^(s-1),s)]; % Send neg.max with

current bit size93 s = s - 1; % Reduce bit size94 res = [ res dec2bin(2^(s-1),s)]; % Send neg.max with

new bit size95 c = 0;96 end97 end;98 end99 i = i + 1;

100 end;

87 B.2. Encode 2

B.2 Encode 2

1 function [res] = encode2(x, cons, counter_max)2 % Compress deltas with encode2 algorithm34 numb_bits = 16; % ADC bit size5 s = numb_bits; % Starting bit size67 sign = dec2bin(2^(32) - 2, 32);% Frame signal89 res = [sign dec2bin(s-1,4)]; % Send 44 bit sign and 4 bit size

10 res = [res dec2bin(1, 12)]; % Frame ID counter11 res = [res dec2bin(x(1), numb_bits)]; % Send 16 bit reference value.1213 signals = 1; % Number of frames in stream14 frameID = 1; % Frame ID15 c = 0; % Counter for sequence of small deltas16 i = 2; % Input value index17 counter = 0; % Frame deltas counter1819 length = size(x,2);% Number of inputs20 %ind = 2;2122 while (i <= size(x,2))2324 % Construct new frame25 if counter >= (counter_max + 1)26 counter = 0; % Reset deltas in frame counter27 signals = signals + 1; % Update frame counter28 i = i - 1;2930 % Update frame ID counter31 frameID = frameID + 1;32 if frameID > (2^12-1)33 frameID = 0;34 end3536 res = [res sign]; % Add frame signal37 res = [res dec2bin(s-1,4)]; % Add current bit size38 res = [res dec2bin(frameID,12)];% Add frame ID39 res = [res dec2bin(x(i),16)]; % Add absolute value of last delta40 else41 % Calculate new delta42 d = int32(x(i)) - int32(x(i-1));4344 % Delta to large, increase bit size45 if ( abs(d) >= (2^(s-1)-1) ) & (s < numb_bits)46 res = [ res dec2bin(2^(s-1)-1,s)]; % Send pos.max with

current bit size47 s = s + 1; % Inc bit size48 res = [ res dec2bin(2^(s-1)-1,s)]; % Send pos.max with new

bit size49 i = i - 1;50 c = 0;5152 % Delta size ok53 else54 counter = counter + 1; % Update delta counter5556 % Negative delta 1’s complement57 if ( d < 0 )58 neg = dec2bin(2^(s)+d-1, s);5960 % Check if maximum bit size is reached61 if size(neg,2) > 1562 neg = neg(1:16);63 end


64 res = [res neg]; % Send delta65 % Positive delta66 else67 pos = dec2bin(d, s);6869 % Check if maximum bit size is reached70 if size(pos,2) > 1571 pos = pos(1:16);72 end73 res = [ res pos]; % Send positive number s bit74 end;7576 % Check if delta could be coded with less bits77 if (abs(d) < (2^(s-2)-1))78 c = c + 1;79 else80 c = 0;81 end;8283 % check for series of small diff84 if (c >= cons) & (s > 2)85 res = [ res dec2bin(2^(s-1),s)]; % Send neg.max with

current bit size86 s = s - 1; % Reduce bit size87 res = [ res dec2bin(2^(s-1),s)]; % Send neg.max with

new bit size88 c = 0;89 end90 end;91 end92 i = i + 1;93 end;

89 B.3. Decode 1

B.3 Decode 1

1 function [y]=decode1(res)2 % Decompress encode1 binary stream34 s = 16; % Starting bit size5 sign = dec2bin(2^(32) - 2); % Frame header signal67 y = 0; % Decompressed array8 len = size(res,2); % Size of compressed binary stream9

10 j = 1; % Index for storing numbers11 c = 0; % Counter for sequence of small deltas12 k = dec2bin(0, 32); % Sign search string set to zeros13 i = 1; % Start at beginning14 signalID = 0; % frame ID15 oldID = 0;16 firstRun = true;1718 signals = 0; % Frames counter19 frame_size = 500; % Fame size20 deltas = 500; % Found deltas, init value21 lost_deltas = 0; % Lost deltas22 old_ref = 0;2324 % Loop compressed stream25 while (i + s - 1 ) <= len2627 if (i + 31) <= len % Search for sign string28 k = res(i:i + 31);29 end3031 if k == sign32 signals = signals + 1; % Count signals found3334 if oldID == (2^12-2)35 oldID = -1;36 else37 oldID = oldID + 1;38 end3940 i = i + 32; % Jump to bit size index4142 s = uint32(bin2dec(res(i:i+3))) + 1; % Read bit size (size_bits

bit)43 i = i + 4;44 signalID = bin2dec(res(i:i+11));45 i = i + 12;46 ref = uint32(bin2dec(res(i:(i+15)))); % Read old reference value (

numb_bits bit)47 old_ref = ref;48 i = i + 16; % Jump numb_bits bits

further in stream readout49 ref = uint32(bin2dec(res(i:(i+15)))); % Read new reference value (

numb_bits bit)50 y(j) = ref;5152 % Workaround for first frame header53 if firstRun54 firstRun = false;55 oldID = signalID - 1;56 end5758 if oldID ~= signalID-159 fprintf(’Missing frame! Old frame:%i, new frame:%i\n’, oldID,

signalID);60 break;


61 elseif deltas ~= frame_size62 fprintf(’Number of lost deltas : %i\n’, (frame_size-deltas));63 while (deltas < frame_size)64 y(j) = old_ref;65 j = j + 1;66 deltas = deltas + 1;67 end68 break;69 end7071 deltas = 0; % Reset found deltas found inside frame72 j = j + 1; % Prep for next number to be stored73 i = i + 16; % Advance in bit stream7475 elseif deltas <= frame_size76 % Positive maximum found, increase bit size77 if (uint32(bin2dec(res(i:i+s-1))) == (2^(s-1)-1))78 i = i + s;79 s = s + 1;80 i = i + s;8182 % Negative maximum found, decrease bit size83 elseif (uint32(bin2dec(res(i:i+s-1))) == (2^(s-1)))84 i = i + s;85 s = s - 1;86 i = i + s;8788 % Proceed with reading numbers with current bit size89 else90 % Read delta91 d = uint32(bin2dec(res(i:(i+s-1))));9293 % Negative delta94 if res(i) == ’1’95 d_neg = uint32(2^(s) - d - 1);96 y(j) = uint32(ref) - d_neg;97 % Positive delta98 else99 y(j) = int32(ref) + int32(d);

100 end101102 % Update counters103 deltas = deltas + 1;104 j = j + 1;105106 % Check if frame header is in the S next bits107 g = i + s;108 while i < g & (g+31 < len)109 if sign == res(i:i+31)110 g = i;111 end112 i = i + 1;113 end114 end115 else116 i = i + 1;117 end;118119 % Check for to many deltas in frame120 if deltas > frame_size121 fprintf(’Delta count exceed limit in frame %i\n’, signalID);122 break;123 end124 end;125126 y = uint32(y);127 fprintf(’%i: Number of frames found : %i\n’, i, signals);

91 B.4. Decode 2

B.4 Decode 2

1 function [y]=decode2(res)2 % Decompress encode2 binary stream34 s = 16; % Starting bit size5 sign = dec2bin(2^(32) - 2);% Frame signal67 y = 0; % Decompressed array8 len = size(res,2); % Size of input data9

10 j = 1; % Decompressed index11 k = dec2bin(0, 32); % Frame sign search string12 i = 1; % Stream index13 frameID = 0; % Current frame ID14 signals = 0; % Found frame counter1516 % Loop compressed stream17 while (i + s - 1 ) <= len1819 % Read stream20 if (i+31) <= len21 k = res(i:i+31);22 end2324 % Check if frame signal found25 if k == sign26 % Advance in bit stream27 i = i + 32;2829 s = uint32(bin2dec(res(i:i+3))) + 1; % Current bit size30 i = i + 4;31 frameID = uint32(bin2dec(res(i:i+11))); % Frame ID32 i = i + 12;3334 % Check for delta calculate error35 if j > 236 ref = uint32(bin2dec(res(i:(i+15)))); % Reference, goal of last

delta37 if y(j-1) ~= ref38 fprintf(’Error in frame %i: %i %i\n’, frameID, y(j-1), ref

);39 break;40 end;41 % First frame42 else43 y(j) = uint32(bin2dec(res(i:(i+15))));44 j = j + 1;45 end;4647 % Update counters and index48 signals = signals + 1;49 i = i + 16;5051 else52 % Positive maximum found, increase bit size53 if uint16(bin2dec(res(i:i+s-1)))==(2^(s-1)-1)54 i = i + s;55 s = s + 1;56 i = i + s;57 j = j - 1;5859 % Negative maximum found, decrease bit size60 elseif uint16(res(i:i+s-1)==dec2bin(2^(s-1),s))61 i = i + s;62 s = s - 1;63 i = i + s;


64 j = j - 1;6566 % Proceed with reading numbers with current bit size67 else68 % Read delta69 d = uint32(bin2dec(res(i:(i+s-1))));7071 % Negative delta72 if res(i) == ’1’73 y(j) = y(j-1);74 tmp = dec2bin(2^(s)-d-1, s);75 d = uint32(bin2dec(tmp));76 y(j) = y(j) - d;77 % Positive delta78 else79 y(j) = y(j-1);80 y(j) = y(j) + d;81 end8283 % Advance in stream84 i = i + s;85 end8687 % Update decompressed array index88 j = j + 1;89 end;90 end;9192 y = uint16(y);93 fprintf(1,’Number of frames found : %i\n’, signals);

93 B.5. Encode Prediction

B.5 Encode Prediction

1 function [res] = encodePredict(x, cons, counter_max)2 % Compress deltas with prediction based algorithm34 length = size(x,2);5 s = 16;67 ref = x(1);8 prev = ref;9 sign = dec2bin(2^32-2, 32);

1011 res = [sign dec2bin(s-1,4)];12 res = [res ’000000000000’];13 res = [res dec2bin(ref, s)];14 res = [res dec2bin(ref, s)];1516 counter = 0;17 c = 0;18 i = 2;19 sent = x(1);20 arr = [sent sent sent];2122 while (i <= length-1)2324 if counter == counter_max25 % Send old reference again (as backup)26 res = [res sign]; % Add sign 32 bit sign.27 res = [res dec2bin(s-1,4)]; % Send 4 bit current bit size28 res = [res ’000000000000’]; % pack with 0s to get 16 bit.29 res = [res dec2bin(ref,16)]; % Send reference as 16 bit.3031 prev = ref; % Reference set as previous3233 % Get and send a new reference34 ref = x(i);35 res = [res dec2bin(ref,16)];3637 % Update counters38 counter = 0;39 arr = [arr(2) arr(3) x(i)];40 else4142 % Calculate movement 2 steps behind43 dist1 = int32(arr(2)) - int32(arr(1));44 dist2 = int32(arr(3)) - int32(arr(2));45 predict = int32(dist2) - int32(dist1);46 predict = round(predict / 2);4748 actual = int32(x(i)) - int32(x(i-1));4950 % Calculate miss51 sent = int32(actual) - int32(predict);5253 if ( abs(sent) >= (2^(s-1)-1) )54 if s >= 1655 counter = counter_max;56 i = i - 1;57 else58 posmax = dec2bin(2^(s-1)-1,s);59 res = [ res posmax];60 s = s + 1;61 posmax = dec2bin(2^(s-1)-1,s);62 res = [ res posmax];63 i = i - 1;64 c = 0;65 end


66 else67 if ( sent < 0 )68 neg = dec2bin(2^(s)+sent-1, s);69 res = [res neg];70 else71 pos = dec2bin(sent,s);72 res = [ res pos];73 end;7475 if (abs(sent) < (2^(s-2)-1))76 c = c + 1;77 else78 c = 0;79 end;80 %fprintf(’%i : actual=%i sent=%i predict=%i dist1=%i dist2=%i

lagret=%i [%i %i %i] s=%i res=%s\n’, i, actual, sent,predict, dist1, dist2, x(i), arr(1), arr(2), arr(3), s,res(size(res,2)-s+1: size(res,2)));

8182 if c >= cons83 res = [ res dec2bin(2^(s-1),s)];84 s = s - 1;85 res = [ res dec2bin(2^(s-1),s)];86 c = 0;87 end;8889 arr = [arr(2) arr(3) x(i)];90 end;91 end92 i = i + 1;93 end;

95 B.6. Decode Prediction

B.6 Decode Prediction

1 function [y]=decodePredics(res)2 % Decompress prediction based compressed binary stream34 y = 0; % Decompressed array5 len = size(res,2);% Size of data stream67 sign = dec2bin(2^32-2, 32);% Frame signal8 k = dec2bin(0, 32); % Sign search string set to zeros9

10 j = 1; % Decompressed index11 s = 16; % Starting bit size12 i = 1; % Stream index1314 first = 1; % First frame indicator1516 % Loop data stream17 while (i + s - 1 ) <= len1819 % Read 32 bit from data stream20 if (i+31) <= len21 k = res(i:i+31); %Store data in search string22 end2324 % Frame found in stream25 if k == sign26 i = i + 32; % Jump to bit size index2728 s = uint32(bin2dec(res(i:i+3))) + 1; % Read bit size (4 bit)2930 i = i + 16; % Jump to reference value

index31 ref = uint32(bin2dec(res(i:(i+15)))); % Read old reference value

(16 bit)32 i = i + 16; % Jump 16 bits further in

stream readout33 ref = uint32(bin2dec(res(i:(i+15)))); % Read new reference value

(16 bit)34 y(j) = ref;3536 % Update memory37 if first == 138 arr = [y(j) y(j) y(j)];39 first = 0;40 else41 arr = [arr(2) arr(3) y(j)];42 end4344 % Advance in stream and update index45 j = j + 1; % Prep for next number to

be stored46 i = i + 16; % Jump 16 bits further in

bit stream4748 else49 % Positive maximum, increase bit size50 if uint16(bin2dec(res(i:i+s-1)))==(2^(s-1)-1)51 i = i + s;52 s = s + 1;53 i = i + s;54 j = j - 1;55 % Negative maximum, decrease bit size56 elseif uint16(res(i:i+s-1)==dec2bin(2^(s-1),s))57 i = i + s;58 s = s - 1;59 i = i + s;


60 j = j - 1;61 else62 % Predict movement63 dist1 = int32(arr(2)) - int32(arr(1));64 dist2 = int32(arr(3)) - int32(arr(2));65 predict = int32(dist2) - int32(dist1);66 predict = round(predict / 2);6768 % Read delta69 sent = uint32(bin2dec(res(i:(i+s-1))));7071 % 1’s complement negative72 if res(i) == ’1’73 sent = (-1)*int32(2^(s) - sent - 1);74 end7576 % Calculate from predicted and delta77 actual = int32(predict) + int32(sent);78 y(j) = int32(y(j-1) + actual);7980 % Advance in stream and update memory81 i = i + s;82 arr = [arr(2) arr(3) y(j)];83 end84 j = j + 1;85 end86 end;8788 y = uint16(y);

Appendix C

Program code

C.1 VHDL

C.1.1 Encoder

1 --------------------------------------------------------2 -- Filename : encoder.vhd3 -- Author : Marius Elvegaard4 -- Date : 02.05.20165 -- Description : connects internal signals to sub6 -- modules.7 --------------------------------------------------------89 library ieee;

10 use ieee.std_logic_1164.all;11 use ieee.std_logic_unsigned.all;12 use ieee.numeric_std.all;13 use ieee.std_logic_signed.all;141516 entity encoder is17 port (18 CLK : in std_logic;19 ENABLE : in std_logic;20 RESET : in std_logic;21 WR : in std_logic;22 RD : in std_logic;23 DataIn : in std_logic_vector( 15 downto 0 );24 DataOut : out std_logic_vector( 15 downto 0 );25 FAIL : out std_logic;26 READY : out std_logic27 );28 end encoder;293031 architecture Behavioral of encoder is3233 --******************************************************34 -- SIGNAL DECLARATION35 --******************************************************36 signal s : std_logic_vector(3 downto 0); -- bit

size3738 signal output_f : std_logic_vector(15 downto 0);-- FIFO

output39 signal output_dh : std_logic_vector(15 downto 0);-- Data

Handler40 -- output

97

Appendix C. Program code 98

41 signal output_w : std_logic_vector(15 downto 0);-- Wrapperoutput

4243 signal rd1, rd2, wr1, wr2 : std_logic; -- FIFO read and write

signals44 signal full1, full2 : std_logic; -- FIFO full signals45 signal empty1, empty2 : std_logic; -- FIFO empty signals46 signal valid_dh : std_logic; -- Data Handler valid signal47 signal ready_w : std_logic; -- Wrapper output ready

signal484950 --******************************************************51 -- COMPONENT DECLARATION52 --******************************************************5354 -- FIFO55 component FIFO56 port(57 CLK : in STD_LOGIC;58 RESET : in STD_LOGIC;59 WR : in STD_LOGIC;60 RD : in STD_LOGIC;61 DATAIN : in STD_LOGIC_VECTOR(15 downto 0);62 DATAOUT : out STD_LOGIC_VECTOR(15 downto 0);63 EMPTY : out STD_LOGIC;64 FULL : out STD_LOGIC65 );66 end component FIFO;676869 -- DATA HANDLER70 component DATAHANDLER71 port(72 CLK : in STD_LOGIC;73 RESET : in STD_LOGIC;74 ENABLE : in STD_LOGIC;75 FULL : in STD_LOGIC;76 EMPTY : in STD_LOGIC;77 DATAIN : in STD_LOGIC_VECTOR(15 downto 0);78 s : out STD_LOGIC_VECTOR(3 downto 0);79 DATAOUT : out STD_LOGIC_VECTOR(15 downto 0);80 READY : out STD_LOGIC;81 RD : out STD_LOGIC82 );83 end component DATAHANDLER;848586 -- WRAPPER87 component WRAPPER88 port(89 CLK : in STD_LOGIC;90 RESET : in STD_LOGIC;91 DATAIN : in STD_LOGIC_VECTOR(15 downto 0);92 S : in STD_LOGIC_VECTOR(3 downto 0);93 VALID : in STD_LOGIC;94 READY : out STD_LOGIC;95 DATAOUT : out STD_LOGIC_VECTOR(15 downto 0)96 );97 end component WRAPPER;9899

100 begin101 --******************************************************102 -- COMBINATIONAL LOGIC103 --******************************************************104 READY <= not empty2;105 FAIL <= ’0’ when RESET = ’1’ else ’1’ when FULL1=’1’ or FULL2=’1’ else

99 C.1. VHDL

’0’;106107108109 --******************************************************110 -- PORT MAPPING111 --******************************************************112 U1 : FIFO port map(113 CLK => CLK,114 RESET => RESET,115 WR => WR,116 RD => RD1,117 DATAIN => DataIn,118 DATAOUT => output_f,119 EMPTY => empty1,120 FULL => full1121 );122123124 U2 : DATAHANDLER port map(125 CLK => CLK,126 RESET => RESET,127 ENABLE => ENABLE,128 FULL => full1,129 EMPTY => empty1,130 DATAIN => output_f,131 S => s,132 DATAOUT => output_dh,133 READY => valid_dh,134 RD => rd1135 );136137 U3 : WRAPPER port map(138 CLK => CLK,139 RESET => RESET,140 DATAIN => output_dh,141 S => s,142 VALID => valid_dh,143 READY => ready_w,144 DATAOUT => output_w145 );146147 U4 : FIFO port map(148 CLK => CLK,149 RESET => RESET,150 WR => ready_w,151 RD => RD,152 DATAIN => output_w,153 DATAOUT => DataOut,154 EMPTY => empty2,155 FULL => full2156 );157158159 end Behavioral;


C.1.2 FIFO

1 --------------------------------------------------------2 -- Filename : fifo.vhd3 -- Author : Marius Elvegaard4 -- Date : 02.05.20165 -- Description : Single clock FIFO memory buffer.6 --------------------------------------------------------78 library IEEE;9 USE IEEE.STD_LOGIC_1164.ALL;

10 USE IEEE.NUMERIC_STD.ALL;11121314 entity FIFO is15 Generic (16 constant DATA_WIDTH : positive := 16; -- element size17 constant FIFO_DEPTH : positive := 100 -- memory depth18 );19 Port (20 CLK : in STD_LOGIC;21 RESET : in STD_LOGIC;22 WR : in STD_LOGIC;23 RD : in STD_LOGIC;24 DATAIN : in STD_LOGIC_VECTOR (DATA_WIDTH - 1 downto 0);25 DATAOUT : out STD_LOGIC_VECTOR (DATA_WIDTH - 1 downto 0);26 EMPTY : out STD_LOGIC;27 FULL : out STD_LOGIC28 );29 end FIFO;303132 architecture Behavioral of FIFO is3334 begin35363738 --******************************************************39 -- FIFO process40 --******************************************************41 process (CLK)4243 --------------------------------------------------------44 -- SIGNAL DECLARATION45 --------------------------------------------------------46 type FIFO_MEM is array(0 to FIFO_DEPTH-1) of STD_LOGIC_VECTOR(

DATA_WIDTH-1 downto 0);47 variable MEM : FIFO_MEM; -- memory4849 variable LOOPED : BOOLEAN := FALSE; -- FIFO looped50 variable HEAD : INTEGER := 0; -- head pointer51 variable TAIL : INTEGER := 0; -- tail pointer525354 begin55 if rising_edge(CLK) then56 if RESET = ’1’ then57 HEAD := 0;58 TAIL := 0;59 EMPTY <= ’1’;60 FULL <= ’0’;61 LOOPED := FALSE;62 MEM(0) := (others => ’0’);63 DATAOUT <= (others => ’0’);64 else65

101 C.1. VHDL

66 ---------------------------67 -- WRITE68 ---------------------------69 if WR = ’1’ then70 if ((not LOOPED) or (HEAD /= TAIL)) then71 MEM(head) := DATAIN;72 if (HEAD = FIFO_DEPTH-1) then73 HEAD := 0;74 LOOPED := TRUE;75 else76 HEAD := HEAD + 1;77 end if;78 end if;79 end if;8081 ---------------------------82 -- READ83 ---------------------------84 if RD = ’1’ then85 if ((LOOPED) or (HEAD /= TAIL)) then86 DATAOUT <= MEM(tail);87 if (TAIL = FIFO_DEPTH-1) then88 LOOPED := FALSE;89 TAIL := 0;90 else91 TAIL := TAIL + 1;92 end if;93 end if;94 end if;9596 ---------------------------97 -- UPDATE FULL and EMPTY98 -- signals.99 ---------------------------

100 if (HEAD = TAIL) then101 if LOOPED then102 FULL <= ’1’;103 else104 EMPTY <= ’1’;105 end if;106 else107 EMPTY <= ’0’;108 FULL <= ’0’;109 end if;110111 end if;112 end if;113 end process;114115116 end Behavioral;


C.1.3 Data Handler

1 --------------------------------------------------------2 -- Filename : DataHandler.vhd3 -- Author : Marius Elvegaard4 -- Date : 02.05.20165 -- Description : Calculates delta values and adds6 -- necessary information to data stream.7 --------------------------------------------------------89 library ieee;

10 use ieee.std_logic_1164.all;11 use ieee.std_logic_unsigned.all;12 use ieee.numeric_std.all;13 use ieee.std_logic_signed.all;14151617 entity datahandler is18 port (19 CLK : in STD_LOGIC;20 RESET : in STD_LOGIC;21 ENABLE : in STD_LOGIC;22 FULL : in STD_LOGIC;23 EMPTY : in STD_LOGIC;24 DATAIN : in STD_LOGIC_VECTOR(15 downto 0);25 S : out STD_LOGIC_VECTOR(3 downto 0);26 DATAOUT : out STD_LOGIC_VECTOR(15 downto 0);27 READY : out STD_LOGIC;28 RD : out STD_LOGIC29 );30 end datahandler;31323334 architecture Behavioral of datahandler is3536 --******************************************************37 -- CONSTANT DECLARATION38 --******************************************************39 constant minbits : integer := 0;40 constant counter_max : integer := 1000;41 constant c_max : integer := 20;42 constant sign : std_logic_vector(31 downto 0) := x"FFFFFFFE";4344 --******************************************************45 -- SIGNAL DECLARATION46 --******************************************************47 -- State machine signals48 type state_type is (idle_state, signal_state, counter_state,49 down_state, new_state, up_state, large_diff);50 signal current_state, next_state : state_type;5152 -- Internal signals53 signal DataIn_i : std_logic_vector(15 downto 0); -- input data54 signal DataOut_i : std_logic_vector(15 downto 0); -- output data55 signal VALID_i : std_logic; -- output valid56 signal RD_i : std_logic; -- FIFO RD57 signal counter : integer; -- deltas in

frame58 signal c : integer; -- sequential

counter59 signal delta : integer; -- current delta60 signal delta_stored : integer; -- stored delta61 signal prevref : std_logic_vector(15 downto 0); -- old reference62 signal newref : std_logic_vector(15 downto 0); -- new reference63 signal bits : integer; -- current size64 signal bits_stored : integer := 0; -- last bitsize

103 C.1. VHDL

65 signal input_stored : std_logic_vector(15 downto 0);6667 signal loops : integer := 0; -- internal counter68 signal frameID : integer := 0; -- frame ID counter69 signal bitsback : boolean := False; -- restore bit size signal70 signal firstRun : boolean := True; -- first frame signal71727374 --******************************************************75 -- FUNCTIONS76 --******************************************************7778 --------------------------------------------------------79 -- Produce 1’s complement maximum80 -- Outputs positive max if number = -181 -- Outputs negative max if number = 082 -- Maximum value in b number of bits83 --------------------------------------------------------84 function sendmax(b : in integer; number : in integer) return

std_logic_vector is85 begin86 return std_logic_vector(to_signed(2**(b)+number, DataOut’length));87 end sendmax;888990 --------------------------------------------------------91 -- Check and return updated value for sequally small92 -- numbers counter.93 --------------------------------------------------------94 function checkC(delta : in integer; bitsize : in integer; c : in integer

) return integer is95 begin96 -- positive numbers97 if delta >= 0 then98 if delta < (2**(bitsize-1)-1) and c < (c_max-1) then99 return (c + 1);

100 else101 return 0;102 end if;103 -- negative numbers104 else105 if delta > (-(2**(bitsize-1))) and c < (c_max-1) then106 return (c + 1);107 else108 return 0;109 end if;110 end if;111 end checkC;112113 --------------------------------------------------------114 -- Check if delta is to large for current bitsize115 --------------------------------------------------------116 function checkLarge(delta : in integer; bitsize : in integer) return

boolean is117 begin118 if (delta >= 0) then -- positive delta119 if (delta >= (2**(bitsize)-1)) then120 return true;121 else122 return false;123 end if;124 else125 if delta <= (-(2**(bitsize))) then126 return true;127 else128 return false;129 end if;


130 end if;131 end checkLarge;132133134 --------------------------------------------------------135 -- Check if delta can use a smaller bitsize136 --------------------------------------------------------137 function checkSmall(delta : in integer; bitsize : in integer) return

boolean is138 begin139 if (delta >= 0) then -- positive delta140 if (delta < (2**(bitsize-1)-1)) then141 return true;142 else143 return false;144 end if;145 else146 if delta > (-(2**(bitsize-1))) then147 return true;148 else149 return false;150 end if;151 end if;152 end checkSmall;153154155 --------------------------------------------------------156 -- Calculate 1’s complement negateive deltas with157 -- workaround for large numbers.158 --------------------------------------------------------159 function calcDelta(inval : std_logic_vector; refval : std_logic_vector)

return integer is160 begin161 -- input = ref162 if to_integer(unsigned(inval)) = to_integer(unsigned(refval)) then163 return 0;164165 -- input > ref166 elsif to_integer(unsigned(inval)) > to_integer(unsigned(refval))

then167 if signed(unsigned(inval)-unsigned(refval)) < 0 then168 return 2**(15);169 else170 return to_integer(signed(unsigned(inval) - unsigned(refval)));171 end if;172173 -- input < ref174 else175 if signed(unsigned(inval)-unsigned(refval)) >= 0 then176 return -2**(15);177 else178 return to_integer(signed(unsigned(inval) - unsigned(refval))-1);179 end if;180 end if;181 end calcDelta;182183184185186187188 begin189190191 --******************************************************192 -- COMBINATIONAL LOGIC193 --******************************************************194

105 C.1. VHDL

195 -- Read from input FIFO196 RD <= ’0’ when RESET = ’1’ else197 RD_i when (EMPTY = ’0’) else ’0’;198199 -- output to wrapper200 DATAOUT <= (others => ’0’) when RESET = ’1’ else201 DataOut_i when (ENABLE = ’1’) else (others => ’0’);202203 -- number of valid bits in output204 S <= "1111" when RESET = ’1’ else205 std_logic_vector(to_signed(bits, 4)) when ENABLE = ’1’ else

"1111";206207 -- valid value on output208 READY <= ’0’ when RESET = ’1’ else209 VALID_i when (ENABLE = ’1’) and (EMPTY = ’0’) else ’0’;210211212 -- calculation of delta213 delta <= 0 when RESET = ’1’ else214 calcDelta(DataIn, newref) when ENABLE = ’1’ else 0;215216217218219 --******************************************************220 -- STATE MACHINE PROCESS221 --******************************************************222 TIMING:process (CLK)223 begin224 if rising_edge(CLK) then225 if reset = ’1’ then226 input_stored <= (others => ’0’);227 frameID <= 0;228 c <= 0;229 counter <= 0;230 bits <= 15;231 loops <= 0;232 DataOut_i <= (others => ’0’);233 RD_i <= ’0’;234 VALID_i <= ’0’;235 newref <= (others => ’0’);236 prevref <= (others => ’0’);237 next_state <= idle_state;238 bitsback <= False;239 firstRun <= True;240 elsif ENABLE = ’1’ and EMPTY = ’0’ then241 RD_i <= ’0’;242 VALID_i <= ’0’;243244245 --*********************246 -- STATE MACHINE247 --*********************248 case next_state is249250 ----------------------251 -- IDLE STATE252 ----------------------253 when idle_state =>254 next_state <= idle_state;255 if EMPTY = ’0’ then256 RD_i <= ’1’;257 next_state <= signal_state;258 end if;259260 ----------------------261 -- SIGNAL STATE


262 ----------------------263 when signal_state =>264 next_state <= signal_state;265 loops <= loops + 1;266 VALID_i <= ’1’;267 RD_i <= ’0’;268 counter <= 0;269270 case loops is271 when 0 =>272 bits_stored <= bits;273 bits <= 15;274 frameID <= frameID + 1;275 DataOut_i <= sign(31 downto 16);276277 when 1 =>278 DataOut_i <= sign(15 downto 0);279 if (firstRun) then280 prevref <= DATAIN;281 newref <= DATAIN;282 else283 prevref <= newref;284 newref <= DataIn;285 end if;286287 when 2 =>288 RD_i <= ’1’;289 if (firstRun) then290 DataOut_i <= std_logic_vector(to_signed(bits, 4)) &

std_logic_vector(to_signed(frameID, 12));291 else292 DataOut_i <= std_logic_vector(to_signed(bits_stored

,4)) & std_logic_vector(to_signed(frameID, 12));293 end if;294295 when 3 =>296 DataOut_i <= prevref;297298 when 4 =>299 next_state <= counter_state;300 DataOut_i <= newref;301 if (firstRun) then302 RD_i <= ’1’;303 bits_stored <= bits;304 delta_stored <= delta;305 firstRun <= False;306 else307 bitsback <= True;308 delta_stored <= delta;309310 if checkLarge(delta_stored, bits_stored) then311 RD_i <= ’0’;312 else313 RD_i <= ’1’;314 end if;315 end if;316317 when others =>318 VALID_i <= ’0’;319 null;320 end case;321322323 --------------------324 -- COUNTER STATE325 --------------------326 when counter_state =>327 counter <= counter + 1;

107 C.1. VHDL

328 next_state <= counter_state;329 VALID_i <= ’1’;330 DataOut_i <= std_logic_vector(to_signed(delta, 16));331 RD_i <= ’1’;332 loops <= 0;333334335 if bitsback then336 bits <= bits_stored;337 bitsback <= False;338 c <= checkC(delta_stored, bits_stored, c);339 else340 c <= checkC(delta, bits, c);341 end if;342343 delta_stored <= delta;344345 -- Check if frame filled up346 if ( counter >= (counter_max-1) ) then347 RD_i <= ’0’;348 if checkLarge( delta, bits ) then349 DataOut_i <= sendmax(bits, -1);350 next_state <= up_state;351 elsif ( c >= (c_max-1) ) and checkSmall( delta, bits )

then352 next_state <= down_state;353 else354 input_stored <= DataIn;355 prevref <= newref;356 next_state <= signal_state;357 end if;358359 else360 if not bitsback then361 -- Small delta362 if checkSmall( delta, bits ) then363 if c >= c_max-1 and bits > 1 then364 RD_i <= ’0’;365 next_state <= down_state;366 end if;367 -- To larg delta368 elsif abs(delta) >= 2**(15) then369 frameID <= frameID + 1;370 bits_stored <= 15;371 bits <= 15;372 RD_i <= ’0’;373 DataOut_i <= sign(31 downto 16);374 prevref <= newref;375 newref <= DataIn;376 next_state <= large_diff;377 -- Large delta378 elsif checkLarge(delta, bits) then379 RD_i <= ’0’;380 input_stored <= DataIn;381 DataOut_i <= sendmax(bits, -1);382 next_state <= up_state;383 end if;384 else385 -- Small delta386 if checkSmall( delta_stored, bits_stored ) then387 if c >= c_max-1 and bits_stored > 1 then388 RD_i <= ’0’;389 next_state <= down_state;390 end if;391 -- To large delta392 elsif abs(delta_stored) >= 2**(15) then393 frameID <= frameID + 1;394 bits_stored <= 15;


395 bits <= 15;396 RD_i <= ’0’;397 DataOut_i <= sign(31 downto 16);398 prevref <= newref;399 newref <= DataIn;400 next_state <= large_diff;401 -- Large delta402 elsif checkLarge(delta_stored, bits_stored) then403 RD_i <= ’0’;404 input_stored <= DataIn;405 DataOut_i <= sendmax(bits_stored, -1);406 next_state <= up_state;407 end if;408 end if;409 end if;410411412413 ----------------------414 -- DECREASE BITSIZE415 ----------------------416 when down_state =>417 next_state <= down_state;418 loops <= loops + 1;419 VALID_i <= ’1’;420 RD_i <= ’0’;421422 case loops is423 when 0 =>424 c <= 0;425 DataOut_i <= sendmax(bits, 0);426 when 1 =>427 DataOut_i <= sendmax(bits-1, 0);428 bits <= bits - 1;429 if counter >= counter_max then430 loops <= 0;431 prevref <= newref;432 next_state <= signal_state; --new_state;433 else434 RD_i <= ’1’;435 next_state <= counter_state;436 end if;437 when others =>438 next_state <= down_state;439 end case;440441442 ----------------------443 -- INCREASE BITSIZE444 ----------------------445 when up_state =>446 RD_i <= ’0’;447 VALID_i <= ’1’ ;448 loops <= loops + 1;449 next_state <= up_state;450451 case loops is452 when 0 =>453 bits <= bits + 1;454 DataOut_i <= sendmax( (bits+1), -1 );455 if checkLarge( delta_stored, (bits+1) ) then --Check

if still to large456 if ( (bits+1) >= 15 ) then457 loops <= 0;458 next_state <= signal_state;459 else460 loops <= 2;461 next_state <= up_state;

109 C.1. VHDL

462 end if;463 end if;464465 when 1 =>466 DataOut_i <= std_logic_vector(to_signed(delta_stored,

16));467 -- Check if frame full468 if counter >= counter_max then469 prevref <= newref;470 next_state <= signal_state;471 loops <= 0;472 else473 RD_i <= ’1’;474 next_state <= counter_state;475 end if;476477 when 2 =>478 -- Delta still to large479 DataOut_i <= sendmax(bits, -1);480 loops <= 0;481482 when others =>483 next_state <= up_state;484 end case;485486487 ---------------------------------------488 -- Delta to large, create new frame489 ---------------------------------------490 when large_diff =>491 counter <= 0;492 next_state <= large_diff;493 loops <= loops + 1;494 RD_i <= ’0’;495 VALID_i <= ’1’;496497 case loops is498 when 0 =>499 DataOut_i <= sign(15 downto 0);500 when 1 =>501 DataOut_i <= std_logic_vector(to_signed(bits_stored,

4)) & std_logic_vector(to_signed(frameID, 12));502 when 2 =>503 DataOut_i <= prevref;504 when 3 =>505 DataOut_i <= newref;506 next_state <= counter_state;507 RD_i <= ’1’;508509 when others =>510 next_state <= large_diff;511 end case;512513 ---------------------514 -- OTHERS515 ---------------------516 when others =>517 VALID_i <= ’0’;518 end case;519 end if;520 end if;521 end process TIMING;522523524525 --******************************************************526 -- State machine timing527 --******************************************************


528 CONTROL: process(CLK)529 begin530 if rising_edge(CLK) then531 if reset = ’1’ then532 current_state <= idle_state;533 elsif ENABLE = ’1’ and EMPTY = ’0’ then534 current_state <= next_state;535 end if;536 end if;537 end process CONTROL;538539540541 end Behavioral;

111 C.1. VHDL

C.1.4 Wrapper

1 --------------------------------------------------------2 -- Filename : wrapper.vhd3 -- Author : Marius Elvegaard4 -- Date : 02.05.20165 -- Description : Wrapping bit streams to 16 bit6 -- packages.7 --------------------------------------------------------89 library ieee;

10 use ieee.std_logic_1164.all;11 use ieee.std_logic_unsigned.all;12 use ieee.numeric_std.all;13 use ieee.std_logic_signed.all;14151617 entity wrapper is18 port (19 CLK : in STD_LOGIC;20 RESET : in STD_LOGIC; -- reset mem21 DATAIN : in STD_LOGIC_VECTOR(15 downto 0); -- input22 s : in STD_LOGIC_VECTOR(3 downto 0); -- bitsize23 VALID : in STD_LOGIC; -- valid input data24 READY : out STD_LOGIC;25 DATAOUT : out STD_LOGIC_VECTOR(15 downto 0) -- output26 );27 end wrapper;282930 architecture Behavioral of wrapper is3132 --******************************************************33 -- SIGNAL DECLARATION34 --******************************************************35 signal s_i : integer; -- bit size36 signal mem : std_logic_vector(31 downto 0);-- memory37 signal point : integer range 0 to 31 := 0; -- mem pointer383940 --******************************************************41 -- FUNCTIONS42 --******************************************************4344 ----------------------------------------45 -- Shift bits up in 16 bit array46 ----------------------------------------47 function bitshift(bits : in integer; data : in std_logic_vector(15

downto 0)) return std_logic_vector is48 begin49 case bits is50 when 15 => return data;51 when 14 => return data(bits downto 0) & "0";52 when 13 => return data(bits downto 0) & "00";53 when 12 => return data(bits downto 0) & "000";54 when 11 => return data(bits downto 0) & "0000";55 when 10 => return data(bits downto 0) & "00000";56 when 9 => return data(bits downto 0) & "000000";57 when 8 => return data(bits downto 0) & "0000000";58 when 7 => return data(bits downto 0) & "00000000";59 when 6 => return data(bits downto 0) & "000000000";60 when 5 => return data(bits downto 0) & "0000000000";61 when 4 => return data(bits downto 0) & "00000000000";62 when 3 => return data(bits downto 0) & "000000000000";63 when 2 => return data(bits downto 0) & "0000000000000";64 when 1 => return data(bits downto 0) & "00000000000000";65 when others => return "0000000000000000";


66 end case;67 end bitshift;686970 begin7172 --******************************************************73 -- COMBINATIONAL LOGIC74 --******************************************************75 s_i <= to_integer(unsigned(s));76 DataOut <= (others => ’0’) when RESET = ’1’ else77 mem(31 downto 16) when point < 16 else (others => ’0’);78 READY <= ’0’ when reset = ’1’ else79 ’1’ when point < 16 and VALID = ’1’ else ’0’;80818283 --******************************************************84 -- Wrapper process.85 --******************************************************86 WRAPPER: process(CLK)87 begin88 if rising_edge(CLK) then89 if RESET = ’1’ then90 mem <= (others => ’0’);91 point <= 31;92 else93 if (VALID = ’1’) then9495 -- 16 bit or more stored in memory96 if (point < 16) then9798 -- shift up lower bits stored in memory99 mem(31 downto 16) <= mem(15 downto 0);

100101 -- insert new bits and update pointer102 if (point = 15) then103 mem(31 downto 16) <= bitshift(s_i, DataIn);104 point <= 31 - s_i - 1;105 else106 mem((point+16) downto (point+1)) <= bitshift(s_i, DataIn

);107 point <= point + 15 - s_i;108 end if;109110 -- less than 16 bits stored in memory111 else112 mem(point downto point-15) <= bitshift(s_i, DataIn);113 point <= point - s_i - 1;114 end if;115 end if;116 end if;117 end if;118 end process WRAPPER;119120 end Behavioral;

113 C.1. VHDL

C.1.5 Interface module

1 --------------------------------------------------------2 -- Filename : my_wrapper.vhd3 -- Author : Marius Elvegaard4 -- Date : 02.05.20165 -- Description : Synchronizes signals between HPS and6 -- ENCODER.7 --------------------------------------------------------89 library ieee;

10 use ieee.std_logic_1164.all;11 use ieee.numeric_std.all;121314 entity my_wrapper is15 port (clock, resetn : in std_logic;16 read, write, chipselect : in std_logic;17 address : in std_logic_vector(1 downto 0);18 writedata : in std_logic_vector(31 downto 0);19 readdata : out std_logic_vector(31 downto 0);20 leds : out std_logic_vector(9 downto 0)21 );22 end my_wrapper;232425 architecture Structure of my_wrapper is262728 --******************************************************29 -- COMPONENT DECLARATION30 --******************************************************31 component ENCODER32 port(33 CLK : in std_logic;34 ENABLE : in std_logic;35 RESET : in std_logic;36 WR : in std_logic;37 RD : in std_logic;38 DataIn : in std_logic_vector( 15 downto 0 );39 DataOut : out std_logic_vector( 15 downto 0 );40 FAIL : out std_logic;41 READY : out std_logic42 );43 end component ENCODER;4445 --******************************************************46 -- SIGNAL DECLARATION47 --******************************************************48 -- registers49 signal ctrl_reg : std_logic_vector(31 downto 0);50 signal addr_reg : std_logic_vector(31 downto 0);51 signal data_reg : std_logic_vector(31 downto 0);52 signal data2_reg : std_logic_vector(31 downto 0);5354 -- internal signals55 signal ENABLE_i : std_logic;56 signal RESET_i : std_logic;57 signal WR : std_logic;58 signal RD : std_logic;59 signal DataIn_i : std_logic_vector(15 downto 0);60 signal DataOut_i : std_logic_vector(15 downto 0);61 signal FAIL_i : std_logic;62 signal READY_i : std_logic;6364 -- synchronizing signals65 signal flag : std_logic;66 signal set : boolean;


6768 signal leds_i : std_logic_vector(9 downto 0);6970 begin7172 -- Output status to LEDs73 leds(0) <= ctrl_reg(0);74 leds(1) <= ctrl_reg(1);75 leds(2) <= ctrl_reg(2);76 leds(3) <= ctrl_reg(3);77 leds(4) <= ctrl_reg(4);78 leds(5) <= ctrl_reg(5);79 leds(6) <= ENABLE_i;80 leds(7) <= RESET_i;81 leds(8) <= WR;82 leds(9) <= RD;838485 --******************************************************86 -- PORT MAPPING87 --******************************************************88 U1 : ENCODER port map(89 CLK => clock,90 ENABLE => ENABLE_i,91 RESET => RESET_i,92 WR => WR,93 RD => RD,94 DataIn => DataIn_i,95 DataOut => DataOut_i,96 FAIL => FAIL_i,97 READY => READY_i98 );99

100101 --******************************************************102 -- SYNCHRONIZING PROCESS103 --******************************************************104 process(clock, resetn)105 variable looper : integer := 0;106 begin107 if resetn = ’0’ then108 looper := 0;109 ENABLE_i <= ’0’;110 RESET_i <= ’0’;111 RD <= ’0’;112 WR <= ’0’;113 flag <= ’0’;114 set <= false;115 DataIn_i <= (others => ’0’);116 elsif rising_edge(clock) then117 RD <= ’0’;118 RESET_i <= ’0’;119 ENABLE_i <= ’0’;120 WR <= ’0’;121122 case ctrl_reg(3 downto 0) is123124 -- STOP125 when "0000" =>126 set <= false;127 RD <= ’0’;128 ENABLE_i <= ’0’;129130 -- ENABLE131 when "0001" =>132 ENABLE_i <= ’1’;133 looper := 0;134 set <= False;

115 C.1. VHDL

135136 -- WRITE to ENCODER137 when "0010" =>138 ENABLE_i <= ’1’;139 if looper = 0 then140 WR <= ’1’;141 DataIn_i <= data_reg(15 downto 0);142 looper := looper + 1;143 elsif looper = 1 then144 WR <= ’0’;145 looper := looper + 1;146 end if;147148 -- READ from ENCODER149 when "0100" =>150 ENABLE_i <= ’1’;151 if set = False then152 set <= True;153 RD <= ’1’;154 end if;155156 -- RESET157 when "1000" =>158 if set = False then159 set <= True;160 RESET_i <= ’1’;161 end if;162163 when others =>164 null;165 end case;166167 end if;168 end process;169170171172 --******************************************************173 -- REGISTER INTERFACING174 --******************************************************175 process(clock, resetn)176 begin177 if resetn = ’0’ then178 ctrl_reg <= (others => ’0’);179 addr_reg <= (others => ’0’);180 data_reg <= (others => ’0’);181 data2_reg <= (others => ’0’);182 readdata <= (others => ’0’);183 elsif rising_edge(clock) then184185 -- HPS write data186 if chipselect = ’1’ and write = ’1’ then187 case address is188 when "00" =>189 ctrl_reg <= x"000000" & "00" & writedata(5) & READY_i &

writedata(3 downto 0);190 when "01" =>191 addr_reg <= writedata;192 when "10" =>193 data_reg <= writedata;194 when "11" =>195 data2_reg <= (31 downto (32-DataOut_i’length) => ’0’) &

DataOut_i;196 when others =>197 null;198 end case;199200 -- HPS read data


201 elsif chipselect = ’1’ and read = ’1’ then202 case address is203 when "00" =>204 readdata <= x"000000" & "00" & flag & READY_i & ctrl_reg(3

downto 0);205 when "01" =>206 readdata <= addr_reg;207 when "10" =>208 readdata <= data_reg;209 when "11" =>210 readdata <= (31 downto (32-DataOut_i’length) => ’0’) &

DataOut_i;211 when others =>212 null;213 end case;214215 end if;216 end if;217 end process;218219 end Structure;

117 C.2. C

C.2 C

1 /*------------------------------------------------------2 Filename : main.c3 Author : Marius Elvegaard4 Date : 02.05.20165 Description : HPS program communicating with6 interfacing module on FPGA.7 ------------------------------------------------------*/89 #define soc_cv_av

1011 #include <stdio.h>12 #include <string.h>13 #include <stdlib.h>14 #include <unistd.h>15 #include <fcntl.h>16 #include <sys/mman.h>17 #include "hwlib.h"18 #include "soc_cv_av/socal/socal.h"19 #include "soc_cv_av/socal/hps.h"20 #include "soc_cv_av/socal/alt_gpio.h"21 #include "hps_0.h"222324 #define HW_REGS_BASE (ALT_STM_OFST)25 #define HW_REGS_SPAN (0x04000000)26 #define HW_REGS_MASK (HW_REGS_SPAN-1)27 #define PIO_LED_DATA_WIDTH 102829 #define BUF_SIZE 333031 // ctrl signal32 #define STOP 0x0; // 000033 #define ENABLE 0x1; // 000134 #define WR 0x2; // 001035 #define RD 0x4; // 010036 #define RESET 0x8; // 100037383940 typedef struct my_wrapper {41 int a; // Control register42 int b; // Address register43 int c; // Data in register44 int d; // Data out register45 } my_wrapper;4647484950 /*---------------------------------------------51 Convert integer to binary string.52 Buffer must have length >= sizeof(int) + 1.53 -----------------------------------------------*/54 char *int2bin(int a, char *buffer, int buf_size) {55 buffer += (buf_size - 1);56 int i;57 for (i = 31; i >= 0; i--) {58 *buffer-- = (a & 1) + ’0’;59 a >>= 1;60 }61 return buffer;62 }636465


666768 /*------------------------------------------------------69 MAIN70 ------------------------------------------------------*/7172 int main() {73 void *virtual_base;74 int fd;75 my_wrapper *my_io;767778 /*------------------------------------------79 Open memory mapping80 ------------------------------------------*/81 if( ( fd = open( "/dev/mem", ( O_RDWR | O_SYNC ) ) ) == -1 ) {82 printf( "ERROR: could not open \"/dev/mem\"...\n" );83 return( 1 );84 }8586 virtual_base = mmap(NULL, HW_REGS_SPAN, 111, MAP_SHARED, fd,

HW_REGS_BASE);87 if(virtual_base == MAP_FAILED) {88 printf("ERROR: mmap() failed...\n");89 close(fd);90 return(1);91 }9293 my_io = virtual_base + ((unsigned long)(ALT_LWFPGASLVS_OFST +

MY_WRAPPER_0_BASE) & (unsigned long)(HW_REGS_MASK));949596 /*------------------------------------------97 Open files98 ------------------------------------------*/99 FILE *fout = fopen("FPGA.txt", "w"); // FPGA output file

100 if (fout == NULL) {101 printf("Error opening output file!\n");102 exit(1);103 }104 FILE *fin = fopen("data.txt", "r"); // HPS input file105 if (!fin) {106 printf("Error openinf input file!\n");107 exit(1);108 }109110111 /*------------------------------------------112 Write and read data to FPGA113 ------------------------------------------*/114 printf("\n* Starting HPS - FPGA test\n-------------------------\n");115 int deltas;116117 // Number of input values to send118 printf("Number of deltas : ");119 scanf("%d", &deltas);120121122 // Register buffers123 char datain_buffer[1000];124 char ctrl_buffer[BUF_SIZE];125 char dataout_buffer[BUF_SIZE];126 ctrl_buffer[BUF_SIZE-1] = ’\0’;127 dataout_buffer[BUF_SIZE-1] = ’\0’;128129 // reset FPGA registers130 my_io->a = RESET;131 my_io->a = STOP;

119 C.2. C

132133 float tx = 0; // number of sendt134 float rx = 0; // number of received135136 my_io->a = ENABLE;137138 // Transmit and receive data139 while ( (tx < deltas) && (ctrl_buffer != NULL) ) {140 // Read input data and send141 fgets(datain_buffer, 1000, fin);142 my_io->c = atoi(datain_buffer);143144 // Read command register145 int2bin(my_io->a, ctrl_buffer, BUF_SIZE-1);146 if (ctrl_buffer[27] == ’1’) {147 rx += 1;148 my_io->a = RD;149150 // Read output and save to file151 int2bin(my_io->d, dataout_buffer, BUF_SIZE-1);152 fprintf(fout, "%.*s\n", 16, dataout_buffer+16);153154 // Check if more data is ready155 int2bin(my_io->a, ctrl_buffer, BUF_SIZE-1);156 if (ctrl_buffer[27] == ’1’) {157 rx += 1;158 my_io->a = ENABLE;159 my_io->a = RD;160 int2bin(my_io->d, dataout_buffer, BUF_SIZE-1);161 fprintf(fout, "%.*s\n", 16, dataout_buffer+16);162 }163164 }165 else { }166167 // Send write cmd168 my_io->a = WR;169 my_io->a = ENABLE;170171 // Increment input value counter172 tx += 1;173 }174175176177 printf("\n* Sendt : %.0f, Received : %.0f, Compression : %3.2f%%\n", tx,

rx, 100-(rx/tx)*100);178179 // Stop encoder180 my_io->a = STOP;181182 // Close input and output files183 fclose(fin);184 fclose(fout);185186 // clean up our memory mapping and exit187 if( munmap( virtual_base, HW_REGS_SPAN ) != 0 ) {188 printf( "ERROR: munmap() failed...\n" );189 close( fd );190 return( 1 );191 }192 close( fd );193194 return( 0 );195 }

Documents

Sounding Rocket Telemetry Compression · 2017-12-07 · This thesis investigates the design and implementation of a real time, low computational complexity, lossless data compression