You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
13 lines
3.6 KiB
13 lines
3.6 KiB
\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.
|
|
|
|
|
|
|
|
\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. After this problem has been resolved, 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. |