diff --git a/report/bibliography.bib b/report/bibliography.bib
index acdcd4430528845afa84278fef438faa022f7101..28492ea4247ccea6ef21cc00d67e09ffd0e42f0d 100644
--- a/report/bibliography.bib
+++ b/report/bibliography.bib
@@ -250,6 +250,89 @@
note = {[Online; visited 17/03/2019]}
}
+@misc{gnuradioperformance,
+ title = {Exploring GNU Radio performance},
+ year = {2018},
+ author = {Alberto Dassatti},
+ publisher = {reds.ch},
+ howpublished = {\url{http://blog.reds.ch/?p=372}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{kfr,
+ title = {KFR audio processing library},
+ year = {2019},
+ author = {kfrlib},
+ publisher = {kfrlib.com},
+ howpublished = {\url{https://www.kfrlib.com/}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{stk,
+ title = {STK audio synthesis library},
+ author = {Perry R. Cook and Gary P. Scavone},
+ publisher = {stanford.edu},
+ year = {2019},
+ howpublished = {\url{https://ccrma.stanford.edu/software/stk/usage.html}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{psk,
+ title = {Phase Shift Keying},
+ author = {Watson},
+ publisher = {udel.edu},
+ howpublished = {\url{http://www.physics.udel.edu/~watson/scen103/projects/96s/thosguys/psk.html}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{qam,
+ title = {Quadrature Amplitude Modulation},
+ author = {National Instruments},
+ publisher = {ni.com},
+ year = {2019},
+ howpublished = {\url{http://www.ni.com/en-us/innovations/white-papers/06/quadrature-amplitude-modulation--qam-.html}}
+}
+
+@misc{ask,
+ title = {Amplitude-shift keying},
+ year = {2019},
+ publisher = {wikipedia.org},
+ howpublished = {\url{https://en.wikipedia.org/wiki/Amplitude-shift_keying}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{am,
+ title = {Amplitude modulation},
+ year = {2019},
+ publisher = {wikipedia.org},
+ howpublished = {\url{https://en.wikipedia.org/wiki/Amplitude_modulation}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{onoff,
+ title = {On-Off Keying},
+ year = {2019},
+ publisher = {wikipedia.org},
+ howpublished = {\url{https://en.wikipedia.org/wiki/On-off_keying}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{goertzel,
+ title = {Goertzel algorithm},
+ year = {2019},
+ publisher = {wikipedia.org},
+ howpublished = {\url{https://en.wikipedia.org/wiki/Goertzel_algorithm}},
+ note = {[Online; visited 17/03/2019]}
+}
+
+@misc{fft,
+ title = {Fast Fourier Transform},
+ year = {2019},
+ publisher = {wikipedia.org},
+ howpublished = {\url{https://en.wikipedia.org/wiki/Fast_Fourier_transform}},
+ note = {[Online; visited 17/03/2019]}
+}
+
@misc{fsk,
title = {Frequency-shift keying},
year = {2019},
diff --git a/report/chapters/conclusion.md b/report/chapters/conclusion.md
index 13ab55cb03b20c26873dd8a36b2ff199f478c092..12392d20b7a447f54c4d3bf9d3e20a0aa995693d 100644
--- a/report/chapters/conclusion.md
+++ b/report/chapters/conclusion.md
@@ -1,6 +1,12 @@
-# Conclusion
+# 6. Conclusion and future work
-To be added: Conclusion
+I have enjoyed working on this project. It has taught me many different aspects of a software defined radio, especially how to create my own audio processing algorithms. I have never studied signal processing before, but now at least I have the minimal foundation. Furthermore, I have extended my knowledge of C++ programming skills by working on tree platforms at the same time. I am pleasantly surprised by the results of the encoder and the decoder. I have expected a much bigger wall that I would have to get over. I did not manage to implement a noise reduction filters and to properly test those, but I am satisfied with the results as it is.
+
+The project has achieved most of the requirements specified in the beginning of this document. But, there is a large room to improve those, and add more features. One of the feature that I have thought of only at the end of this project was to add authenticity and security of the data received. This could be done by signing the message via a public-private keys. So that only the authorised person could have created the transmission in the first place. One more thing I would have changed would be to modify how the third party dependencies are handled. Currently they are handled by CMake as an external project. Meaning that the CMake loses all information about the generated library (such as, where the generated binaries are located). So it requires manual input into the CMake scripts, so that the parent project (this project) can find those libraries. If I would have start from scratch, I would have chosen PKG style dependencies handling, or simply importing the third party dependencies scripts into the parent project. That way I would not have to manually specify the location of the libraries, which has caused many headaches and wasted hours over the development. Another thing that I have enjoyed was finding out about the Bintray service, a package storage and distribution service, which was used to store pre-built binaries of the decoder and the encoder (the artifacts). I have not heard of this service before and their friendly open source free pricing makes it perfect for many of my upcoming projects that I will create.
+
+Last thing I would have improved is the graphical user interface. It is not very intuitive from my point of view. I am not a UX designer, nor I will ever be. Maybe getting some feedback from non technical users would help. After all, having a user interface that you have to explain makes your user interface useless.
+
+This project was never meant to replace the current state of the internet, nor it is meant to be the way of the future emergency information distribution. It is meant to be open source project that can be used as one in many ways how to send information cheaply and with very low hardware requirements. More importantly, I have created this project to have fun, which I did.
diff --git a/report/chapters/design.md b/report/chapters/design.md
index b3b21a0cafed4f852370a91cb604fce1ec897559..2d2be2fd4d875d2e2f451ad1237665396c72a176 100644
--- a/report/chapters/design.md
+++ b/report/chapters/design.md
@@ -224,7 +224,7 @@ The detailed explanation behind the functionality of these blocks is explained i
### 4.4.3 Fast Fourier Transform and Goertzel Algorithm
-During the prototyping phase, a Fast Fourier Transform (FFT) was considered in order to listen for the two specific frequencies representing the binary stream of data. After a lot of research done on this topic, a decision was made that using FFT was computationally heavy for a simple work we need. In this project, we are only looking at the two specific frequencies, representing high and low bits, and a complete silence, representing no transmission. In the end, the Goertzel algorithm was used to perform this process. While the FFT produces buckets for a range of frequencies, the Goertzel only produces a magnitude of a specific frequency we are trying to listen to. If no frequency is detected, the output of the algorithm is close or equal to zero. The Goertzel can be sumarized in the following code:
+During the prototyping phase, a Fast Fourier Transform (FFT) was considered in order to listen for the two specific frequencies representing the binary stream of data. After a lot of research done on this topic, a decision was made that using FFT was computationally heavy for a simple work we need. In this project, we are only looking at the two specific frequencies, representing high and low bits, and a complete silence, representing no transmission. In the end, the Goertzel [@goertzel] algorithm was used to perform this process. While the FFT produces buckets for a range of frequencies, the Goertzel only produces a magnitude of a specific frequency we are trying to listen to. If no frequency is detected, the output of the algorithm is close or equal to zero. The Goertzel can be sumarized in the following code:
\pagebreak
diff --git a/report/chapters/literature.md b/report/chapters/literature.md
index 32bbda6dc8a2ed179123b28d5186fa633f527dcb..d961c85a6d21df471addb81f8419a04ea00bc4bf 100644
--- a/report/chapters/literature.md
+++ b/report/chapters/literature.md
@@ -2,7 +2,43 @@
This chapter will discuss any relevant technologies and relevant encoding or decoding strategies explained.
-## 2.1 Modulation
+## 2.1 Existing solutions
-To be added: Describe different modulation techniques.
+There are many solutions to the same problems we are facing in this project. However, most of them are hardware based. Because this project uses the existing FM radio to transmit the data, it would only make things complicated by introduced a hardware based middle-man. Additionally, the reason of this project is not to create any new hardware, rather than use an existing one. Therefore, we need to do signal processing on the software side. GNU Radio [@gnuradio] does offer a software solution for this project. However, the GNU Radio was primarily developed on Linux platform and the Windows or Mac OSX support is non-existing. There are some unofficial user made ports that do work on Linux, but I was unable to find any that work on Mac OSX. Moreover, the GNU Radio is a massive framework and many times requires fast CPU [@gnuradioperformance]. For this project, I would only use a small fraction of what the GNU Radio provides. But, because of it size and the fact that it is oriented around Linux, I simply can not use it. While the GNU Radio can not be used for this project, the blocked based approach to create a system can be adopted to this project.
+
+![Screenshot of the block based interface of the GNU Radio software. Credits for the picture go to the GNU Radio wiki. [@gnuradio]](images/gnuradio.png)
+
+There are other libraries that do offer similar functionality as the GNU Radio, but they often have heavily outdated packaging tools, or simply are not cross platform portable. There are similar libraries more targeted for general audio/music processing and not necessarily targeted at modulation. One of such libraries is kfrlib [@kfr] but their licensing does not allows me to use their library freely. There are also many less known similar libraries, such as stk [@stk], which is more targeted at audio synthesis, but is missing many core features that this projects needs in order to encode or decode the data into an audio.
+
+In the end, I have chosen not to further look for a library that could provide the building blocks I need for this projects. Many of the libraries are either badly licensed (GPLv3), often use outdated building and packaging technologies (autoconf) and therefore not portable, or are simply too big to easily integrate into a modern C++ application. I have chosen not to pursue the solution through a third party algorithms, and instead decided to implement my own.
+
+## 2.2 Modulation
+
+There are many different methods of modulation, but only the digital modulation techniques are relevant. This section will cover the basics of different modulations and why FSK was chosen.
+
+### 2.2.1 Phase-Shift Keying
+
+The Phase Shift Keying [@psk] (PSK) is a type of modulation that changes the phase of the frequency based on the binary data. This is used in many different devices such as Bluetooth, or WLANs. The PSK uses a symbol based approach where the binary ones and zeros are not encoded exactly the same. The combination of bits creates a different unique phase. The PSK demodulator than has to map the unique sequence of phased waveform back to the original data. This would be extremely difficult to create and run purely through a software without any hardware acceleration.
+
+### 2.2.2 Amplitude-Shift Keying
+
+The Amplitude Shift Keying [@ask] (ASK) is a type of modulation that uses the height of the amplitude to encode (modulate) the digital signal. A similar modulation called AM [@am] was primarily used as an analog modulation for old public radio equipment that was later replaced by more reliable FM modulation. This type of modulation is very easy to implement, as we only need to keep track of the amplitude height. But we lose precision when the strength of the signal gets weaker.
+
+### 2.2.3 Quadrature Amplitude Modulation
+
+The Quadrature Amplitude Modulation [@qam] (QAM) is a type of modulation that carries two digital signals via amplitude shift keying [@ask]. The two digital signals are 90 degrees out of phase. This type of modulation is used mainly in telecommunications and WiFi based systems. This type of modulation is again difficult to decode through a custom software. For this project, we need something simpler that we can guarantee it will work.
+
+### 2.3.4 On-Off Keying
+
+The On-Off Keying [@onoff] is a modified type of amplitude shit keying modulation, in which the digital signal is modulated by presence or absence of the carrier signal. This type of modulation is used to transmit morse code. It is more prone to noise, therefore this type modulation will not be considered in this project.
+
+### 2.3.5 Frequency Shift Keying
+
+The Frequency Shift Keying [@fsk] (FSK) is a very popular method for encoding (modulating) the binary data. The modulation works by shifting the frequency of the carrier based on the binary input. This can be even further simplified by encoding the binary input via two different frequencies. This type of modulation is widely adopted in many different systems, such as the modem. Therefore, due to its popularity and simplicity, this type of modulation was used for this project.
+
+## 2.3 Demodulation
+
+The FSK was chosen as the best candidate for the modulation of the signal. Therefore, a demodulation algorithm is needed. To demodulate the signal, we simply need to check for the carrier and the shifted frequency. In more simpler terms, we need to check for two frequencies. While this can be easily done through a hardware, it is slightly more complicated through the software. This type of modulation can be easily demodulated by already existing and popular algorithms such as Fast Fourier Transform [@fft] (FFT) or Goertzel algorithm [@goertzel].
+
+The Fast Fourier Transform works by analyzing the audio and producing bins. In simple terms, each bin represents a frequency range, and the magnitude of the bin represents the occurrence of that range in the analyzed audio sequence. In this project, I have decided not to pursue FFT, due to a fact that it is computationally expensive in a real time systems. Instead, I have decided to go with a much simpler algorithm, a Goertzel algorithm.
diff --git a/report/chapters/testing.md b/report/chapters/testing.md
index 8ac09fc0a23eaf7dd67f31caa086619115952c0b..d89ab47470fa79511f7357a7ef6944d6e33dd1a0 100644
--- a/report/chapters/testing.md
+++ b/report/chapters/testing.md
@@ -4,11 +4,11 @@ The following section describes methods that were used to test the decoder and t
## 5.1 Hardware testing
-For the following test I have decided to use a real FM transmitter and a FM receiver. To perform the test, I have encoded a simple 132 byte HTML file. This audio was automatically transmitted out via the encoder (by using `--stream` command line argument). This audio was then forwarded into a FM transmitter via the workstation's speaker output. The audio was transmitted and then received on the other end by the FM receiver. This audio was then forwarded back to the workstation through its microphone input. The audio was decoded through the decoder (by using `--listen` command line argument) and the file was decoded back to its original HTML form and saved into a specified destination folder.
+For the following test I have decided to use a real FM transmitter and a FM receiver. To perform the test, I have encoded a simple 132 byte HTML file. This audio was automatically transmitted out via the encoder (by using `--stream` command line argument). This audio was then forwarded into a FM transmitter via the workstation's speaker output. The audio was transmitted and then received on the other end by the FM receiver. This audio was then forwarded back to the workstation through its microphone input. The audio was then finally decoded through the decoder (by using `--listen` command line argument) and the file was decoded back to its original HTML form and saved into a specified destination folder.
### 5.1.1 FM hardware
-The FM hardware used in these tests were pre-built purchased FM modules. The FM transmitter is a module consisting of BH1417F [@bh1417f] analog integrated circuit. The BH1417F offers a frequency range of 87.7Mhz and 107.9Mhz. This frequency can be chosen by toggling the pins (or in this case, switches on the module board), but the default frequency was set to 107.9MHz. The BH1417F is a pure analog integrated circuit and does not contain any features that could affect the audio, such as automatic gain control. The module was relatively cheap and easy to set up. It only needs a 5V 2.4W input power and audio signal through the 3.5mm jack connector. The antenna used is a simple ~20cm wire. I have not used a proper antenna, because both the FM transmitter and the FM receiver were located in the same room next to the workstation. There was no reason to add a proper antenna that would extend the transmission distance.
+The FM hardware used in these tests were pre-built purchased FM modules. The FM transmitter is a module consisting of BH1417F [@bh1417f] analog integrated circuit. The BH1417F offers a frequency range of 87.7Mhz and 107.9Mhz. This frequency can be chosen by toggling the pins (or in this case, switches on the module board), but the default frequency was set to 107.9MHz. The BH1417F is a pure analog integrated circuit and does not contain any features that could affect the audio, such as automatic gain control. The module was relatively cheap and easy to set up. It only needs a 5V 2.4W input power and audio input signal through the 3.5mm jack connector. The antenna used here is a simple ~20cm wire. I have not used a proper antenna, because both the FM transmitter and the FM receiver were located in the same room next to the workstation. There was simply no reason to add a proper antenna that would extend the transmission distance.
The FM receiver is a module consisting of TEA5767 [@tea5767] digital integrated circuit. This integrated circuit uses a I2C protocol [@i2c] which is used to configure the TEA5767 device. I have used an Arduino based board Arduino Uno [@arduinouno]. The Arduino board contained a custom program that would modify the TEA5767 registers in order to specify the target listening frequency - 107.9MHz. The device also contains registers which allow enabling or disabling of additional extra features such as automatic station finder, automatic gain control, or automatic noise suppression. The device used relatively low power and only required 5V and 0.5W of power.
@@ -18,13 +18,13 @@ The FM receiver is a module consisting of TEA5767 [@tea5767] digital integrated
### 5.1.2 FM results
-Before I have tested this project with a real FM hardware, I have first performed a baseline test. This baseline test was made to verify that everything excluding the FM hardware works as expected. The test was done by connecting the audio output straight into the microphone input of the workstation. By doing this, we eliminate a possibility that a problem, if any, is inside of the motherboard (the sound card) or in the program itself. I have encoded a simple 132 HTML file, sent it out via the encoder-cli, and let the decoder-cli listen to the audio. The test was successful, I was able to get the exact same HTML file back. In the next figures, you can see the intercepted recording of the audio (that has returned back via microphone). Additionally, I have performed a fast fourier transform analysis on an empty region of the audio, to see if there are any artifacts or high noise that could affect other tests.
+Before I have tested this project with a real FM hardware, I have first performed a baseline test. This baseline test was made to verify that everything, excluding the FM hardware, works as expected. The test was done by connecting the audio output straight into the microphone input of the workstation. By doing this, we eliminate a possibility that a problem, if any, is inside of the motherboard (the sound card) or in the program itself. I have encoded a simple 132 HTML file, sent it out via the encoder-cli, and let the decoder-cli listen to the audio. The test was successful, I was able to get the exact same HTML file back. In the next figures, you can see the intercepted recording of the audio (that has returned back via microphone). Additionally, I have performed a fast fourier transform analysis on an empty region of the audio, to see if there are any artifacts or high noise that could affect other tests.
-The first FM test conduced was not a success. As shown in the following figures below, the audio that has returned back to the decoder contains artifacts and is completely out of the shape compared to the baseline test. After spending a lot of time figuring out the cause of this issue, I have found out that this was due to the internal settings of the TEA5767 and the fact that the power supply was insufficient. The power supply in the first tests was a 5V 500mA supply via USB-A from the workstation. The USB power is not meant to be used this way at all. Additionally, the default values of TEA5767 are set in a way to enable noise reduction and automatic gain control. This was especially noticeable when a random audio recording was played by the FM transmitter, the receiver has lowered it's output audio gain once it has noticed the audio recording has stopped and a silence (with a background noise) started.
+The first FM test conduced was not a success. As shown in the following figures below, the audio that has returned back to the decoder contains artifacts and is completely out of the shape compared to the baseline test. After spending a lot of time figuring out the cause of this issue, I have found out that this was due to the internal settings of the TEA5767 and the fact that the power supply was insufficient. The power supply in the first tests was a 5V 500mA supply via USB-A from the workstation. The USB power is not meant to be used this way at all. Additionally, the default values of the TEA5767 are set in a way to enable noise reduction and automatic gain control. This was especially noticeable when a random audio recording was played by the FM transmitter, the receiver has lowered it's output audio gain once it has noticed the audio recording has stopped and a silence (with a background noise) started.
diff --git a/report/images/gnuradio.png b/report/images/gnuradio.png
new file mode 100644
index 0000000000000000000000000000000000000000..c0d21be06723b0f165e1da2adbf3939fe500b7bb
Binary files /dev/null and b/report/images/gnuradio.png differ