\documentclass[titlepage,a4paper,12pt]{article}

\usepackage{graphicx}
\DeclareGraphicsRule{.png}{eps}{.bb}{‘bmeps #1}

\title{Wireless Data Acquisition and Visualization, Peak Power-Point Tracking,
and Driver Information Display for the UK Solar car Team}

\author{Saravana Krishnan Kannan,
		\\Department of Computer Science,
		\\University of Kentucky.
		\\
		\\Advised by: Dr. Raphael A. Finkel}
\date{January 14, 2005}
%\date{\today}

\newcommand{\vdd}{V$_{DD}$}
\newcommand{\vref}{V$_{REF}$}
\newcommand{\circuitx}{power-point control circuitry}
\newcommand{\incst}{\emph{Increase}}
\newcommand{\decst}{\emph{Decrease}}
\newcommand{\panicst}{\emph{Panic}}

\bibliographystyle{unsrt}
\begin{document}

\pagestyle{empty}

\maketitle
\tableofcontents
\listoffigures

\begin{abstract}

I designed and built a wireless data-acquisition and visualization subsystem
for the UK Solar-car team. This wireless data-acquisition and visualization
subsystem allows the UK Solar-car team to monitor the performance of the solar
car by looking at the various signals in the solar car when the driver drives
it. I also built the peak power-point tracking subsystem and the driver
information-display subsystem.  The peak power-point tracking subsystem
operates the solar cells in the solar car at their most efficient operating
point. The driver information-display subsystem displays relevant data to the
driver of the solar car.

\end{abstract}

\pagestyle{plain}

\section{Introduction}

Solar cars run purely on the energy obtained by converting sun-light to
electricity. Solar cars generally consist of a large solar array and an
electric motor mounted in a chassis capable of supporting a driver, wheels
and the above-mentioned components. Solar car technology is still in its
infancy.

Several yearly races are held around the world to motivate the development in
of solar-car technologies. The Formula Sun Grand Prix and the American Solar
Challenge are two such races. The Formula Sun Grand Prix is a track race
conducted on closed-circuit professional race tracks, and the American Solar
Challenge is a cross-country race across the United States of America.

The University of Kentucky Solar-car team is a student organization that builds
and races solar cars. The solar cars built by the University of Kentucky Solar
car team participated in the Formula Sun Grand Prix 2004 and other previous
races. Building a solar car is a multi-disciplinary project that involves
several facets of engineering (mechanical, electrical and computer
science), business and teamwork. The  University of Kentucky Solar car team is
presently working on its next solar car and hopes to develop several more
improved versions of the solar car.

To build a solar car worthy of competing in a race and to facilitate
improvements to the design of the solar car, the Solar-car team needs
to monitor the performance of the car and to log any cases of faulty operation
while the car is racing.

When a car is moving, the solar irradiance depends on the location of the car,
time of day, weather, direction of motion, and so forth. The photo-current from
a solar cell in turn depends on the solar irradiance on the cell. Typical
$I$--$V$ and $P$--$V$ curves of a solar cell without any change in the
irradiation are shown in Figure~\ref{fg:ivcurve} and Figure~\ref{fg:pvcurve}
respectively. Without a peak power-point tracking mechanism under varying
irradiation conditions, a solar cell operates at a very inefficient operating
point in its power curve.  Peak Power-Point Tracking (PPPT) is a mechanism that
regulates and maintains proper output power at the terminals of the solar cell.

\begin{figure}[ht]
  \begin{center}
    \begin{minipage}{2in}
      \includegraphics[height=2in]{IV-curve.eps}
      \caption[$I$--$V$ curve of a solar cell]{$I$--$V$ curve of a solar cell}
      \label{fg:ivcurve}
    \end{minipage}
    \hspace{.5in}
    \begin{minipage}{2in}
      \includegraphics[height=2in]{PV-curve.eps}
      \caption[$P$--$V$ curve of a solar cell]{$P$--$V$ curve of a solar cell}
      \label{fg:pvcurve}
    \end{minipage}
  \end{center}
\end{figure}

The driver of the solar car needs to see certain information like speed and
battery voltage to maintain the ratio of the power consumed to the power
produced so that by the end of the race, the batteries have very little power
left and the car has traveled as far as possible with the available power and
time.

This project's primary goal is to use a micro-controller to sample various
signals in the solar car (when it is racing) and to transmit the data to the
team's base station, where the data is stored for future analysis and
visualization.  Since the input data for Peak Power-Point Tracking and the
information needed by the driver is already available in the micro-controller,
this project also implements Peak Power-Point Tracking and driver information
display using the same micro-controller that samples the analog signals.

During the race, the ratio of the power provided by the solar cells to the
power demand of the car is the key limiting performance factor.  The power
consumption of a solar car is directly proportional to the weight of the car.
Hence, all the components of the solar car are designed to minimize weight and
power consumption.  Being a student organization, the Solar car team has very
little financial backing. This financial condition results in an additional
requirement, that modules built for the solar car that raced in the FSGP 2004
should operate on future versions of the solar car with as little modification
as possible. The project design also takes into consideration the weight and
power consumption limits, financial limits of the team, and the hard deadline
for the solar car to be operational before the Formula Sun Grand Prix 2004
race.

\section{Requirements}

The goals of the project are:

\begin{enumerate}

  \item Sample, transmit to the base station, store, and visualize data from
  the solar car.

  \item Maintain the solar-cell output current close to its peak.

  \item Display relevant data to the driver.

\end{enumerate}

\noindent
The constraints of the project are:

\begin{enumerate}
  \item Low weight
  \item Low power consumption
  \item Reusability
  \item Financial and time limits
\end{enumerate}

\subsection{Data acquisition}

The data-acquisition system must be able to operate over a long distance and
under heavy electromagnetic interference (EMI) and radio-frequency interference
(RFI). The reason for this requirement is that the motor, electrical components
in the solar car and other aspects of the environment\footnote{There have been
reports that one of the solar cars in the race stopped working when it passed
by a high-tension power line. The high-tension power line generated enough
interference to confuse the sensors and the micro-controller in the car.} can
produce a significant amount of EMI and RFI.  Also, depending on the race
rules~\cite{fsgprules} \cite{ascrules}, the base station can be separated from
the solar car by a distance of 10 feet to 2 miles.

The transmitted data should be displayed in real time and stored in a manner
that facilitates categorization based on the signal that is logged and the time
when the signal is logged. The visualization tool should be able to access the
stored data at a later date and display it for inspection.

The data-acquisition system must sample, transmit to the base station and
store the following data:

\begin{itemize}
  \item Speed of the car
  \item Current from the solar array
  \item Voltage across the solar array
  \item Current from batteries
  \item Voltage across batteries

  \item Battery temperatures\footnote{The temperature of a lithium-ion battery
  is monitored while it is charged. A lithium-ion battery should not be charged
  if the temperature of the battery is above some particular temperature
  specified in its data sheet.}

  \item Air pressure inside chassis\footnote{A pressure sensor is placed inside
  the hollow aluminum chassis, and the chassis is pressurized and sealed. The
  pressure inside the chassis is then monitored for sudden drops, which
  indicate cracks in the chassis.}

\end{itemize}

\subsection{Peak Power-Point Tracking}

The PPPT module must maintain the solar-cell output current close to the peak
of the output-current curve.  The PPPT module feeds a 20KHz pulse to the
\circuitx{}, which controls the operating point of the solar cell on its power
curve depending on the duty cycle of the 20KHz pulse.  Increasing/decreasing
the duty cycle of the 20KHz pulse increases/decreases the output current of
the solar cell. The PPPT module must sample the solar cell output current at
least once every 1 to 2 seconds to maintain the output current close to the
peak of the output-current curve.  The power curve of the solar cells depends
on a lot of factors like time of day, direction of motion of car, and weather.

\subsection{Driver Information Display}

The driver needs to see the speed of the car and the voltage across the
batteries (indicative of the charge left on the batteries). The driver needs
the speed of the car when taking the braking test \cite{fsgprules}
\cite{ascrules} and for the obvious reasons of maintaining the speed of the car
and to follow speed limits.

The driver refers to the voltage across the batteries and the current speed to
drive the solar car in a controlled manner so as to balance the ratio of power
consumption to power production.

\section{Design}

\subsection{Layout of the solar-car circuitry}

Figure~\ref{fg:incar} on page~\pageref{fg:incar} shows a block diagram of
the solar-car circuitry. The sensors along with their interface circuits output
a voltage proportional to the analog input signal that they measure.
The voltage outputs of the interface circuits are connected to the
Analog--to--Digital Converter (ADC) input pins of the micro-controller.

\begin{figure}
  \begin{center}
    \includegraphics[height=3.51in]{incar.eps}
    \caption[Block diagram of the solar-car circuitry]{Block diagram of the solar-car circuitry}
    \label{fg:incar}
  \end{center}
\end{figure}

To measure any analog signal, the ADC needs a reference voltage to which it
compares the analog signal. The input voltage to the micro-controller (\vdd)
comes from a regulated power source that is part of the micro-controller
development board. Thus, to simplify the code and to eliminate the need for a
regulated voltage source, the ADC uses \vdd{} as the reference voltage.

The interface circuits are designed to not exceed an output voltage of 3V for
the highest possible input signal and to not exceed 3.26V under any
circumstance.  The \vdd{} is fixed at 3.26V; exceeding that voltage in any
of the micro-controller pins could damage the micro-controller.

The micro-controller samples the signals and adjusts the duty cycle of the
20KHz pulse, sends the required data to the driver information display, and
transmits all the sampled signal values to the base station. The
micro-controller has to select the destination of the serial output before it
sends data to the driver information display or the radio, since both
communicate with the micro-controller through the same serial port. The serial
mux/demux selects the destination of the serial output. The micro-controller
controls the serial mux/demux through a few output pins connected to the
I/O-selection pins of the serial mux/demux.

The serial mux/demux is connected to the LCD display and the amateur radio.

\subsection{Layout of the base-station components}

Figure~\ref{fg:basest} on page~\pageref{fg:basest} shows a block diagram of
the base station. The amateur radio at the base station is connected to a
laptop running a serial-communication daemon. The daemon reads the data coming
in through the serial port, parses the data and writes the data for each signal
to a separate flat binary file.

The front-end GUI checks for changes in the size of files written by the serial
communication daemon and updates the screen if any new data is written to a
file.

\begin{figure}
  \begin{center}
    \includegraphics[width=4.59in]{basest.eps}
    \caption[Block diagram of the base-station components]{Block diagram of the base-station components}
    \label{fg:basest}
  \end{center}
\end{figure}

The serial communication daemon and the front-end GUI are separated into two separate programs
for the following reasons:

\begin{enumerate}

  \item To allow future changes to the communication method or hardware
  without affecting the front-end GUI

  \item To simplify the source code of the serial-communication daemon, since
  simple code helps reduce the possibility of bugs or crashes and eases
  maintenance of the code. The serial-communication daemon is a critical part
  of the data-acquisition module, since a crash of the daemon results in
  irrecoverable loss of transmitted data.

\end{enumerate}

\section{Implementation}

\subsection{Choice of Hardware and Software}

I chose the Cygnal C8051F310 micro-controller for implementing this project,
since it is fast enough to generate a pulse of about 20KHz, which is required
to control the \circuitx{}. It also has 21 ADC inputs, which leaves plenty of
room to add more signals to the list of data that must be sampled.  The Cygnal
C8051F310 also has an UART controller, which is essential for data transmission
and display.

I chose amateur (Ham) radio with packet transmission and reception capabilities
as the method of transmission instead of other wireless technologies like IEEE
802.11 and wireless serial modems. The important factor that determined the
choice is the distance between the solar car and the base station and the
conditions under which the data-acquisition system is expected to work. There
is a significant amount of EMI and RFI on highways (as in the case of the
American Solar Car challenge~\cite{ascrules}), and the distance between the
solar car and the base station is high on tracks (as in the case of the Formula
Sun Grand Prix, where the base station is not allowed to trail the solar
car~\cite{fsgprules}). Only a powerful amateur radio can handle such
requirements. While some wireless radio modems can handle the distance, it is
very unlikely that they would be able to handle the interference. The amateur
radio also passed a practical test: the Big Blue project~\cite{bigblue} at
the University of Kentucky successfully used amateur radios for data telemetry
between a base station and a high-flying glider.

As for the driver information display, I chose a serial Liquid Crystal
Display~(LCD) to replace the initial choice of a PDA for the following reasons:

\begin{enumerate}
  \item It is easier to send data from a micro-controller to the LCD.
  \item The LCD is less expensive.
  \item The LCD has a lower power rating.
  \item The LCD is smaller and easier to fit into the solar car's dashboard.
  \item The LCD has larger text and a better viewing angle.
\end{enumerate}

The programming language of choice for the micro-controller is C, because a C
compiler~(Keil C) comes bundled with the micro-controller development kit, and
it is the only tool that the other EE team members were familiar with.  Also, I
have a lot of experience writing programs in C, and C is my preferred
programming language.

I chose the GTK+ toolkit coupled with C to develop the front-end GUI
visualization program, because GTK+ has a very friendly GUI layout designer
called Glade, is portable to Win32 to a certain extent, and I was already
familiar with GTK+/C.

\subsection{Embedded program}

\subsubsection{Main block}
The embedded program in the micro-controller is the heart of the three modules
of this project. The main block of the embedded program is made up of an
initialization phase and a infinite loop. Every time the micro-controller
is reset manually or is powered up, execution flow starts with the
initialization phase and then enters the infinite loop. The infinite
loop samples some of the signals and then sends the required data to the driver
information display. It also periodically sends the signal data to the amateur
radio for transmission to the base station. Figure~\ref{fg:main} on
page~\pageref{fg:main} shows the activity diagram for the main block.

\begin{figure}
  \begin{center}
    \includegraphics[width=4.59in]{main.eps}
    \caption[Activity diagram: Main block]{Activity diagram for the main block of the embedded program}
    \label{fg:main}
  \end{center}
\end{figure}

The initialization phase initializes the following subsystems of the micro-controller:

\begin{itemize}
  \item \emph{System Clock}: The C8051F310 system clock can operate at several
  frequencies, the highest of which is 24.5 MHz. The system clock is set to
  operate at 24.5 MHz, since an increase in system clock frequency increases
  the execution speed of the embedded program and, more importantly, allows for
  finer control of the frequency and duty cycle of the pulse used for
  controlling the \circuitx{}.

  \item \emph{I/O pins}: The embedded code initializes the I/O pins into the
  proper modes of input/output, analog/digital and push-pull/float\-ing
  mode. The embedded code initializes the I/O pins connected to the sensors
  into input, analog and push-pull mode and all the other I/O pins into output,
  digital and push-pull mode.

  \item \emph{UART}: The embedded code initializes serial communication
  parameters on the UART (Universal Asynchronous Receiver Transmitter)
  controller, such as the number of data bits (8), the baudrate (9600bps),
  parity (none), and the number of stop bits (1).  Both the radio and the LCD
  require the same parameter settings.

  \item \emph{ADC}: The embedded code initializes ADC characteristics, such as
  polled/interrupt-driven, single-ended/double-ended mode\footnote{ADCs can
  operate in two different modes --- single-ended and double-ended.  In
  single-ended mode, the signal is quantified within the voltage range of 0V to
  +\vref{}, thus limiting the quantifiable signals to positive voltage levels.
  In double-ended mode, the lower end of the voltage range can be provided
  separately (generally called the -\vref{}) and the signal is quantified
  within the range of -\vref{} to +\vref{}, thus facilitating the
  quantification of negative voltage levels by providing a -\vref{} less than
  0V.}, left/right justification of the sample data bits and positive reference
  voltage. The embedded code initializes the ADC to operate in polled,
  single-ended mode, with left justification of sample data bits and \vdd{} as
  the positive reference voltage.
  
  \item \emph{Timers}: The embedded code initializes three timers to provide
  the base clock signal for the PCA (timer0), provide the base clock signal for
  the UART (timer1) and produce an interrupt several times a second (timer2).

  \item \emph{PCA}: The embedded code initializes the PCA's (Programmable
  Count\-er Array) CCM0 (Capture/Compare Module~0) to generate a 20KHz pulse
  whose duty cycle can be changed and configures CCM1 (Capture/Compare
  Module~1) to generate an interrupt on the positive edge of a pulse seen on a
  particular input pin.

  \item \emph{Radio}: The embedded code initializes the parameters on the
  radio, such as the call sign (a combination of letters and numbers that
  identify an FCC license, in this case, a license to transmit in the amateur
  radio bands), flow control, use of carriage-return, mode of operation and
  mode of transmission.

  \item \emph{LCD}: The embedded code initializes the LCD to clear the screen
  and turn on the back light. Turning on the back light increases the
  visibility of the data on the LCD screen. This improvement in visibility is
  more important than power conservation, since it reduces the duration of time
  the driver looks at the LCD.

