summaryrefslogtreecommitdiffstats
path: root/notFinishedCode/Report
diff options
context:
space:
mode:
authorRefik Hadzialic2011-10-22 23:18:43 +0200
committerRefik Hadzialic2011-10-22 23:18:43 +0200
commit2375bb932bd2e68a3aa7c9e4f774ac7bc976e526 (patch)
treed4f2ae79af593401498d408aae8aeaf5efa1a788 /notFinishedCode/Report
parentReport writing (diff)
downloadgsm-selftest-2375bb932bd2e68a3aa7c9e4f774ac7bc976e526.tar.gz
gsm-selftest-2375bb932bd2e68a3aa7c9e4f774ac7bc976e526.tar.xz
gsm-selftest-2375bb932bd2e68a3aa7c9e4f774ac7bc976e526.zip
Report writing
Diffstat (limited to 'notFinishedCode/Report')
-rw-r--r--notFinishedCode/Report/test.log4
-rw-r--r--notFinishedCode/Report/test.pdfbin1481109 -> 1481113 bytes
-rw-r--r--notFinishedCode/Report/test.tex2
-rw-r--r--notFinishedCode/Report/test.tex~2
4 files changed, 4 insertions, 4 deletions
diff --git a/notFinishedCode/Report/test.log b/notFinishedCode/Report/test.log
index b1b8cb9..21f7baa 100644
--- a/notFinishedCode/Report/test.log
+++ b/notFinishedCode/Report/test.log
@@ -1,4 +1,4 @@
-This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.9.27) 22 OCT 2011 23:06
+This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.9.27) 22 OCT 2011 23:18
entering extended mode
%&-line parsing enabled.
**test.tex
@@ -425,7 +425,7 @@ r/fonts/pk/ljfour/jknappen/ec/ecrm1728.600pk></usr/share/texmf-texlive/fonts/ty
pe1/public/amsfonts/cm/cmmi10.pfb></usr/share/texmf-texlive/fonts/type1/public/
amsfonts/cm/cmsy10.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm
/cmsy9.pfb>
-Output written on test.pdf (30 pages, 1481109 bytes).
+Output written on test.pdf (30 pages, 1481113 bytes).
PDF statistics:
703 PDF objects out of 1000 (max. 8388607)
0 named destinations out of 1000 (max. 500000)
diff --git a/notFinishedCode/Report/test.pdf b/notFinishedCode/Report/test.pdf
index e395c76..d3347a3 100644
--- a/notFinishedCode/Report/test.pdf
+++ b/notFinishedCode/Report/test.pdf
Binary files differ
diff --git a/notFinishedCode/Report/test.tex b/notFinishedCode/Report/test.tex
index 7f8188a..0b8b1d0 100644
--- a/notFinishedCode/Report/test.tex
+++ b/notFinishedCode/Report/test.tex
@@ -313,7 +313,7 @@ response from the other side. Our approch to this problem was to build a simple
confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging
topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum
protocol\footnote{Design concepts and paradigms for the protocol design have been used from the
-``Network Protocol Design and Evaluation'' course, lectured by Stefan R\"{u}hrup}.
+``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}.
In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works,
it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device
that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software
diff --git a/notFinishedCode/Report/test.tex~ b/notFinishedCode/Report/test.tex~
index 5e03427..7f8188a 100644
--- a/notFinishedCode/Report/test.tex~
+++ b/notFinishedCode/Report/test.tex~
@@ -312,7 +312,7 @@ When defining these rules, it is important to define a limited state space for e
response from the other side. Our approch to this problem was to build a simple synchronous protocol, where every expected message is
confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging
topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum
-protocol\footnote{Design ideas and references for the protocol design have been used from the
+protocol\footnote{Design concepts and paradigms for the protocol design have been used from the
``Network Protocol Design and Evaluation'' course, lectured by Stefan R\"{u}hrup}.
In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works,
it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device