Big commit containing detailed schematic, BOM, a lot of glossary
entries, truth tables and references to the datasheet of the parts
mentioned in the schematic.
@ -19,7 +19,7 @@ They are also divided to a hardware part and software part. Software is easier t
\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 (configured and working) with a \gls{led}
\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}
@ -85,51 +85,142 @@ The measuring devices, from now on called \textbf{client nodes}, will consist of
\subsection{Hardware components breakdown}
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 is already integrated as a \textbf{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 actual ESP-12E module should be used, because of the available certification\cite{online:2ADUIESP-12}, which allows it to be introduced on the market later. It was shown in the figure \ref{f:esp-12e}. The \gls{pwm} is present there too, so sound indication requires just an additional sound emitting device.
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.
Talking about the measurement circuitry, the viable candidate is MAX78615 \cite{online:MAX78615} with the companion \gls{ic} MAX78700 \cite{online:MAX78700}. The couple \ref{f:schem_block} 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}.
Luckily, a particular part of the required functionality for the client node is already integrated as a \textbf{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 actual ESP-12E module has been chosen, 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.
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 a \textbf{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 actual ESP-12E module has been chosen, 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.
\caption{Greatly simplified schematic of a \textit{client node} sketching the inner working}\label{f:schem_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 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 the linear transformer coupled with the 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.
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), galvanic isolation via the 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}.
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 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 design}
\subsection{Schematic and 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.
\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}
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}
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).
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 solution 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.
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 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.
Peter Babič
8 years ago