\end{itemize}

In the body of the infinite loop, the embedded program gathers all the sampled
data and sends the required data to the driver information display. If the
\emph{txdelay} flag is set, the embedded program also sends all the sampled
data to the radio for transmission. The value of the \emph{txdelay} flag is set
every \emph{n} seconds and is reset after a transmission. The value of \emph{n}
must be set during compile time to a value that will not overload the radio.
The typical value of \emph{n} is 4 seconds.

\subsubsection{Interrupt-service routine}

The timer2 interrupt-service routine (ISR) is executed every time the 16-bit
timer2 counter overflows. The timer2 interrupt-service routine reloads the
timer2 counter with the initial value of zero, so that the period of the
interrupt is as high as possible. The timer2 interrupts approximately 31 times
per second.  Figure~\ref{fg:timerisr} on page~\pageref{fg:timerisr} shows the
activity diagram for the timer2 interrupt-service routine.

\begin{figure}
  \begin{center}
    \includegraphics[height=6in]{timerisr.eps}
    \caption[Activity diagram: Timer 2 ISR]{Activity diagram for the Timer 2 Interrupt Service Routine}
    \label{fg:timerisr}
  \end{center}
\end{figure}

The timer2 ISR typically executes the PPPT function every 0.5 secs and executes
the speed calculation code every one second. It calculates the speed every one
second to reduce the number of floating-point operations required for the
calculation. The timer2 ISR increments the PPPT delay counter and the speed
delay counter during each execution, and uses the delay counters to determine
the delay between each call to the PPPT function and the speed-calculation
function.  In Figure~\ref{fg:timerisr}, \emph{pt} is the PPPT delay counter.
The motor controller produces \emph{PULSEPERREV} pulses for every revolution of
the wheel of the car that is attached to the motor. The embedded code
increments the pulse counter when a CCM1 interrupt occurs. Every second, the
timer2 ISR reads the pulse counter to calculate the speed, and then resets it
to zero.  Thus, every time the timer2 ISR reads the pulse counter, the value it
reads is equal to the number of pulses per second. The embedded code calculates
the speed using the formula $speed = (pulses$ $per$ $second / PULSEPERREV)
\times \pi \times wheel$ $diameter$ $in$ $miles \times 3600$.

