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.
131 lines
15 KiB
131 lines
15 KiB
\section{Realisation}
|
|
|
|
The manufactured client node has been inserted into the enclosure\cite{online:enclosure}, portrayed in the figure \ref{f:enclosure}, containing an European mains socket (female) on one side and an European mains plug (male) on the other side, forming a man-in-the-middle adaptor, that can be non-invasively put between wall socket and an appliance. The result can be observed in figure \ref{f:project_inside}.
|
|
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{enclosure}
|
|
\caption{The 3D visualisation of the enclosure, displaying both the plug and the socket}\label{f:enclosure}
|
|
\end{figure}
|
|
|
|
\begin{figure}[]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{project_inside}
|
|
\caption{The view into the client node's enclosure, before the final assembly, exposing top side of the board containing linear transformer T1 (green), mains connectors J1 and J2 (blue), a fuse holder for F1 (yellow-ish), a relay K1 (white) and an ESP-12E module}\label{f:project_inside}
|
|
\end{figure}
|
|
|
|
\subsection{Discovered problems} \label{ss:problems}
|
|
|
|
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
|
|
\includegraphics[width=1\textwidth,angle=0]{oscilloscope}
|
|
\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 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.
|
|
|
|
\setlength{\tabcolsep}{.3em}
|
|
\begin{table}[ht!]
|
|
\centering
|
|
\caption{Single Word SPI Read Command}
|
|
\label{t:spi-read}
|
|
\begin{tabular}{|c|c|r|r|r|r|r|l|r|}
|
|
\hline
|
|
\multicolumn{1}{|r|}{\textbf{Byte\#}} & \multicolumn{1}{r|}{\textbf{Bit 7}} & \textbf{Bit 6} & \textbf{Bit 5} & \textbf{Bit 4} & \textbf{Bit 3} & \textbf{Bit 2} & \multicolumn{1}{r|}{\textbf{Bit 1}} & \textbf{Bit 0} \\ \hline
|
|
0 & \multicolumn{8}{c|}{0x01} \\ \hline
|
|
1 & \multicolumn{6}{c|}{ADDR{[}5:0{]}} & \multicolumn{2}{l|}{0x00} \\ \hline
|
|
2 & \multicolumn{8}{c|}{0} \\ \hline
|
|
3 & \multicolumn{8}{c|}{0} \\ \hline
|
|
4 & \multicolumn{8}{c|}{0} \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
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.
|
|
|
|
\setlength{\tabcolsep}{.3em}
|
|
\begin{table}[ht!]
|
|
\centering
|
|
\caption{Single Word SPI Write Command and Data}
|
|
\label{t:spi-write}
|
|
\begin{tabular}{|c|c|r|r|r|r|r|l|r|}
|
|
\hline
|
|
\multicolumn{1}{|r|}{\textbf{Byte\#}} & \multicolumn{1}{r|}{\textbf{Bit 7}} & \textbf{Bit 6} & \textbf{Bit 5} & \textbf{Bit 4} & \textbf{Bit 3} & \textbf{Bit 2} & \multicolumn{1}{r|}{\textbf{Bit 1}} & \textbf{Bit 0} \\ \hline
|
|
0 & \multicolumn{8}{c|}{0x01} \\ \hline
|
|
1 & \multicolumn{6}{c|}{ADDR{[}5:0{]}} & \multicolumn{2}{l|}{0x02} \\ \hline
|
|
2 & \multicolumn{8}{c|}{DATA{[}23:16{]} @ ADDR} \\ \hline
|
|
3 & \multicolumn{8}{c|}{DATA{[}15:8{]} @ ADDR} \\ \hline
|
|
4 & \multicolumn{8}{c|}{DATA{[}7:0{]} @ ADDR} \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
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:
|
|
\begin{itemize}
|
|
\item The J3 header is wrong pitch (2mm instead of 2,54mm)
|
|
\item The mounting holes are too small diameter
|
|
\item The longer side of the board is 1mm wider than desired, it doesn't fit easily into the enclosure
|
|
\end{itemize}
|
|
|
|
\subsection{Data representation within the web interface}
|
|
|
|
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 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!]
|
|
\centering
|
|
\caption{Sample of the data of the measurements stored in the cloud database, showing 10 successive samples}
|
|
\label{t:cloud_samples}
|
|
\begin{tabular}{|r|r|r|}
|
|
\hline
|
|
\multicolumn{1}{|c|}{\textbf{current}} & \multicolumn{1}{c|}{\textbf{voltage}} & \multicolumn{1}{c|}{\textbf{timestamp}} \\ \hline
|
|
1.0821 & 237.1633 & 2016-04-19T16:26:53.834Z \\ \hline
|
|
1.2323 & 237.0149 & 2016-04-19T16:26:41.787Z \\ \hline
|
|
1.0335 & 234.3102 & 2016-04-19T16:26:31.168Z \\ \hline
|
|
1.6476 & 233.5277 & 2016-04-19T16:26:19.157Z \\ \hline
|
|
1.0879 & 235.6132 & 2016-04-19T16:26:08.485Z \\ \hline
|
|
1.2149 & 238.0802 & 2016-04-19T16:25:57.706Z \\ \hline
|
|
1.1474 & 237.1673 & 2016-04-19T16:25:45.881Z \\ \hline
|
|
0.9841 & 238.3774 & 2016-04-19T16:25:35.115Z \\ \hline
|
|
0.9922 & 238.8315 & 2016-04-19T16:25:23.355Z \\ \hline
|
|
0.9598 & 236.3844 & 2016-04-19T16:25:12.715Z \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
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
|
|
\includegraphics[width=1\textwidth,angle=0]{plot_preview}
|
|
\caption{The preview of the visualised data from the data stream displaying 14 hours of data; it can be seen when the appliance was in standby mode (red) or the periodical fluctuations of the mains voltage (blue)}\label{f:plot_preview}
|
|
\end{figure}
|
|
|
|
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{Measurement calibration}
|
|
|
|
Since the client's node is performing measurements of physical quantities, it is reasonable to perform the initial calibration, to make the device as accurate as possible. Since the actual measuring unit, the MAX78700\cite{online:MAX78700}, is an \gls{adc} converter, it cannot provide the results in an actual volts and amperes. To be able to interpret the 24-bit number obtained from the the conversion process, we have to multiply it by calibration constants. They depend on the resistors surrounding the converter.
|
|
|
|
This process is also outlined in the reference design\cite{online:SONOMA} provided by Maxim, displaying the calibration constants tailored for the configuration suggested by it, along with the formulas to do the calculations.
|
|
|
|
The calibration performed in the laboratory resulted in similar, but not entirely equal calibration constants. The difference could be caused by a little bit different lengths in \gls{pcb} tracks and different length and material of the conductors, with respect to the reference design, which needed to be taken into consideration.
|
|
|
|
|
|
\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 a such design is the 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. The linear voltage regulator could also be replaced by a smaller one, since the power consumption across whole node is not that high overall.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|