% !TeX root = main.tex
\iffalse
# It is impossible to optimise all system parameter values concurrently.
# Trade-offs $quantify$ the benefits a designer would gain in optimising one 
performance metric at the expense of degrading a different performance metric.

Have you considered $and quantified$ the cost (you will incur) versus the gain 
(you will obtain) when you modify different parameters in your system? For example:
* Local vs. Cloud processing.
* Range vs. Power consumption (battery life).
* Throughout vs. Power consumption.
* Latency /Delay vs. Accuracy.
* Performance vs. Security.
* Generic vs. Bespoke hardware.
* Price vs. Functionality.
* Price vs. Usability.
* Price vs. Robustness / Reliability.
* Functionality vs. Usability.
* Functionality vs. Rapid development (time to market).
* Functionality vs. Backward compatibility.
\fi

\newpage
\section{Engineering Trade-offs}

\subsection{Sensor selection}
This section describes different sensor options and reasons for specific choices.

\subsubsection{Temperature and Humidity}
A simple thermistor was not used as humidity sensor is also required and most of the module solutions has integrated both sensors. Three $I^2C$ modules were considered: \texttt{HTU21D}, \texttt{Si7021} and \texttt{HDC2080} as these were the only modules that meet requirements and were available from the supplier. All of modules has similar accuracy of $\pm2-3\%$ for relative humidity and $\pm 0.2-0.4~^\circ C$. All sensors had relatively similar sleep current however, different measuring current and time as shown in \autoref{tab:temp_power}. \texttt{HDC2080} was chosen due to the lowest measuring time which means it's the most power efficient and does not delay microprocessor as long further saving energy.

\begin{center}
	\begin{tabular}{c|c|c|c|c|c}
		\multirow{2}{*}{Sensor}	& \multicolumn{2}{c|}{Sleep Current} & \multicolumn{2}{c|}{Measuring Current} & Measuring Time \\\cline{2-6}
					& Typ. & Max & Typ. & Max & Typ. \\
		\hline
		HDC2080 & 50 nA	& 100 nA 	& 550$\mu A$ & 730$\mu A$ & 1.27ms \\
		Si7021  & 60 nA & 62 nA 	& 150$\mu A$ & 180$\mu A$ & 28ms \\
		HTU21D  & 20 nA & 140 nA 	& 450$\mu A$ & 500$\mu A$ & 58ms \\
		BME280  & 100 nA & 300 nA 	& 350$\mu A$ & 370$\mu A$ & 8ms \\
	\end{tabular}
	\captionof{table}{Power consumption of temperature and humidity sensors \autocite{HDC2080,SI7021,HTU21D,BME280}.}
	\label{tab:temp_power}
\end{center}

Unfortunately, after system setup \texttt{HDC2080} sensor has failed to respond and a new replacement sensor was needed. Due to availability from alternative supplier and relatively good specification, \texttt{BME280} was chosen, which in addition include atmospheric pressure readings which were recorded but not used for analysis.

\subsubsection{Air Quality}
For air quality, three sensors where considered, \texttt{MQ135}, \texttt{SGP30} and \texttt{CCS811}. \texttt{MQ135} lacked $I^2C$ interface, has poor efficiency and requires additional circuit to control heater \autocite{MQ135}. \texttt{CCS811} has 1.2mW average power draw measuring once every 60 seconds, whereas \texttt{SGP30} takes 6.5mW at minimum which is significantly more. \texttt{SGP30} has higher maximum measurement range of up to 60000ppm $CO_2$ and 60000ppb TVOC comparing to 8192ppm and 1187ppb that \texttt{CCS811} can provide \autocite{SGP30,CCS811}. \texttt{SGP30} was selected due supplier unavailability to provide \texttt{CCS811} sensor.

\subsection{Cryptography}
A number of different cryptography algorithms have been considered. Arduino library repository provides a library with most of chryptographic algorithm implemented including their benchmarks. Results are shown in \autoref{tab:crypto}. Used ESP8266 does not have most commonly used AES hardware acceleration therefore this table should be relevant even when it was produced using much less capable AVR processor. Software implemented AES is outperformed by ChaCha and Speck, the best result showing Speck with ECB mode. However, as ECB mode lacks of diffusion ChaCha20 was chosen instead. 20 over 12 round ChaCha was selected due to relatively low time penalty over much higher system lifetime. 

\begin{center}
	\begin{tabular}{c|c|c}
		Algorithm & Encryption time per byte & Key Setup \\
		\hline
		AES192 ECB 	& 39.94$\mu s$ 		& 165.34$\mu s$ \\
		AES256 ECB 	& 46.61$\mu s$ 		& 217.79$\mu s$ \\
		AES192 GCM 	& 116.38$\mu s$ 	& 1485.56$\mu s$ \\
		AES256 GCM 	& 123.04$\mu s$ 	& 1760.28$\mu s$ \\
		ChaCha12 	& 10.38$\mu s$ 		& 43.74$\mu s$ \\
		ChaCha20 	& 14.87$\mu s$ 		& 43.74$\mu s$ \\
		ChaChaPoly  & 41.20$\mu s$ 		& 902.36$\mu s$ \\
		Speck 192 ECB	& 10.03$\mu s$ 	& 264.63$\mu s$ \\
		Speck 256 ECB	& 10.31$\mu s$ 	& 275.26$\mu s$ \\
		Speck 256 GCM	& 86.74$\mu s$ 	& 646.88$\mu s$ \\
		
	\end{tabular}
	\captionof{table}{Benchark result for various encryption algorithms perfromed on Atmel ATmega328P microprocessor at 16MHz  \autocite{cryptolib}.}
	\label{tab:crypto}
\end{center}