\subsubsection{Peak power-point tracking module}

The Peak Power-Point Tracking function is called twice per second. The PPPT
logic can be represented as a state machine with three states: \incst{},
\decst{} and \panicst{}. In the \incst{} and \decst{} states, the duty cycle of
the 20KHz pulse increases and decreases, respectively. The \panicst{} state is
required as a work-around for the inherent nature of the \circuitx{} to
shutdown if the operating point of the solar cells goes well beyond the peak
power-point of the solar cells.  It might appear that the operating point never
goes beyond the peak power-point of the solar cells, but that is not true: The
operating point changes greatly when there is a drastic change in the lighting
conditions, and suddenly the operating point that was ideal in the previous
execution cycle is beyond the peak power-point in the current execution cycle.
Then the \circuitx{} shuts down and must be reset by bringing the duty cycle to
zero and giving it some time to return to a stable state.
Figure~\ref{fg:ppptstate} on page~\pageref{fg:ppptstate} shows a simple state
diagram of the peak power-point tracking logic.

\begin{figure}
  \begin{center}
    \includegraphics[width=5in]{ppptstate.eps}
    \caption[State diagram: PPPT logic]{State diagram for the Peak Power-Point Tracking logic}
    \label{fg:ppptstate}
  \end{center}
\end{figure}

