visualize2.tex

软件无线电的平台

\documentclass[a4paper,11pt,titlepage]{article}
\usepackage[english]{babel}
\usepackage[T1]{fontenc}
\usepackage[dvips]{graphicx}

\title{Semester Project Report : \\ \Huge \textbf{Extension of the Graphical User Interface for the LCM Software Radio}}
\author{Porchet~Vincent \\ 3th year Computing Science Section Student\\ Mobile Communication Labotory \\ \textbf{Supervisor} : Linus~Gasser  \textbf{Teacher} : Bixio~Rimoldi}
\begin{document}
\maketitle
\tableofcontents
\listoffigures
\pagebreak


\section{Introduction}

In this chapter, we have a look at the LCM Software Radio and 
the goal of this project.


\subsection{LCM Software Radio}

A good and short definition for the software radio project is given in the report
of Ferreiro and Braure \cite{rep} : 

\begin{quote}
The \emph{{}``Laboratoire de communication Mobile (LCM) Software
Radio''} Test-bed is a project with the objective of designing and
implementing a real-time software platform to validate advanced mobile
communication signal processing algorithm. 
\end{quote}
It's an important and large project working in two modes : 

\begin{enumerate}
\item in real-time mode, with real ``on the air'' communications 
\item in simulation mode, with a simulated channel
\end{enumerate}
Seen from the GUI, the LCM Software Radio does basically two things
\cite{rep} : 

\begin{enumerate}
\item Load the software radio core components. The information related to
these elements is stored in the folder \texttt{cdb/} (\texttt{class
database}) of the \texttt{sradio/} root directory. 
\item Load as many \emph{instantiated} classes (subsystem) from \texttt{cdb}
as we want into the radio system. The subsystem is composed by a list
of \textbf{S}ignal \textbf{P}rocessing \textbf{C}lasses (\textbf{SPC}).
We name SPC elements \textbf{modules} in the report. The information
related to the subsystem is stored in the folder \texttt{sdb/} (\texttt{subsystem
database}) 
\end{enumerate}
The whole information we need is contained in the \texttt{sdb} directory.
I name the SPC elements \textbf{modules} like my predecessors and write \textbf{sr} for \textbf{software radio} in the report.


\subsection{The Project}


\subsubsection{The GUI at the Beginning}

The GUI parses and exracts the data generated from the \emph{LCM SR},
builds the GUI information with : modules, interconnections modules
informatio and shows them.\\
It uses a data structure of the \emph{LCM SR} which is described in the report from
Ferreiro and Braure \cite{rep} and which I briefly recalle here : 

\begin{itemize}
\item For each module in the SR, the \texttt{sdb/} directory contains a sub-directory. In each of these sub-directories, we have files that
contain some information with respect to this module (i.e. \texttt{name} contains the name of
the module or \texttt{stats} contains the statistics related with
the module). 
\item We have the following C++ classes : 

\begin{description}
\item [Module~:]Is an instance of an SPC and contains all information
related with this particular instance. 
\item [IOLink~:]Represents input/output links that connect modules
together. 
\item [Block~:]This class represents a block of data that
is load into memory and plotted. 
\item [Port~:]Subclass of block that initializes an I/O port 
\item [Stats~:]Second subclass of block, implementing statistics data. 
\item [ModuleGenerator~:]The object that browses through the file
system and creates the modules to appended it to the mapper's module list. 
\item [Mapper~:]The mapper's task is to take care of displaying the modules
on the GUI and has the responsibility to draw them with their links.
\item [Controller~:]The controller is the entity that control the refresh
and which redraws the data. 
\item [Interface~:]The graphical interface's main part. 
\item [CanvasView~:]The class that handles the mouse events. 
\item [Show~:]Is used to display some statistics data or the output of a
module. 
\end{description}
\end{itemize}
%
\begin{figure}[htbp]
\begin{center}
\includegraphics[ width=13cm]{oldGraphical.eps}
\caption{Simplified UML class diagram showing the classes
related to the graphical part (from \cite{rep}) at the beginning}
\label{old1}
\end{center}
\end{figure}


%
\begin{figure}[htbp]
\begin{center}
\includegraphics[ width=13cm]{oldControl.eps}
\caption{Simplified UML class diagram showing the classes
related to the SR data (from \cite{rep}) at the beginning}
\label{old2}
\end{center}
\end{figure}


