summaryrefslogtreecommitdiffstats
path: root/notFinishedCode
diff options
context:
space:
mode:
authorRefik Hadzialic2011-10-22 23:06:43 +0200
committerRefik Hadzialic2011-10-22 23:06:43 +0200
commita6bfdcea01d91cf5d492ddde916a69aeeb53a064 (patch)
treefcc006a3c8b89371b92c017524615cd224f8159c /notFinishedCode
parentReport writing (diff)
downloadgsm-selftest-a6bfdcea01d91cf5d492ddde916a69aeeb53a064.tar.gz
gsm-selftest-a6bfdcea01d91cf5d492ddde916a69aeeb53a064.tar.xz
gsm-selftest-a6bfdcea01d91cf5d492ddde916a69aeeb53a064.zip
Report writing
Diffstat (limited to 'notFinishedCode')
-rw-r--r--notFinishedCode/Report/test.log12
-rw-r--r--notFinishedCode/Report/test.pdfbin1479159 -> 1481109 bytes
-rw-r--r--notFinishedCode/Report/test.tex4
-rw-r--r--notFinishedCode/Report/test.tex~4
4 files changed, 12 insertions, 8 deletions
diff --git a/notFinishedCode/Report/test.log b/notFinishedCode/Report/test.log
index 54ba8f9..b1b8cb9 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 22:42
+This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.9.27) 22 OCT 2011 23:06
entering extended mode
%&-line parsing enabled.
**test.tex
@@ -386,17 +386,17 @@ File: sshTunnel.png Graphic file (type png)
<use sshTunnel.png> [21
<./sshTunnel.png (PNG copy)>] [22] [23]
-LaTeX Font Info: Try loading font information for OMS+cmr on input line 547.
+LaTeX Font Info: Try loading font information for OMS+cmr on input line 549.
(/usr/share/texmf-texlive/tex/latex/base/omscmr.fd
File: omscmr.fd 1999/05/25 v2.5h Standard LaTeX font definitions
)
LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <9> not available
-(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 547.
+(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 549.
[24] [25] [26]
LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <10.95> not available
-(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 619.
+(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 621.
<resultsImage.png, id=121, 702.625pt x 431.6125pt>
File: resultsImage.png Graphic file (type png)
@@ -425,9 +425,9 @@ 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, 1479159 bytes).
+Output written on test.pdf (30 pages, 1481109 bytes).
PDF statistics:
- 698 PDF objects out of 1000 (max. 8388607)
+ 703 PDF objects out of 1000 (max. 8388607)
0 named destinations out of 1000 (max. 500000)
96 words of extra memory for PDF output out of 10000 (max. 10000000)
diff --git a/notFinishedCode/Report/test.pdf b/notFinishedCode/Report/test.pdf
index fc2bb4c..e395c76 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 d373c95..7f8188a 100644
--- a/notFinishedCode/Report/test.tex
+++ b/notFinishedCode/Report/test.tex
@@ -311,7 +311,9 @@ A communication protocol represents a set of well defined rules by whose help tw
When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate
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.
+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}.
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 d373c95..5e03427 100644
--- a/notFinishedCode/Report/test.tex~
+++ b/notFinishedCode/Report/test.tex~
@@ -311,7 +311,9 @@ A communication protocol represents a set of well defined rules by whose help tw
When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate
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.
+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
+``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
that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software