The peak power-point tracking function uses a variable \emph{state} to
maintain the current state. During each execution, the function first makes
sure that the output current from the solar cells is more than the acceptable
lower limit. If the output current of the solar cells is below the acceptable
lower limit, \emph{state} is set to \emph{PANIC}. Then,
depending on the value of \emph{state}, one of the following
actions is performed:

\begin{figure}
  \begin{center}
    \includegraphics[width=6in]{pppt.eps}
    \caption[Activity diagram: PPPT logic]{Activity diagram for the Peak Power-Point Tracking logic}
    \label{fg:pppt}
  \end{center}
\end{figure}

\begin{itemize}

\item \emph{INCDC}: This state is the `Increase Duty Cycle' state. The PPPT
function first increases the duty cycle. It then compares the current value of
the output current with the previous value of the output current to determine
if the output current has dropped or risen. If the output current has dropped,
the PPPT function increments the drop count; else it decrements (but not below
zero) the drop count. If the drop count is more than the allowed upper limit,
the PPPT function sets \emph{state} to \emph{DECDC}.

\item \emph{DECDC}: This state is the `Decrease Duty Cycle' state. The PPPT
function first decreases the duty cycle. It then compares the current value of
the output current with the previous value of the output current to determine
if the output current has dropped or risen. If the output current has dropped,
the PPPT function increments the drop count; else it decrements (but not below
zero) the drop count. If the drop count is more than the allowed upper limit,
the PPPT function sets \emph{state} to \emph{INCDC}.