The figures \ref{old1} and \ref{old2} show how the modules are linked and
related to the SR data and graphical part.\\
 With this structure, the GUI draws and connects the module, shows information
about the modules and plot data (with the GUI).


\subsubsection{The Goal}

The tasks was to implement the following features : 

\begin{itemize}
\item Add a tab-bar to show more that one SR instance at the same time
(in simulation mode). 
\item Change the configuration of the SR using the GUI (in real-time and simulation). 
\item Export graphics (done by show) in \texttt{.ps} (\texttt{postscript})
and \texttt{.m} (\texttt{matlab}) format. 
\item Create (and export) new plot with two statistics from one or two modules (selected with the GUI). 
\item Draw a timed graphic using one selected statistics . 
\end{itemize}
The implementation is done with the \emph{Qt toolkit}


\section{The Tab-Bar's Creation}

It was the first part, easy to implement, but I discovereed the Qt library and the existing GUI.\\



\subsection{The Idea}

With the simulation mode of the SR, we can have multiple radios on the
same machine. With the tab-bar we can show multiple views in the same window
and thus increase the user-friendlyieness.\\
 The tab-bar is useful only when the user wants to test more than one
SR at the same time. I choose to implement four possibilities : 

\begin{enumerate}
\item the user gives a \texttt{sdb} path (no tab-bar, only one path) 
\item the GUI finds a real-time SR (no tab-bar) 
\item the GUI finds in \texttt{/tmp/} directory at least one \texttt{proc.\#}
directory (tab-bar with a tab for each \texttt{proc.\#} directory) 
\item the user doesn't give a \texttt{sdb} path and the GUI doesn't find anything
(no tab and no SR) 
\end{enumerate}

\subsection{Classes and Control Flow}

To implement these possibilities, I modified the class \texttt{Interface}
and created a class \texttt{RadioView}. \texttt{Interface} inherits
always from \texttt{QMainWindow} but doesn't contain a \texttt{CanvasView}
and does't create a \texttt{Controller}. Depending on the four possibilities discussed in 2.1, the \texttt{Interface} creates: 

\begin{enumerate}
\item a \texttt{RadioView}
\item a \texttt{RadioView}
\item a \texttt{tab-bar} that is an instance of \texttt{QTabWidget} and has a tab that contains a \texttt{RadioView}
for each configuration 
\item a \texttt{label} that is an instance of \texttt{QLabel}
\end{enumerate}
The \texttt{RadioView} creates the \texttt{Controller} and
contains the \texttt{CanvasView}. \texttt{RadioView} inherits from
\texttt{QWidget}.\\
 The \texttt{Interface} keeps the control on the \texttt{tab} and gives
the update control to the \texttt{Controller} (as before) but through
the \texttt{tab-bar} and the \texttt{RadioView}. Each \texttt{radioView}
is created independently of the other with its own \texttt{Contoller},
but only the visible \texttt{tab} is updated.\\
 The figure \ref{graphicaltab} and \ref{controltab} show how the
additional classes are inserted and their relations with the graphical
part and SR data.

%
\begin{figure}[htbp]
\begin{center}
\includegraphics[ width=13cm]{newGraphical.eps}
\caption{Simplified UML classes diagram showing the class
related to the graphical part after the implementation of the tab-bar}
\label{graphicaltab}
\end{center}
\end{figure}


%
\begin{figure}[htbp]
\begin{center} 
\includegraphics[scale=1.75]{newControl.eps}
\caption{Simplified UML classes diagram showing the class
related to the SR data after the implementation of the tab-bar (the
additional part only)}
\label{controltab}
\end{center}
\end{figure}



\section{Changing the Configuration}

The configuration of the SR modules can be changed. In this part
we show how to do that with the GUI. \\



\subsection{The Idea}

The task is to read the actual configuration from the file-system. Then we have to create
 a window with all the parameters of the module and initialize them with the actual values. 
Any change has to be written back to the SR.


\subsection{Classes and Control Flow}

I create two new classes to do this job:  \texttt{ConfWind} and \texttt{Config}.
 I modified the \texttt{ModuleGenerator}: when the \texttt{ModuleGenerator} creates
 a module, it creates (with \texttt{getConfigFile}) a \texttt{config} list (each \texttt{config}