@ -42,7 +42,7 @@ They are also divided to a hardware part and software part. Software is easier t
\begin{itemize}
\item The \gls{gui} running on the web-server
\item Add, edit (configure) and remove measuring devices to/from the system
\item Present the instantaneous (real) power consumed for each appliance
\item Present the real power consumed for each appliance
\end{itemize}
\textbf{High importance:}
@ -82,7 +82,7 @@ Where there are at least two nodes in a system, they have to communicate togethe
The measuring devices, from now on called \textbf{client nodes}, will consist of blocks of the remaining hardware requirements. The resulting block diagram can be seen in the figure \ref{f:client_node})
For the \textbf{server node}, a complete working solution already exists, ready to be employed. The \textbf{GL.inet board}, described in more detail in the chapter \ref{s:glinet}, is greatly sufficient in all required aspects, and thus is used for this purpose.
Luckily, a particular part of the required functionality for the client node (displayed as a simplified schematic in \ref{f:schem_block}) is already integrated as an ESP-8266 module, described in more detail in the chapter \ref{s:esp8266}. The module contains the \gls{tcpip} stack, micro-controller (application processor) running the user program, \gls{wlan} and light indication, all in one piece, so this greatly simplifies the design process and allows for more focus on the actual measurement circuitry. The ESP-12E has been chosen as an actual module, because of the available certification\cite{online:2ADUIESP-12}, which allows it to be introduced on the market later. It was already shown in the figure \ref{f:esp-12e}. The \gls{pwm} is present there too, so sound indication requires just a sound emitting device.
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.
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 was 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 inaccessible data from completion.
\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.
After a few test runs performed on an assembled client node, the first problem became obvious: the node's application processor (contained inside of the ESP-12E module) starts erratically, when the node is plugged into socket. Investigations of the supply voltage under the oscilloscope shows no difference in voltage surges during the boot-up, either if the processor starts or not, suggesting a firmware problem too. The first 220ms of power line inspection can be seen in the figure \ref{f:oscilloscope}, showing a voltage fluctuations caused by current surges from the processor starting. However, this problem does not occur, when the processor is powered from external source via J3, but otherwise makes the node unreliable to use.
After a few test runs performed on an assembled client node, the first problem became obvious: the node's application processor (contained inside of the ESP-12E module) starts erratically, when the node is plugged into socket. Investigations of the supply voltage under the oscilloscope shows no difference in voltage surges during the boot-up, either if the processor starts or not, suggesting a firmware problem too. The first 220ms of power line inspection can be seen in the figure \ref{f:oscilloscope}, showing a voltage fluctuations caused by current surges drained by the starting processor. However, processor starts every time, when powered from an external source via J3 (when being reprogrammed).
\begin{figure}[ht!]
\centering
@ -24,10 +24,42 @@ After a few test runs performed on an assembled client node, the first problem b
\caption{The power line of the ESP-12E inspected during the boot-up by the oscilloscope - it looks the same either if the processors boots, or it doesn't, suggesting the possible occurence of the ESP8266 firmware problem}\label{f:oscilloscope}
\end{figure}
Ignoring the boot-up problem, the client node is sort of working as indented, apart from one huge problem with the MAX78615 \gls{ic}, that was not apparent during the design stage: the \gls{spi} protocol only allows for 6 bit long memory addressing, enabling only the first 64 words of the memory to be accessed, leaving the 104 words out of 186 completely inaccessible. As a result, from the required data, only RMS Voltage and RMS Current can be obtained. All the data depending on phase shift, namely real power, reactive power and power factor are not accessible.
Ignoring the boot-up problem, the client node is sort of working as indented, apart from one huge issue with the MAX78615 \gls{ic}, that was not apparent during the design stage: the \gls{spi} protocol only allows for 6 bit long memory addressing, enabling only the first 64 words of the memory to be accessed, leaving the 104 words out of 186 completely inaccessible. The details can be observed in the table \ref{t:spi-read} and \ref{t:spi-write}. The byte number 1 contains the \texttt{ADDR[5:0]} value, thus the address can only by 6 bits long. The data are taked directly from MAX78615 data-sheet\cite{online:MAX78615}. As a result, from the required data, only a RMS Voltage and a RMS Current can be obtained. All the data depending on phase shift, namely real power, reactive power and power factor are not accessible.
The \gls{spi} limitation obviously cripples the node's functionality. The protocol was chosen, because the data-sheet for the MAX78615 suggested it as the only way to obtain the instantaneous measurements, as discussed back in the sub-chapter \ref{ss:schematic_pcb}. Although the instantaneous measurements are not required, there was no reason to not enable this feature in the design stage. The fact, that such a limitation exists was observed too late.
Requesting help from the technical support of the \gls{ic} manufacturer, the Maxim Integrated, did not help resolve or at least minimize the damage. They responded, that they are no longer supporting the part in question, because whole power measurement department was sold to another manufacturer based in China, Silergy Corp in March 2016.
There are multiple, rather cosmetic issues, that does not affect the functionality of the board, but are imposing small physical troubles. They include the following:
@ -41,7 +73,7 @@ There are multiple, rather cosmetic issues, that does not affect the functionali
Since there exists a possibility to read the RMS Current drawn by the appliance at measured RMS Voltage, at least the apparent power can be obtained by multiplying it, described in deeper detail back in a sub-chapter \ref{ss:ac_power}.
Having something to work with gives opportunity to continue the work, despite the fact that the desired real power will not be obtained. Client node makes statistical median of the measured current and voltage and every 10 seconds sends them to the could database, creating a data stream. The sample of the stream can be seen in the table \ref{t:cloud_samples}. The timestamp is in the internal format, allowing transformations to any other desired format easily.
Having something to work with gives an opportunity to continue the work, despite the fact that the desired real power will not be obtained. Client node makes statistical median of the measured current and voltage and every 10 seconds sends them to the cloud database, creating a data stream. The sample of the stream can be seen in the table \ref{t:cloud_samples}. The timestamp is in the internal format, allowing transformations to any other desired format easily.
\setlength{\tabcolsep}{.5em}
\begin{table}[ht!]
@ -64,7 +96,7 @@ Having something to work with gives opportunity to continue the work, despite th
\end{tabular}
\end{table}
The data from the could data stream are then visualised on the server node via plotting library, provided by GoogleAPIs. The web interface can be accessed via \texttt{http://vameter.ddns.net}, a \gls{ddns} redirect service provided by \texttt{http://no-ip.com}. It traslates the \gls{dns} to the \gls{ip} of the server node on the local network. If there were multiple client nodes, and the \gls{ip} of the server node should change, this way all of them would be updated. The illustrative results can be seen in the figure \ref{f:plot_preview}. The mentioned apparent power is obtained by multiplying current and voltage, as has been already stated, so these values are not stored or displayed explicitly.
The data from the could data stream are then visualised on the server node via plotting library, provided by GoogleAPIs\cite{online:googleapis}. The web interface can be accessed via \texttt{http://vameter.ddns.net}, a \gls{ddns} redirect service provided by \texttt{http://no-ip.com}. It traslates the domain name by a\gls{dns} to the \gls{ip} of the server node on the local network. If there were multiple client nodes, and the \gls{ip} of the server node should change, this way all of them would be updated. The illustrative results can be seen in the figure \ref{f:plot_preview}. The mentioned apparent power is obtained by multiplying the current and voltage, as has been already stated, so these values are not stored or displayed explicitly.
\begin{figure}[ht!]
\centering
@ -74,6 +106,17 @@ The data from the could data stream are then visualised on the server node via p
The web interface also contains a button for shutting the appliance on or off (by controlling the electromechanical relay K1). It consists of simple ON/OFF button that changes its value accordingly to the relay's state. It also uses the mentioned \gls{ddns} service to contact the server node.
\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 does not pose a significant problem at all, because a lot of them still lies in the region inaccessible by \gls{spi} (due to the bad \gls{ic} design by its manufacturer, there is simply no way of accessing instantaneous measurements stored in memory outside of the first 64 words). Also, \gls{i2c} requires one less pin than \gls{spi}, thus leaving more pins on the ESP8266 and MAX78615 for some additional future 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, utilising one of its free multio-purpose \gls{io} pins. Fundamental part of responsibilities of the \gls{ic} is to track the phase shift, thus being informed about the zero-crossing\cite{chappell2013introduction}. Relay switching locked to the zero-crossing allows for a graceful start ofthe appliance. 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.
It would be really helpful to address the cosmetic issues, outlined back towards the end of a sub-chapter \ref{ss:problems}. Also, to reduce the cost, the programming circuitry described in sub-chapter \ref{ss:schematic_pcb} could be removed from the PCB and moved onto the programmer itself. To reduce the size, the fuse could be replaced by the smaller size one, or even better, the miniature resettable \gls{ptc} one, proposed back in the chapter \ref{ss:hw}. The connectors for mains could be replaced by fast-on type to simplify the final assembly process. The crystal Y1 could be replaced by a miniature resonator to reduce the size too.
There is always a room for improvement, but the last bigger proposed one 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 the 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 eliminate the need for an external \gls{ddns} server.
Peter Babič
8 years ago