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.
242 lines
24 KiB
242 lines
24 KiB
\section{Requirements}
|
|
The device under test will be referred to as \textbf{appliance}. The requirements for the final \textbf{measuring device} are grouped to the three categories. Mandatory requirements are bound to be met at any cost. Some of the high importance requirements can be skipped or slightly modified, if unpredictable obstacles are found. However, they are all assumed to be completed for well being of the project. Optional requirements will be completed only if the resources allow for it.
|
|
|
|
They are also divided to a hardware part and software part. Software is easier to change than hardware and requires hardware to be run on. Software is also limited by the resources provided by the hardware. Therefore, hardware needs to be logically completed first and are also highlighted in figures \ref{f:client_node} and \ref{f:serv_node}.
|
|
|
|
|
|
\subsection{Hardware requirements}
|
|
|
|
\renewcommand{\theenumi}{\Alph{enumi}}
|
|
\textbf{Mandatory:}
|
|
\begin{enumerate}
|
|
\item Measure current, voltage and phase angle simultaneously to calculate the real power and the power factor
|
|
\item More measuring devices can be added to the system by user without \gls{hw} or \gls{sw} modifications
|
|
\item Devices under test run at nominal 230 V, 50 Hz that use two-way or three-way EU plug
|
|
\item Protection against the electrical shock, fire hazard and damage caused by power surges
|
|
\end{enumerate}
|
|
|
|
\textbf{High importance:}
|
|
\begin{enumerate}[resume]
|
|
\item Store the measured data in server's node available non-volatile local \gls{memory}
|
|
\item Completely shut the appliance off or back on
|
|
\item Indicate that the measuring device is active (working) with a \gls{led}
|
|
\item Handle maximum of 8 A currents drawn by the appliance
|
|
\end{enumerate}
|
|
|
|
\textbf{Optional:}
|
|
\begin{enumerate}[resume]
|
|
\item Store the measured data on an \gls{usb} flash disk
|
|
\item Provide \gls{hw} support for some crossed support signalisation (i.e. by sound)
|
|
\item Internet and Ethernet connection on server node
|
|
\end{enumerate}
|
|
|
|
\begin{figure}[ht]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{client_node_diag}
|
|
\caption{The proposed block diagram of a \textit{client node}, including HW requirements}\label{f:client_node}
|
|
\end{figure}
|
|
|
|
|
|
\subsection{Software requirements}
|
|
\textbf{Mandatory:}
|
|
\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 real power consumed for each appliance
|
|
\end{itemize}
|
|
|
|
\textbf{High importance:}
|
|
\begin{itemize}
|
|
\item Graphs of all measured quantities over time
|
|
\item Authentication mechanism
|
|
\item Automatic configuration of the new connected measuring devices
|
|
\end{itemize}
|
|
|
|
\textbf{Optional:}
|
|
\begin{itemize}
|
|
\item Access to \gls{gui} outside of local network
|
|
\item Control Wi-Fi repeater mode to strengthen the signal for client nodes
|
|
\item Send measured data to the cloud storage
|
|
\item Separate administrator (view and change) and user (view only) privileges
|
|
\item Ability to set thresholds for measured data and notify user about crossing them via text based message
|
|
\end{itemize}
|
|
|
|
\newpage
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{server_node_diag}
|
|
\caption{The proposed block diagram of a \textit{server node}, including HW requirements}\label{f:serv_node}
|
|
\end{figure}
|
|
|
|
|
|
\clearpage
|
|
\section{System design}
|
|
|
|
The first mandatory software requirement asks for a web server. It is entirely possible for every measuring device to contain its own web server. However, multiple points are requiring separate parts to work as a \textbf{system}. Two common system structures are \textit{centralised} and \textit{decentralised}.
|
|
Decentralised (peer-to-peer) systems\cite{vu2009peer} are harder to build but are more fail-proof. Since fail-proofness is not mentioned in the requirements, centralised system might suffice.
|
|
|
|
Using centralised system means, that the measuring devices will use one separate accessory, from now called the \textbf{server node}, to do most of the work on the software side. The work includes, but is not limited to, receiving the measured data, storing them, hosting the web server with the \gls{gui} containing all necessary options and information, handling the \gls{usb} or communication with a \gls{cloud} and so on. The block diagram for a server node, depicting required blocks can be seen in the figure \ref{f:serv_node})
|
|
|
|
Where there are at least two nodes in a system, they have to communicate together in a particular way, known to both of them. The web server naturally operates over \gls{tcpip}. Therefore, same networking stack, that is used for communication between the server node and user can be used to communicate to client nodes as well. \Gls{tcpip} hardware is ready to be used and is supporting a full-blown networking \gls{stack}, powering communication over today's networks.
|
|
|
|
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})
|
|
|
|
|
|
\subsection{Hardware components breakdown} \label{ss:hw}
|
|
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 to 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.
|
|
|
|
Talking about the measurement circuitry \ref{f:schem_block}, the viable candidate is MAX78615 \cite{online:MAX78615} with the companion \gls{ic} MAX78700 \cite{online:MAX78700}. The couple should be used, because it provides multiple ways of same voltage level communication with the processor, galvanic isolation via the pulse transformer for improved circuitry protection, great precision, accuracy and utility. The shunt resistor is utilised as a way of obtaining measurements, described in the sub-chapter \ref{ss:pmic}.
|
|
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=1\textwidth,angle=0]{schematic_block}
|
|
\caption{Greatly simplified schematic of a client node sketching the inner working}\label{f:schem_block}
|
|
\end{figure}
|
|
|
|
For the protection against fire a standard glass fuse or a resettable \gls{ptc} fuse\cite{wright2004electric} should be used. Because of the variable nature of most used devices, it is hard to calculate the current consumption of the circuit. It can be measured after the first iteration is manufactured. Thus, the easily replaceable standard glass fuse has been chosen because of its versatility. The circuit protection against high voltage should be solved with an isolated DC-to-DC converter\cite{carr1996linear} or with a linear transformer coupled with a linear voltage regulator\cite{2008linear}. Since the former one is either expensive or hard to design, and this work does not want to focus on more complexities, the latter option has been chosen.
|
|
|
|
Choosing the voltage level for the digital electronics (the output voltage of the linear regulator) is straightforward. Since the ESP-12E works on nominal 3.3V, this is the level that has been chosen. Having \glspl{ic} using the same voltage level removes the need to level-shift the communication between them, thus increasing the simplicity of the design.
|
|
|
|
Talking about the measurement circuitry, the candidate is MAX78615 \cite{online:MAX78615}, working on nominal 3.3V level, along with the companion \gls{ic} MAX78700 \cite{online:MAX78700}. The couple has been chosen, because it provides multiple ways of communication with the processor (buses/serial interfaces), galvanic isolation via a pulse transformer for improved circuitry protection, great precision, accuracy and utility. The resistor network, including the shunt resistor is utilised as a way of obtaining measurements. The shunt resistor is also briefly described in the sub-chapter \ref{ss:pmic}.
|
|
|
|
The remaining part of the client node's block diagram \ref{f:client_node} not yet mentioned is switching. Either a mechanical relay or a semiconductor device, such as a thyristor or a \gls{ssr} isolated by an opto-coupler\cite{trzynadlowski2015introduction} will do. Mechanical relays tend to be larger and produce sound noise, have slow response time, but have inbuilt separate isolation and are capable of switching higher currents without additional thermal issues than their semiconductor counterparts\cite{blume2008electric}. The disadvantages of the mechanical relay are not relevant here, thus it has been chosen.
|
|
|
|
|
|
\subsection{Schematic and PCB} \label{ss:schematic_pcb}
|
|
The detailed schematic can be seen in the figure \ref{f:schem_full}, along with the \gls{bom}, shown in the table \ref{t:bom}. Some parts of it are quite straightforward, but some require less or more description, to avoid confusion.
|
|
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=1\textwidth,angle=0]{schematic}
|
|
\caption{Full client node schematic, providing all the details}\label{f:schem_full}
|
|
\end{figure}
|
|
|
|
In the top section, there is a power supply circuit, which consists of the linear transformer T1, stepping the mains voltage down to the comfortable level of less than 10V AC. The BR1 bridge rectifier MYS80\cite{online:MYS80} is a compact unit, capable of providing up to 500mA@\textasciitilde 10V continuous current, which is split between a relay K1 and a U1 linear voltage regulator LD1117S33\cite{online:LD1117}. Regulator can provide up to 800mA@3V3 of current, which is more than needed, but was picked for its price. Most of the current it provides (around 250mA) is consumed by U4, an ESP-12E module. All the other connected devices, including the relay, have at least an order of magnitude lower current consumption, thus the current provided should suffice. Surrounding capacitors are for smoothing and for preventing the regulator from oscillating.
|
|
|
|
The K1 relay RM96-1011-35-1009\cite{online:RM96} circuit in the top right corner shows relay coil connected as a low-side switch over a transistor Q1. The coil is consuming around 30mA and the transistor BC817-40 \cite{online:BC817} can handle far more, but it was picked, because of its availability. Base of the Q1 is biased over a resistor R1 to be fully open at 3.3V, provided by U4 pin high level. Resistor RN1.2 is weakly pulling the base down until U4 boots up and starts maintaining pin states, to prevent bouncing. The relay itself was picked up, because of low operational voltage, low price and, current consumption and small dimensions. It is cofigured as NC (normally connected), so in case of failure at U4, the appliance will still function as expected. Another less obvious treat of NC is that pulse transformer T2 will not be saturated by coil's magnetic field (which would prevent its function), more details later. The flywheel diode D1 is anti-parallel to the coil, providing a way for a current to flow, when Q1 is cut-off (the coil's collapsing magnetic field is discharged trough D1 to prevent dangerous negative voltage to build up at the collector of Q1). Practically any semiconductor diode would suffice, provided it can handle the peak current. In this case, the common 1N4148\cite{online:1N4148} was picked, again, because of it's availability and price.
|
|
|
|
\setlength{\tabcolsep}{.3em}
|
|
\begin{table}[ht!]
|
|
\centering
|
|
\caption{The truth table of logic implemented by the transistor Q2 and Q3 providing automatic programming and communication interface for ESP-12E}
|
|
\label{t:esp-dtr-rts}
|
|
\begin{tabular}{|c|c|c|c|}
|
|
\hline
|
|
\textbf{DTR} & \textbf{RTS} & \textbf{RST} & \textbf{GPIO0} \\ \hline
|
|
H & H & H & H \\ \hline
|
|
L & L & H & H \\ \hline
|
|
H & L & L & H \\ \hline
|
|
L & H & H & L \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
The application processor U4, an already mentioned ESP-12E module, is connected in a configuration, that allows it to be programmed \textbf{and} to communicate over a serial link without hassle. This functionality is achieved by two standard NPN transistors Q2 and Q3, utilising the DTR and RTS pins of a serial link, switching GPIO0 into required level. The logic implemented by the transistors is described in the table \ref{t:esp-dtr-rts}. The required level is, on the other hand, based on the boot-up state described previously in the table \ref{t:esp-gpio}. The U4 is decoupled by a high-value capacitor for current surges, when using Wi-Fi. The low value capacitor is added for a greater decoupling frequency response.
|
|
|
|
\setlength{\tabcolsep}{.3em}
|
|
\begin{table}[ht!]
|
|
\centering
|
|
\caption{The configuration pins selecting the serial interface of the MAX78615}
|
|
\label{t:max-ifc}
|
|
\begin{tabular}{|l|l|l|}
|
|
\hline
|
|
\textbf{Interface mode} & \textbf{IFC0} & \textbf{IFC1} \\ \hline
|
|
SPI & L & X (don’t care) \\ \hline
|
|
UART & H & L \\ \hline
|
|
I\textsuperscript{2}C & H & H \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
The U3, the data processing unit MAX78615\cite{online:MAX78615}, has two configuration pins, selecting the serial interface (communication bus) used to talk to the application processor U4. The truth table for the pins can be seen in the table \ref{t:max-ifc}. The \gls{spi} has been chosen, because unlike \gls{uart} and \gls{i2c}, it is able to communicate faster, than the sampling frequency of the \gls{adc} (U2), thus getting instantaneous measurements, in case the data are needed. \Gls{spi} requires two more pins from U4, but there are some spare ones, so this is not a problem. Also, the \gls{uart} cannot be used anyway, because U4 uses it for programming and debugging. The unit is utilising external 20MHz crystal and both its power supply pins are decoupled by small value capacitors.
|
|
|
|
The last part of the schematic is the actual measuring circuitry around the U2, the MAX78700\cite{online:MAX78700} \gls{adc}. The whole circuit is obtained from reference design\cite{online:SONOMA} provided by the chip manufacturer. It communicates and obtains the power from U3 via the pulse transformer T2. Care has to be taken when surrounding components emit strong magnetic field, because T2 core could get saturated by it, preventing correct function. This is also the reason, that the relay K1 is in NC configuration - either the relay coil is conducting, or the pulse transformer (in case they are physically situated near each other).
|
|
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=.65\textwidth,angle=0]{pcb_top}
|
|
\caption{The top layer of the designed \gls{pcb} (client node), exposing mainy \gls{tht} components}\label{f:pcb_top}
|
|
\end{figure}
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=.65\textwidth,angle=0]{pcb_bottom}
|
|
\caption{The bottom layer of the designed \gls{pcb} (client node), exposing mainly \gls{smt} components}\label{f:pcb_bottom}
|
|
\end{figure}
|
|
|
|
|
|
\clearpage
|
|
\setlength{\tabcolsep}{.3em}
|
|
\begin{table}[]
|
|
\centering
|
|
\caption{The bill of materials used in a client node design}
|
|
\label{t:bom}
|
|
\begin{tabular}{|l|l|l|l|l|}
|
|
\hline
|
|
\textbf{RefDes} & \textbf{Qty} & \textbf{Value} & \textbf{Name} & \textbf{Pattern} \\ \hline
|
|
BR1 & 1 & & MYS80 & microDIL \\ \hline
|
|
C1 & 1 & 220u & CAP100RP & 2.54/5.08 \\ \hline
|
|
C2 & 1 & 10u & CAP\_TC3216 & TC\_3216 \\ \hline
|
|
C3,C7,C8,C10,C15 & 5 & 100n & CAP\_0805 & CAP\_0805 \\ \hline
|
|
C4, C6, C11 & 3 & 470n & CAP\_0805 & CAP\_0805 \\ \hline
|
|
C5, C13 & 2 & 10p & CAP\_0805 & CAP\_0805 \\ \hline
|
|
C9 & 1 & 1u & CAP\_0805 & CAP\_0805 \\ \hline
|
|
C12 & 1 & 10u & CAP\_0805 & CAP\_0805 \\ \hline
|
|
C14 & 1 & 100u & CAP\_TC3528 & TC\_3528 \\ \hline
|
|
C16 & 1 & 470p & CAP\_0805 & CAP\_0805 \\ \hline
|
|
C17, C18 & 2 & 18p & CAP\_0805 & CAP\_0805 \\ \hline
|
|
D1 & 1 & 1k8 & CD4148WS & DIO\_0805 \\ \hline
|
|
F1 & 1 & & PTF/15 & PTF/15 \\ \hline
|
|
J1, J2 & 2 & & DG301-5.0 & 02P-12 \\ \hline
|
|
J3 & 1 & & 87758-06 & 2x3T/2x2/6x4 \\ \hline
|
|
K1 & 1 & & RM96-1011 & 35-1009 \\ \hline
|
|
L1 & 1 & 1k & MMZ1608S102A & IND\_0603 \\ \hline
|
|
L2, L3 & 2 & 100 & MPZ1608S101A & IND\_0603 \\ \hline
|
|
Q1 & 1 & 1k8 & BC817-40 & SOT23 \\ \hline
|
|
Q2, Q3 & 2 & & BC817-40 & SOT23 \\ \hline
|
|
R1 & 1 & 1k8 & RES\_0805 & RES\_0805 \\ \hline
|
|
R2, R3 & 2 & 1M .1\% & RES\_0805 & RES\_0805 \\ \hline
|
|
R4, R5, R7 & 3 & 750 .1\% & RES\_0603 & RES\_0603 \\ \hline
|
|
R6 & 1 & 8m 1\% & RES\_2512 & RES\_2512 \\ \hline
|
|
R8, R9 & 2 & 10k & RES\_0805 & RES\_0805 \\ \hline
|
|
RN1-RN4 & 4 & 10k & 4D03WGJ0103T & 8/1.6x3.2x0.8 \\ \hline
|
|
T1 & 1 & & TEZ1\_5\_D\_6V & TEZ1\_5\_D\_6V \\ \hline
|
|
T2 & 1 & & Midcom & 750110056 \\ \hline
|
|
U1 & 1 & & LD1117S33 & SOT223-4 \\ \hline
|
|
U2 & 1 & & MAX78700 & uMax-10 \\ \hline
|
|
U3 & 1 & & MAX78615 & QFN-24/4x4x0.5 \\ \hline
|
|
U4 & 1 & & ESP-12E & ESP-12E \\ \hline
|
|
Y1 & 1 & 20MHz & HC-49US & HC-49US \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\clearpage
|
|
\subsection{Software architecture and components}
|
|
As with the hardware components, again, starting with the server node, the board should work alongside the \textbf{OpenWRT} \gls{os}, again, described in a deeper detail in the sub-chapter \ref{ss:openwrt}. It allows for relatively easily configurable network connections\cite{rosen2013linux} and the web-server.
|
|
|
|
The web-server should be handled by some package already available for installation into the OpenWRT distribution. There are various choices. Ordered in an ascending order by their complexity, the most common ones are: \texttt{uhttpd}, \texttt{lighttpd}, \texttt{Apache} and \texttt{nginx}. The resource requirements are proportional to the complexity, and since GL.inet is not an extremely powerful machine, the choice should fall on the more lightweight one from the beginning of the list, with just as many features as absolutely necessary\cite{adelstein2007linux}. The \texttt{lighttpd} was chosen for this task after some research, as it is the best fit for the given criteria.
|
|
|
|
As far as a choice for the web interface programming/scripting language goes, there are three rather good choices: \texttt{Python}, \texttt{PHP} and \texttt{Lua}. There is no exact way to choose - it all depends on the confidence and the efficiency of the implementer, which one fits the best. Any available language will do. However, it should be noted, that \texttt{Lua}, is somewhat superior choice, since two influential software solutions for the proposed system are written in it. On the side of the OpenWRT, we are speaking about the web configuration interface called \texttt{LuCi}\cite{weidner2013linux}, while \texttt{NodeMCU}\cite{kurniawannodemcu} is a \texttt{Lua} eco-system based on ESP-8266. Both solutions are relatively mature and open-source and can be referenced easily. However, the \texttt{PHP} language was chosen, because it is the easiest way to develop the required functionality in it.
|
|
|
|
Another choice lies in the way of storing the measured data on the server. For a local storage, one can either use plain text format for very simple data, or a data-base of some sort, preferably a \gls{rdbms}\cite{sumathi2007fundamentals}. If a data-base is to be chosen, the \texttt{SQLite}\cite{allen2011definitive} is a good choice - it was already noted, that the computational resources are at premium. Everything marketed as lightweight has an edge here. For a remote storage, there is a plethora of cloud-based solutions, ready to employ and use, so this is a very good choice, if an internet connection is available. Because there is nothing preventing us from using the Internet connection in the design, the cloud storage for a data stream named \texttt{phant.io} is chosen as a primary one and \texttt{SQLite} in stored in a local memory is used only as a backup, in case the connection cannot be established.
|
|
|
|
On a client side of a proposed system, there are again three main language options. The first one is the already mentioned \texttt{Lua}. This language is simple, yet not terribly popular. The availability of the design resources might be limited. Second one is the ruler of the micro-controller world\cite{van2001programming}, plain \texttt{C}, suited for more experienced programmer, but providing the highest flexibility. The third choice is to use \texttt{C++} based eco-system, derived from \Gls{arduino}. This choice is far more superior, because it provides access to enormous resources and libraries\cite{seneviratne2015internet} readily available on the Internet with and addition to (mostly) cross-compatible code, which is a nice bonus. This option has been chosen, because it is, again, the easiest way to accomplish the task.
|
|
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{sw_architecture}
|
|
\caption{The block diagram of a data flow in the proposed software architecture, including a client node, a server node, the cloud storage for measurements and an external \gls{ddns} server for providing the \gls{ip} of the server to the client nodes}\label{f:sw_architecture}
|
|
\end{figure}
|
|
|
|
One of the \gls{sw} requirements is to provide the ability to add another measuring nodes without modifications of the existing infra-structure. As it is common in a \gls{sw} world, there are again multiple solution to do this. Since there are so many ways, only the two most viable ones are described. The first is to use automatic configuration sequence, that would be initialized from the server node to communicate to freshly booted up client node. This would work without the Internet connection, but would require additional actions on the side of the user. Another way is to use external \gls{ddns} server to provide the \gls{ip} of the server to the clients. Since it is a centralised resource, all clients get updated simultaneously. It also provides outside of \gls{nat} (local network) access to the server node, which is one of the optional requirements. Since the cloud storage has been already chosen as a primary storage, which requires the Internet connection, external \gls{ddns} server has been chosen for this task. Additional positive side-effect of this choice is, that entire process is invisible to the user, thus simpler to use.
|
|
|
|
All the mentioned SW components are included in a block diagram \ref{f:sw_architecture}. The arrows help indicate which way the data are flowing around the the system, to get the better idea.
|
|
|
|
|
|
|
|
|
|
|
|
|