test.tex

\subsection{Power Supply}
When in the process of building something it is important to check to see if
what you designed for is similar to the results you are receiving. That is why
it is important to run test occasionally to see if the results match. In this
section we will be going through the steps that would be taken in order to
verify the accuracy of our designed power supply. It is of great importance
that the power supply works as expected otherwise the entire project would fail
to work properly. Our power supply consists of various lines each operating at
different voltage levels. It is important that we check each level to see if
they are as we anticipate them to be.

\subsubsection{Line Integrity}
For our boards we have a 12V line, a 12V line, a 5V line, a 3.3V line, and
another line at 120VAC. Each line can and should be tested and measured.
Ideally this testing will be done during the prototyping stage of assembling
our design.  The earlier we test the boards the better. If we continue to
recheck our values at each progression (from one type of prototyping to
another) then we can ensure that nothing abnormal happens as we continue to
make changes. The first level of prototyping will occur at the breadboard
level. At this stage we have nothing more than the parts we wish to put on the
board along with the breadboard. First we will hook up the AC power to the
transformer, on the other end of the transformer we can check to see if the
120VAC was converted as expected into 24VAC. Although this could be done using
a basic multimeter, using an oscilloscope is nice because it allows us to see
the entire waveform. Next we can test the circuit after the rectifying diodes.
Once the voltage is measured we should expect to see values close to 33.9V
since the AC voltage level does not translate exactly into the DC values. At
this point we can also see what our ripple is, either by using traces or by
having the oscilloscope give the max and min values of the circuit. Finally we
can test to see if the DC buck regulators are working as expected. Since we are
using the same adjustable part for the DC to DC converter we really need to buy
one LM2576 switching regulator for the sake of prototyping. The 5V buck
regulator feeds into the linear regulator that will also be tested. At the
breadboard level we can use the probes to pinch the circuit, once we are
prototyping with practiced etched boards we will need to hold the probes onto
wire of the boards.

\subsubsection{Battery Backup}
The backup battery is another power source that will need to be checked.
Usually for most buck regulators there is a minimum voltage level that they
will accept in order to convert that voltage to the level that they are
designed to yield on the output. The only buck regulator that we will need to
use is the 5V regulator. We need to make sure that the battery that we are
providing is of a sufficient size such that the regulator is still able to
accept that voltage and convert it into the desired output signal. Although we
have the information from the datasheet on what values of voltages it will
accept, it still is good idea for us to test different input voltage levels to
see what the cutoff is for our specific regulator. With that information
we{}'ll be sure to put in a backup battery of a sufficient enough size to
account for whatever the results may be.

\subsection{Base Station}
The base station is the most complex item to test and verify functionality.
There are a lot of modules working together to make the base station work with
the WHCS network. This is why testing these certain aspects of the system will
help ensure good performance and prove that the individual subsystems are
functioning properly.

\subsubsection{LCD Control}
Controlling the WHCS network from the LCD is a key part of the design. The base
station should be able to accept touch inputs from the resistive touch screen
on top of the LCD, dispatch that event to an underlying UI element, and cause
some action to occur. If the button to command the control module that is
responsible for the electronic door strike is pressed, this information must
flow quickly and correctly through the base station's code. A simpler test
would be the toggling of a remote LED by hitting a button on the LCD. This test
would prove many things correct simultaneously.

\subsubsection{LCD and NRF Simultaneous}
One consideration that was discussed earlier was the fact that the base
station's microcontroller has a limited speed. The NRF, LCD, and BlueTooth
modules will need to be serviced as quickly as possible by the base station
MCU. If there were to be an error in the code that handles the LCD drawing,
such as a slow graphics drawing loop, then the performance of all the other
modules would suffer. In order to stress test the system, a test case where
many packets are being sent and received over the NRF radio, while an expensive
graphics drawing operation is occurring. If either module takes too much
execution such that the other suffers, then the code structure will have to be
rethought and designed in order to avoid this starvation. A solution to this
problem if it arises would be to have points in either process where the action
can be paused or canceled to be resumed at a later time. That way the MCU can
perform the most important task at any one time. This would be partially
handled by the NRF radio generating interrupts when a new packet has been
delievered, but the packet still needs to be fetched and processed.