\item \emph{PANIC}: This state is the `Panic' state. The PPPT function sets the
duty cycle to zero. After a predetermined amount of time elapses (typically 10
seconds), the PPPT function sets \emph{state} to \emph{INCDC}.  The code
remains in the \panicst{} state for several execution cycles of the PPPT
function to allow time to elapse. The timer2 ISR decrements a \emph{panicdelay}
counter when in the \panicst{} state, and sets \emph{state} to \emph{INCDC}
when the \emph{panicdelay} counter reaches zero.

\end{itemize}

Figure~\ref{fg:pppt} on page~\pageref{fg:pppt} gives a slightly simplified
activity diagram for the peak power-point tracking logic.

\subsection{Front end}

The front end consists of two components, the communication daemon and the
visualization program. The front end is split into these two components so
that future modifications to the method of communication will not affect the
visualization program.

\subsubsection{Communication Daemon}

The communication daemon communicates with the micro-controller in the solar
car through the amateur radio and stores any signal information sent by the
micro-controller in a binary flat file database. Figure~\ref{fg:daemon} on
page~\pageref{fg:daemon} shows the activity diagram for the communication
daemon.

\begin{figure}
  \begin{center}
    \includegraphics[width=4.2in]{daemon.eps}
    \caption[Activity diagram: Communication Daemon]{Activity diagram for the communication daemon}
    \label{fg:daemon}
  \end{center}
\end{figure}

The communication daemon uses a set of proprietary commands to talk to the
amateur radio through the serial port of the computer. It opens the serial
port, initializes the port settings and then sends a disconnect command to the
amateur radio to disconnect any previous connections. It then flushes the
serial port to remove all unread characters.  Then the daemon attempts to
connect the amateur radio in the base station to the amateur radio in the solar
car.  The daemon quits after \emph{MAXTRIES} consecutive connection failures.

If the communication daemon successfully establishes a connection between the
two amateur radios, it reads a line of data from the serial port when data is
available and processes the data if it looks valid. Any line with characters
other than the hexadecimal digits 0 to 9, A to F and blank spaces is considered
invalid and is ignored. If the line read from the serial port has the string
``DISCONNECTED'' as part of the line, the line is considered as a
`Disconnected' status message from the amateur radio. The micro-controller
never transmits a valid data packet that contains the string ``DISCONNECTED''.

