From 3647f4b39f729c7c78671f482169439222407c6c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Peter=20Babi=C4=8D?= Date: Tue, 19 Apr 2016 19:11:51 +0200 Subject: [PATCH] Remove external components part Because it is not going to be used. --- analytical.tex | 10 +++++----- tukethesis.pdf | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/analytical.tex b/analytical.tex index 9a5cec2..502688e 100644 --- a/analytical.tex +++ b/analytical.tex @@ -135,11 +135,11 @@ Another choice lies in the way of storing the measured data on the server. For a On a client side of a proposed system, there are again three main language options. The first one is the already mentioned \texttt{Lua}. This language is simple, yet not terribly popular. The availability of the design resources might be limited. Second one is the ruler of the micro-controller world\cite{van2001programming}, plain \texttt{C}, suited for more experienced programmer, but providing the highest flexibility. The third choice is to use \texttt{C++} based eco-system, derived from \Gls{arduino}. This choice is far more superior, because it provides access to enormous resources and libraries\cite{seneviratne2015internet} readily available on the Internet with and addition to (mostly) cross-compatible code, which is a nice bonus. This option has been chosen, because it is, again, the easiest way to accomplish the task. - -\subsection{External components} -One entity, that was already mentioned, but still not depicted in the design considerations is the \gls{usb} storage. It requires both \gls{hw} and \gls{sw} to work, and is externally connected to the server node. - -Should the \gls{usb} storage be applied for a local data storage capability, in case when the server node cannot connect to the internet for a cloud upload and available non-volatile local memory is depleted, either a \Gls{flash} stick or an external \gls{hdd} should be used. Both require additional \gls{kernel} modules to work, in addition to the \gls{daemon}, that will handle the mounting process. In case of the \gls{hdd}, the capable power supply is needed to power both GL.inet board and the \gls{hdd} at the same time. +% +%\subsection{External components} +%One entity, that was already mentioned, but still not depicted in the design considerations is the \gls{usb} storage. It requires both \gls{hw} and \gls{sw} to work, and is externally connected to the server node. +% +%Should the \gls{usb} storage be applied for a local data storage capability, in case when the server node cannot connect to the internet for a cloud upload and available non-volatile local memory is depleted, either a \Gls{flash} stick or an external \gls{hdd} should be used. Both require additional \gls{kernel} modules to work, in addition to the \gls{daemon}, that will handle the mounting process. In case of the \gls{hdd}, the capable power supply is needed to power both GL.inet board and the \gls{hdd} at the same time. diff --git a/tukethesis.pdf b/tukethesis.pdf index fa2cbdb..9deb81b 100644 --- a/tukethesis.pdf +++ b/tukethesis.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:5f17ee3c0ddbac9ef68969f4883ce68b8e86b9d86e59f599f0ce5f76e4de1e05 -size 2684247 +oid sha256:776760e7f1c15a4d6eae9cdfcca8487b306088b56f6de4117ae9687b8723f36c +size 2683558