\subsubsection{UART and Software Serial}
The UART is a quintessential part of a microcontroller development system
because it allows for easy debugging and testing. The UART can be used to log
information to a screen to show the internal state of the microcontroller and
therefore the system it is controlling. The UART can also be used to give
simple commands to the microcontroller that would otherwise be given through
other components attached to the microcontroller. The base station for WHCS
will have a BlueTooth module connected directly to the Rx and Tx lines so the
lines will be blocked for a simple UART chip. However the BlueTooth module
itself can be used for debugging. In WHCS an Android device will be used to
host the application to interact with the system. The Android play store has an
application available for download called BlueTerm. With this application any
Android phone will be able to easily connect to the BlueTooth module that is
connected to the base station. An Android phone will be a viable option for
printing out debug information and performing tests that would benefit from the
ability to manually input certain commands directly through the UART.

We realized that there may be certain times during testing and debugging that
the BlueTooth module would not serve as a good method for printing out
information to a terminal. For example the BlueTooth module won't be
usable for testing when we are programming the BlueTooth module as mentioned in
\autoref{sec:bt-hc-05} or when we are testing things that require interaction with the
WHCS Android application. For these cases we will have an alternate UART chip,
the FT232RL FTDI, designated for debugging and testing. This will be a simple
UART module that connects to two pins on the base station's
microcontroller and then to a computer's USB port through a mini-USB to
USB connector. Since the base station's Rx and Tx lines will be
occupied by the BlueTooth module, this serial module will have to be connected
to two GPIO pins of the microcontroller and we will have to utilize software
serial. There are already public libraries and routines available for
implementing software serial both in half-duplex and full-duplex operating
modes. The forum AVRFreaks.com has plenty of information on the topic and we
will base our routines for software serial debugging and testing off of the
examples listed on their site. The only things that we should have to specify
are the two pins that will operate as the transmitter and the receiver on the
microcontroller. It is possible that we will only need half-duplex operation to
confirm all of our test-cases and debugging.

\subsection{Control Module}
The control modules are significantly easier to test than the base station
because of the usage of a single major module - the NRF radio. Some control
modules will have specific roles that require specialized testing, but the
common functionality is the most important to be tested. All other verification
will build off of the results of this initial testing.

\subsubsection{UART Chip Testing/Debugging}
Unlike the base station the control modules will not have a BlueTooth module
attached to the UART that can be used for debugging. The absence of the
BlueTooth module frees the Rx and Tx lines of the control module
microcontroller{}'s UART. This means that the FT232RL FTDI chip that will be
used for debugging and testing the base station when the BlueTooth module is
unavailable will be a suitable option for the control modules. The ATmega328
registers for operating the UART will be fully operational for debugging and
testing and we can even leave the serial module in circuit for UART debugging
access at any time. This is because there will be no other need to use the Rx
and Tx pins of the control module microcontrollers. Unlike the base station the
control modules will suffer no limitations from the implementation of software
serial routines. The control modules will be able to operate in full{}-duplex
mode. In full{}-duplex mode we will be able to give commands to the control
modules that would otherwise have to be received from the base station through
the radio transceiver. This will allow for ease of development and testing.

\subsubsection{Command Execution}

The control modules will frequently be receiving commands from the base
station. There will be different types of control modules that execute
different commands. Whenever the control module receives data from the base
station that signifies that a command should be executed the control module
should carry out certain operations to fulfill the request. Tests will need to
be carried out when the control modules are setup so we know that the control
modules are all capable of completely executing the command sets that are
available to them. The tests will need to be decoupled from the communication
pipeline of the base station in order to ensure that no factors outside of the
control modules scope are interfering with the test. Command execution testing
will be executed through the microcontroller{}'s UART port. Commands will be
given just as they would be given via the base station, the only difference
will be the method through which the control module receives the command.

For each type of control module the full set of actions available to it will be
listed. From the list for each control module the commands to perform those
actions will be given through the UART. The tester will document the success of
each individual command given. The command execution tests will pass once the
control modules for every independent role can perform their tasks completely
and without error. The known control modules roles and actions available to
them are listed in \autoref{tab:ctrl-mod-role}. All of the actions listed in the
{}``Commands Available{}'' column must be performed correctly in order to
ensure the proper operation of the control modules for WHCS.

\begin{table}[H]
\centering
\begin{tabular}{|l|l|}
\hline
{\color{black} Control Module Role} &
{\color{black} Commands Available}\\\hline
{\color{black} Light/Outlet Module} &
{\color{black} Toggle On},
{\color{black} Toggle Off},
{\color{black} Check State}
\\\hline
{\color{black} Door Strike Module} &
{\color{black} Lock Strike},
{\color{black} Unlock Strike},
{\color{black} Check State}
\\\hline
{\color{black} Sensor Module} &
{\color{black} Read value}
\\\hline
\end{tabular}
\caption{a tabularization of control module roles and the available commands}
\label{tab:ctrl-mod-role}
\end{table}

