SOURCEFORGE » RALF » 2015 Erasure codes for Cubesat missions

h1. IV - Extra

{{>toc}}

h2. 1. CubeSat performances.

h3. 1.1 Measurement of encoding/decoding time.

h4. 1.1.1 In simulation.

The following program measures the time taken by the device 16-bit dsPIC33FJ256GP710 in order to perform the encoding process, the decoding process and the whole encoder/decoder RS process.

The function clock() returns the number of clock ticks elapsed since the program was launched. Thus, the calling of clock just before and after the encoding process or the decoding process reveals the number of clock ticks elapsed during their execution. Thereafter, the value of the variable  CLOCKS_PER_SEC, combined with the results of the previous functions, gives the time elapsed during the execution of encoding and decoding process.

The following hypothesis is assumed : _POSIX requires that CLOCKS_PER_SEC equals 1000000 independent of the actual resolution._

p=. !Clock1.png!

*1000 ticks per milliseconds*

p=. !Clock2.png!

*Time measurement of data encoding*

p=. !Clock3.png!

*Printing clock data*

Thereby, a chart with the 3 curves illustrating the information word length [byte] as a function of the execution time [ms]. It highlights the linear behavior of the execution time, which is demonstrated afterwards. The simulation has been launched without intruducing error in the message, so we could reckon that the more errors there are, the shaper the slope of the decoding execution time would be.

p=. !Time_RS_resized.PNG!

*Chart of Reed Solomon time measurement*

h4. 1.1.2 With Floating-Point OPeration (FLOP)

p=. !FLOPs2.png!

Hence, encoding stands for *O(nbytes x NPAR)* with _nbytes_ is the codeword length, _NPAR_ the number of parity bits.

Since it is a systematic code _nbytes = information_word_length + NPAR_ encoding stands for *O(information_word_length)* with NPAR constant.

Note that a more accurate way would be to consider processor speed and Salvo function OSGetTiks :

p=. !OSGetTiks.PNG!

h3. 1.2 Busy memory on CubeSat.

The dsPIC33F data width is 16 bits. All internal registers and data space memory are organized as 16 bits wide. The dsPIC33F features two data spaces. The data spaces can be accessed separately (for some Digital Signal Processing (DSP) instructions), or together as one 64-Kbyte linear address range (for microcontroller (MCU) instructions).

p=. !Memory.png!

More information about memory management for the dsPIC33F "Data Memory Manual":http://ww1.microchip.com/downloads/en/DeviceDoc/70202C.pdf

---

h2. 2. Current topics.

For the purpose of reliability for Land Mobile Satellite (LMS) channel, a solution is discussed about error correcting code on the Transport layer [1]. Regarding new trends of erasure codes related to satellites [2], an efficient way to perform encoding over LMS channel is to consider _Non-Binary codes_ such as Reed-Solomon code (studied in [[III - Advanced Project]] chapter) or Non-Binary LDPC code (which is highly complex to implement). The Non-Binary characteristic would be to consider a whole packet or a sliced packet as a symbol in order to decrease the error probability of packets. 

A possible continuity to this project could be to integrate the OpenFEC code available on "OpenFEC - Downloads":http://openfec.org/downloads.html in the CubeSat Kit. This would be easily done by following chapter [[II - Tutorial - Simple project on CubeSat Kit|II - Tutorial]] and [[III - Advanced Project|III - Advanced Project]] that could be a integration pattern for any CubeSat project.

Research papers proposed on IEEE Website :

[1] "Transport layer coding for the land mobile satellite channel":http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1391458&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1391458

[2] "Erasure Codes for Space Communications: Recent Findings and New Challenges":http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6333092&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6333092

---