When processing data packets, if the daemon encounters a``DISCON\-NECTED''
status message, it sends a `Disconnect' command to make sure the radio is in
`Disconnected' mode. The daemon then tries to reconnect to the solar-car
amateur radio for \emph{MAXTRIES} attempts.

To process a data packet, the communication daemon reads a string of
hexadecimal numbers, converts it to a list of two-byte unsigned integers, and
then stores each of the two-byte unsigned integer to a separate flat binary
file.  The position of the hexadecimal number in the string determines the flat
binary file in which the communication daemon stores the corresponding two-byte
unsigned integer. I chose the two-byte integer as the upper limit of the data
samples, because the micro-controller has only a 10-bit ADC. A precision of
16-bits is adequate for all the signal samples. I chose the flat-binary file
for logging data, since it is a simple format that allows random seeks to any
offset in a file. The ability to seek to a random offset in a file is necessary
to provide the ability to view the history of a signal by scrolling back a
slider in the visualization program. The daemon does not log the time, because
a timestamp requires twice the amount of space a signal sample requires. Also,
the formula, $file$ $creation$ $time + (offset$ $of$ $the$ $signal$ $sample /
(sampling$ $frequency * 2))$, gives the timestamp for the signal sample (same
file must not be used for multiple log sessions).

\subsubsection{Visualization Program}

