Finish the Conclusion chapter

conclusion.tex

@@ -1,6 +1,13 @@
-\section{Conclusion}
-
-Táto časť\/ záverečnej práce je povinná. Autor uvedie zhodnotenie
-riešenia. Uvedie výhody, nevýhody riešenia,  použitie výsledkov, ďalšie
-možnosti a~pod., prípadne načrtne iný spôsob riešenia úloh, resp.
-uvedie, prečo postupoval uvedeným spôsobom.
+\section{Conclusion}
+The main requirement of the work was to measure the real, reactive and apparent electric power, as well as power factor, and to show the values to the user, preferably, plotted as a quantity over time. It had to utilise the ESP8266 chip and the GL.inet board in the process. The work's requirements were, however, met only partially. The problem is caused by the inability of obtaining most of the sought values from the power measuring integrated circuit, the MAX78615 over the \gls{spi} communication protocol. As a result, only the apparent power could be displayed, subsequently preventing the requirements relying on the other required data from completion. All the attempts to resolve the problem with Maxim Integrated technical support resulted in dead end. The stated reason was, that the part in the question is no longer supported by Maxim. It was sold with all the accompanying parts to the Silergy Corp. in the critical part of the firmware development. Despite of the problems, all the remaining requirements that could be rationally implemented were met.
+
+Another big problem is erratic start of the client device after it has been plugged in to the socket. Investigations of the power supply allowed to slightly reduce the frequency of failed starts but there is more work to be done to eliminate the phenomenon completely. This problem makes device really unreliable to use.
+
+\subsection{Possible future improvements}
+The most crucial thing to improve is to make the client node's start reliable. The ESP-12E module sometimes won't start, but without any evident mark on the oscilloscope, probing its supply voltage. It may be the power supply problem or it may be some firmware problem. After this problem has been adressed, one can move on to some other issues, but not before.
+
+It is possible to fulfil all the failed requirements due to inability of accessing all the data over \gls{spi} by switching to \gls{i2c}. The only downside of such a design is inability to obtain all the instantaneous measurements. This is not a problem at all, because a lot of them still lies in the region inaccessible by \gls{spi} (\gls{spi} is the only protocol fast enough to be capable of reading instantaneous measurements before they are being over-written at a sampling frequency - this should be fixed by the \gls{ic} manufacturer). The frequency at which \gls{i2c} is capable of obtaining measurements is perfectly sufficient anyway. Also, \gls{i2c} requires one less pin than \gls{spi}, thus leaving more pins on the ESP8266 for additional features. Such a transition would however definitely require another iteration of the \gls{pcb}, which is not instant and requires a bit of resources. If a project is to be maintained in the future, this is definitely a vital change.
+
+Speaking of a \gls{pcb} iteration, another opportunity to improve the \gls{pcb} design lies in utilising the MAX78615 in-built relay controlling mechanism. Fundamental part of responsibilities of the \gls{ic} is to track the zero-crossing. Relay tied to the zero-crossing allows for graceful start of appliances. This is helpful in preventing damage to some sensitive appliaces when started at the point of mains line voltage peak, such as incandescent light bulbs\cite{dilouie2008lighting}. Relay is also not essential for actual measurements, so it could be removed from the system altogether to save some cost and space, in applications where the relay is not needed.
+
+There is always room for improvement, but the last bigger proposed change is to completely remove the GL.inet board from the system. It was included mainly for research and practice reasons, not so much to provide some necessary functionality. If we wanted strictly cloud-connected client devices, given there is a trend in increasing count of such a devices, this would reduce cost and complexity. Such a change would require the client devices to be connected to the Internet all the time and to move the web server from the GL.inet (server node) to some other place, preferably where the could storage is hosted. It would also eliminated the need for an external DDNS server.

tukethesis.bib

@@ -399,3 +399,13 @@
 	note = {(Accessed on 19/04/2016)}
 }
 
+@book{dilouie2008lighting,
+  title={Lighting Controls Handbook},
+  author={DiLouie, C.},
+  isbn={9780881735741},
+  lccn={2007030706},
+  url={https://books.google.sk/books?id=3pKVF4HoeMIC},
+  year={2008},
+  publisher={Fairmont Press}
+}
+