future.tex

This a framework to test new ideas in transmission technology. Actual development is a LDPC-coder in

\part{Future thoughts}

\chapter{STFA}

The STFA being a complex module and having evolved over two years, it would be
a good idea to re-write it once completely. Here are some ideas on what should
be mended and what thoughts should go into a re-structuration of the STFA.

\section{Antenna}

The antenna should be a module on its own with an output for the received
samples and an input for the sent samples. These two ports should then be
connected to the stfa. Advantages:

\begin{itemize}
\item{Configuration} If for a given antenna we have special parameters, we can
define them as easily as in any module
\item{Clarification} It gives a more constant concept in the software-radio
\item{Universality} For the moment the software-radio is very TDD-based with
the STFA. If the antenna is really an independant module, it would be much more
easy to implement other stuff
\end{itemize}


\section{\label{future_stfa_chains}Chains}

The way chains are linked to the STFA is very kludgy. While things are quite OK
for RX-chains, it is really not optimal for TX-chains. Consider figure
\ref{fig:stfa_tx_kludge} where on the left-hand side you see the actual
implementation. The user has to define which modules have to be called at which
moment with two function-calls like:

\begin{quotation}
\texttt{swr\_stfa\_notice\_sdb( stfa, 2, source1 );\\
swr\_stfa\_notice\_sdb( stfa, 5, source2 );}
\end{quotation}

\begin{figure}[h]
   \centering
   \includegraphics[width=12cm, keepaspectratio]
   {figures/stfa_tx_kludge}
   \caption{Actual and proposed design of the TX-chain alertion}
   \label{fig:stfa_tx_kludge}
\end{figure}

In order to simplify things and thus taking away possible sources of error, it
would be much better, if the STFA would consider the chains on its own, like
show in the right-hand part of the figure.

For the TX1-chain, not much would change, only the two above-mentioned
function-calls could be left out, because the STFA would call the RRC-module
with a message like \emph{SUBS\_MSG\_PRODUCE\_DATA}. The RRC-module in turn
would
call the Map-module, which would call the Source1-module. Then, the
Source1-module produces some data, and everything is like before.

For the TX2-chain, the distribution of the time of calculation would even be
more uniform. If you consider the left-hand side, all the calculations for all
the modules is done during slot 3 and 4, even though about half of the
calculations are not needed before slot 7! Now, if the STFA would be smart
enough to not only call the modules with a message
\emph{SUBS\_MSG\_PRODUCE\_DATA}, but also tag the modules passed this way, only
the necessary calculations would be carried out. 

So, at the beginning of slot 3, the RRC would be notified with
\emph{SUBS\_MSG\_PRODUCE\_DATA} and tagged active. Then the Map-, Split-, and
finally the Source2-module would be notified. Once the Source2-module produced
its data, the inverse way will be taken. An important point is to note that the
Split-module produces both branches of data, but that only the left branch is
followed.

Then, at the beginning of slot 5 \footnote{Coincidence: this is the same slot
as the result of the left branch}, the RRC of slot 7 would be notified, which
would notify the Map-module, which would see that it has some data to process,
and stop the notification of further modules. It then processes the data, hands
it to the RRC, which processes its data, too, and hands it to the STFA.

\subsection{Implementation}

In fact, it is not really necessary to tag the data. Each module could just

\begin{itemize}
\item{Check inputs} for whether all necessary inputs are filled with data
\item{Notify} upper modules if this is not the case
\item{Process} the data
\end{itemize}

The idea is that the notification of the upper modules happens synchronously,
that is, the notification only returns once it has been carried out. The module
can then assume that the data is available.

There are a lot of special cases, just a few here:

\begin{itemize}
\item{Multiple inputs} of a module, where one or more may be inactive, that is,
not connected
\item{Loops} for creating incremental coding
\end{itemize}


\chapter{Visualize}

 Reading through the reference-part of the visualize-tool, one gets the
impression that this tool has been glued together (like oh so many others) more
randomly than anything else. Well, unfortunatly, this is true. One project
would be to re-design the classes of this tool, and then re-write a more nice
version of it.

 The steps to do so could include the following:
 
\begin{itemize}
\item{Understand} and look at the existing code. Using a tool like Umbrello,
one can get quite fast a basic understanding of which classes use which classes.
\item{Design} a new class-model, where each class has a well-designed purpose.
\item{Rewrite} the whole tool, doing mostly copy-paste constructs.
\footnote{Important: go step-by-step with easy testable parts}
\end{itemize}