The visualization program is a GTK+ based GUI that periodically checks the file
database for updates from the communication daemon and displays the signal data
to the user in a convenient form. The user display consists of a global view
(see Figure~\ref{fg:genview} on page~\pageref{fg:genview}) and a
signal-specific view (see Figure~\ref{fg:sigview1} on
page~\pageref{fg:sigview1} and Figure~\ref{fg:sigview2} on
page~\pageref{fg:sigview2}). The global view, which can be found under the
``General'' tab in the GUI, consists of a text box for each sampled signal. The
global view facilitates simultaneous monitoring of all the signals.  The
signal-specific view, which can be found under the other tabs in the GUI, is a
graphical representation of the signal within a specific time interval.  The
signal-specific view gives the ability to view the signal over a specific
period of time.

\begin{figure}
  \begin{center}
    \includegraphics[width=4.9in]{genview.eps}
    \caption[Screenshot: General view]{Screenshot of the general view of the visualization program}
    \label{fg:genview}
  \end{center}
\end{figure}

The visualization program can operate in two modes, tracking mode and reviewing
mode. In tracking mode, the program periodically checks for new signal data and
displays the latest data. In reviewing mode, the program displays the signal
data for a particular time interval; the global view shows values at the end
of the chosen interval. The mode of operation can be different for different
signals.

The signal-specific view is a line graph displaying signal data versus time.
The size of the display window limits the length of the interval, and the
slider at the bottom controls the upper limit of the interval. The label above
the slider indicates the sequence number of the signal sample at the upper
limit of the time interval. When the user moves the slider, the mode of
operation for that signal changes to reviewing mode. When the user presses the
``Track'' button, the mode of operation for that signal reverts to tracking
mode.

The signal-specific view dynamically adjusts the graph to maximize the
usability of the visual content:

\begin{itemize}

\item The scale of the graph changes to fit the height of the window.

\item The spacing between the vertical grid lines of the graph adjusts to
maintain the grid box as close to a square or a perfect rectangle (length an
integer multiple of the breadth) as possible.

\item The spacing between the vertical grid lines of the graph adjusts so the
vertical grid lines do not get so close that the labels in the x-axis overlap.

\item The width of the labels displayed in the x-axis is calculated
dynamically. For example, the program realizes that it requires more space to
display the number ``1234'' than to display the number ``123''. The width of
the labels displayed in the x-axis is based on the largest number displayed.

\end{itemize}

Figures~\ref{fg:sigview1} and \ref{fg:sigview2} show these features
in action.

\begin{figure}
  \begin{center}
    \includegraphics[width=5.3in]{sigview1.eps}
    \caption[Screenshot: Signal-specific view -- 1]{Screenshot of the signal-specific view of the visualization program}
    \label{fg:sigview1}
  \end{center}
\end{figure}

\begin{figure}
  \begin{center}
    \includegraphics[width=5.3in]{sigview2.eps}
    \caption[Screenshot: Signal specific view -- 2]{Screenshot of the signal-specific
    view showing the effects of automatic vertical grid-line spacing
    and graph scaling.}
    \label{fg:sigview2}
  \end{center}
\end{figure}

Dragging the slider on the bottom of the window to change the time interval
viewed changes the graph and the numbers displayed on the x-axis to give the
visual effect of scrolling through a large sheet of graph paper.

The user can customize the GUI to a great extent by modifying the
``scmon.conf'' configuration file. The configuration file allows the individual
customization of the following parameters for each sampled signal:

\begin{itemize}

\item Name of the file from which the data is read. The general practice is to
store each day's data on a different file. This parameter is useful when one
wants to look at data logged several days before.

\item The signal value corresponding to the raw ADC reading 0xFFFF. This
parameter helps calculate the actual value of the signal that is measured by
the ADC. To calculate the actual value of the signal, the visualization program
uses the formula $v = a r / 0xFFFF$, where $v$ is the actual value of the
signal, $a$ is the raw ADC reading for the signal, and $r$ is the signal value
corresponding to the raw ADC reading 0xFFFF.