\subsection{Door Access}
One of the most critical functions for WHCS is the control over a door.
WHCS must verify that the door can be correctly engaged and disengaged
wirelessly from commands by the base station LCD or Android phone. Both paths
of execution need to be tested and verified for correct functionality in these
areas to ensure that no homeowner will be left stranded with out a way in to
their home.

\subsection{Android To Base Station Communication}
Once all of the independent components of the base station have been tested and
shown to be working correctly it will be time to see if the base station is
able to communicate with the Android device. This test will require that the
base station{}'s microcontroller is hooked up to the HC{}-05 BlueTooth module
and that the Android device has BlueTooth enabled. Confirmation that the base
station can communicate to the mobile phone is essential for the proper
operating of our system.

\subsubsection{BlueTerm}
The simplest method we have for full{}-duplex communication between the base
station and an Android phone is BlueTerm.  BlueTerm is a free terminal
application on Android. It allows for scanning for BlueTooth devices,
connecting to other devices, and setting up the framing of packets. Using
BlueTerm we will be able to connect to the HC{}-05 on the base station and send
serial data to the microcontroller. The microcontroller will be able to receive
the data from BlueTerm and also reply with data by using the HC{}-05. By
writing a simple echo routine on the base station microcontroller that receives
data from the UART and then echoing it back out of the UART we can test whether
or not the BlueTooth communication is working. With this simple test setup we
will be able to quickly test the functionality of our circuits once we create
our printed circuit boards. We just need to open up BlueTerm, connect to the
HC{}-05 module, and then type any letter into BlueTerm while awaiting the
letter to be echoed back. If the letter is echoed back then we know that the
connection is good and we are able to send data from Android to the base
station. If the letter is not received then there is an issue in the base
station. The error could be coming from the UART routine, the circuit
connection, or the BlueTooth module, but most likely if this test fails it will
be because of the base stations circuit connections.

\subsubsection{BlueToothListener}
BlueTerm will be a very useful application that we can rely on to ensure that
the link between the Android device and the base station is functional.
BlueTerm will not suffice to ensure that our application can communicate to the
base station. In our application we will be using raw BlueTooth sockets for
data exchange with the base station. The main class that will handle
communicating to the base station is the BlueToothListener which is mentioned
in the Android application section of this document. Testing this class will be
essential to ensure that the communication link is working correctly for our
application. BlueToothListener will have access to the socket that wraps the
buffers for communicating with the base station microcontroller so writing to
and reading from this socket will need to be performed. When we have tested and
confirmed that we are able to use the socket in the BlueToothListener class for
full{}-duplex communication then we know that our application is fully capable
of sending whatever data we wish to exchange.

The BlueToothListener class is decoupled from other classes that handle what is
done with the data received. This design will allow for modularity in testing.
We can make a test class that subscribes to the BlueToothListener class{}'s
data received event and then asserts that the data is what we expected. Then
when we want to use the BlueToothListener for the actual application and not
just testing we can simply unsubscribe the test asserting class from the data
received event.

\subsubsection{LED activation test}
Activating an LED will be a standard test that we use during prototyping and
testing for WHCS. For Android to base station communication testing, activating
an LED ensures that the base station is able to perform commands based on the
data exchanged between the Android device and the microcontroller. The LED
activation test can be performed through BlueTerm or through the raw BlueTooth
socket that is present in the BlueToothListener class. This will model
situations where the user of WHCS wants to alter the state of the system from
the Android phone. Toggling the state of an LED is the simplest form of
physical state change. When we are able to turn our LED on and off we know that
the Android to base station communication link is fully operational and we will
be able to control the system from the mobile device.  \autoref{tab:test-led-act}
shows the way the test will be implemented. The microcontroller will receive
bytes from the mobile device. Based on the byte that we send the
microcontroller should perform the required action. The table shows what data
results in the LED on state as well as the LED off state.

\begin{table}[H]
\centering
\begin{tabular}{|l|l|}
\hline
{\color{black} Data sent to microcontroller} &
{\color{black} LED state}\\\hline
{\color{black} {}`A{}' (0x41)} &
{\color{black} ON}\\\hline
{\color{black} Anything but {}`A{}'} &
{\color{black} OFF}\\\hline
\end{tabular}
\caption{LED Activation Test Commands}
\label{tab:test-led-act}
\end{table}