\item The expected maximum raw ADC reading for the signal, say 0xCCCC. This
parameter, combined with the second parameter, helps the GUI utilize the window
real estate in an efficient manner. For example, if the voltage across ten 12V
batteries connected in series is measured, the interface circuit might be
designed to scale 150V to the reference voltage of the ADC (\vref{}) even
though the maximum possible voltage across the batteries never exceeds 120V (10
x 12V), because it might not be possible to find standard resistor values to
scale 120V to \vref{}. Also, it is a good practice to allow a buffer zone when
scaling voltages, so that unexpected spikes in the voltage do not damage the
micro-controller.  If the program draws the voltage graph assuming the upper
limit on the y-axis is 150V, then one-fifth of the window real estate goes
unused, since the voltage never exceeds 120V under ordinary circumstances. This
parameter helps arrive at the upper limit of 120V for the y-axis, if the
parameter is set to 0xCCCC. To calculate the upper limit for the y-axis, the
visualization program uses the formula $u = m r / 0xFFFF$, where $u$ is the
upper limit for the y-axis, $m$ is the expected maximum raw ADC reading for the
signal, and $r$ is the signal value corresponding to the raw ADC reading
0xFFFF.

\item Color of the graph

\item Whether to draw grid lines (True/False)

\item Grid stepping: the difference in value between two horizontal grid lines.

\item Background color for the grid

\item Color of the grid lines

\item The formatting string to display a value

\end{itemize}

A typical signal section from a ``scmon.conf'' configuration file is given below.

\begin{verbatim}
signal speed
{
 file = "speed.dat"
 rawmax = 150.0
 expectedmax = 75.0
 graphcolor = 0xFF0000
 grid = true
 gridstep = 5.0
 gridbgcolor = 0xDDEEFF
 gridlinecolor = 0x0B2EEF
 format = "%0.0f mph"
}
\end{verbatim}

\section{Conclusion}

Our solar car, called ``Gato del sol 4'', is named after the 1982 Kentucky
derby winner.  Translated from Spanish, it means ``Cat of the Sun''. We
successfully raced our solar car in the Formula Sun Grand Prix 2004 conducted
at Topeka, Kansas, from 17th to 21st May 2004. We came in second in the stock
class~\cite{fsgprules}. Though not the best of the solar cars that participated
in FSGP 2004, our entry performed well for one built by a new team. This was
the first time our solar car went past the qualification rounds and
participated in the race. We completed a total of 79 miles in three days.

The software implemented as part of this project performed well during the
race. The implementation has approximately 1128 lines of C code in the embedded
program and 2550 lines of C code in the daemon and GUI. The PPPT module and the
driver information-display module were used on the race. The wireless
data-acquisition and visualization module was not used because the EE team
member did not have time to build a serial mux/demux circuit compatible with
the micro-controller. The wireless data-acquisition and visualization module
was tested at the UK Solar car team workshop and it worked very well. It
handled disconnects (forced by powering off one of the radios) and automatic
reconnects, and sampled various signals, transmitted them to the base station,
stored them in a database, and visualized them on the GUI without any problems.

This project helped me learn embedded-systems programming from scrat\-ch, kindled
my interest in embedded-systems programming, and provided me with a practical
problem to apply my embedded-systems programming skills on. I improved my GTK+
programming skills and user-interface designing skills by designing a GUI that
was friendly to people who were not programmers. I also learned to operate an
amateur radio station and obtained an FCC technician-class license to operate
amateur radios. Working on the solar car also taught me some basics of
mechanics, electronics and chemical engineering. Another important experience
gained from this project is team work. I learned to communicate with and work
with a team of engineers from various other disciplines like mechanical
engineering, electrical engineering and chemical engineering. 

Though I have reached the end of this work as a Master's project, there is
still room for improvement, and I continue to contribute to the UK Solar car
team. Possible improvements include a transmission method with higher
bandwidth, a network of micro-controllers sharing the work, and better methods
to store and visualize signals. I have worked on getting a sponsor to donate
two long-range serial modems that can communicate between each other to maximum
distance of 25 miles. The serial modems can transmit and receive at 115200bps.
I also helped design a CAN (Controller Area Network) based network of
micro-controllers for the next solar car.

Finally, I thank Dr. Kenneth L. Calvert and Dr. Raphael A. Finkel for guiding
and supporting me in this project.

\nocite{*}

\bibliography{proj-rep}

\end{document}
