Before going into details about what is a software-radio, and what it can be used for, I will give an overview of this document, so that you know where to start first.

This document is separated into six parts:

• Introduction - this is what you're reading right now. It gives some basic definitions and ideas about the signal-processing part as well as the chosen implementation.
• Architecture - here you'll learn more about the design of the different aspects of the software-radio
• Reference Manual - when you need to know about a certain function how to use it or what it does, this is the place to go. Usually you'll need the knowledge from the Technical Documents to know everything.
• How-to - a more practical approach, this could also be called tutorial, as you learn how to use the software-radio step-by-step, without an explanation for the gory details.
• Tipsntricks - a collection of common pitfalls and how to avoid them, plus some help on how to do more unusual things.
• Future Thoughts - lots of things I wanted to do with the software-radio, both technically and experimentally, but that I didn't have any time left. Wanna go for it?

At the beginning of each part, you will find a short overview of the different chapters and what they talk about.

• Motivation - why we want to have a software-radio
• System Overview - the basic building blocks of the software-radio
• Usage - what we are doing with it right now
• Outlook - possible future enhancements

This introduction describes our motivation for building a transceiver based on software-radio, hereafter called software-radio testbed, and gives an overview of the general philosophy.

<texit>\index{Software-radio!Definition}</texit>

<quote>We talk about Software Radio when the map between the data (sending and receiving) and the data-carrying antenna signal are completely (within hardware limits) specified by the software. Any map that conforms with the hardware limitations (power, bandwith, hardware imperfections) may be implemented by means of an appropriate code. (B. Rimoldi, 2003)</quote>

If you like the idea of a flexible transceiver and are not too concerned with size and energy consumption, then you want your transceiver to be software-radio based. For instance, let us say that you have a software radio mobile phone. This mobile phone is a general purpose communication device with a piece of software that makes it behave like a mobile phone. You can turn your mobile phone into a GPS receiver, or a TV receiver, or a Wi-Fi interface, just by down-loading a piece of software (assuming there is a server that has the software you need).

For the technically oriented person: in a software-based transmitter, the software creates the samples corresponding to the signal to be transmitted. A general purpose hardware converts these samples into the signal that will be sent to the antenna. Similarly, in a software-based receiver, the general purpose hardware takes the signal captured by the antenna and produces the corresponding samples. The software does the rest. The hardware is not aware of the standard you are using: it just converts back and forth between samples and waveforms.

Fig.<ref>cap:fig_dumb_hardware</ref> shows the two main components of a software-defined transceiver. The hardware implements a two-way mapping between waveforms and samples. Except for the possibility of controlling the power of the transmitted signal, the amplification of the received signal, as well as some other parameters that are not relevant for this discussion, this mapper performs the same operation regardless of the standard implemented by the transceiver.

Dumb hardware and intelligent software (dumb_hardware.ps)

<texit>\index{Simulation mode!Overview}</texit> <texit>\index{Real-time mode!Overview}</texit> The software-radio helps to make it possible to implement a signal-processing algorithm which works on samples that are transmitted and received over the air.

Because the debugging is an important part of the implementation of a signal-processing algorithm, the software-radio can be run in either simulation mode or in real-time mode. Fig. <ref>fig:simulation_real-time</ref> shows the software-radio in both modes.

Structure of the software-radio in both modes (simulation_real-time.ps)

<texit>\index{Visualize!Overview}</texit> The Graphical User Interface (GUI) is the only visible part of the software-radio and allows the user to visualize the state of the different Modules as well as to change their configuration. The Channel is a general interface that represents either a Simulation or has access to the Hardware.

In simulation mode no hardware is used, and the whole transmission is simulated in software, including Gaussian noise and multi-path fading. There are no real-time constraints which makes it very easy to debug the algorithm to be implemented.

Of course, if you don't have access to the right hardware, this is the only possibility to use the software-radio. However, the channel-server which links multiple channels together, is written to simulate a real channel with high enough accuracy to test and verify signal-processing algorithms.

In real-time mode only the Graphical User Interface runs on Linux, while the rest of the software-radio runs in Real-Time mode, made available through the use of RTLinux. This is necessary, as the transmission and reception of the samples has to meet time-constraints that are not possible to meet in simple Linux.

As of spring 2004, there exists two hardware-platform that allow the software-radio to do actual transception of samples over the air. The older one, produced by STMicroelectronics, offers a simple SISO-interface, that is, one antenna at each end of the transmission. The newer interface, produced by ICS-Ltd, allows the software-radio to take advantage of a MIMO-channel, with up to four antennas at each end of a transmission. A MIMO-channel is defined as a channel that has more than one transmitting antenna and more than one receiving antenna. These channels have very interesting properties, mainly the possibility to multiply the available channel-capacity by a function of the available antennas.

<texit>\index{Channel-server!Overview}</texit> The software-radio is built to have a two-way communication. So, if you have more than one instance of a software-radio running, they can communicate together.

If the software-radio is run in real-time mode, only one instance of a software-radio can run on a computer. So if you want to communicate in real-time, you need at least two computers.

In simulation mode, the number of instances per computer is only limited by its calculation-power (and the patience of the user ;). A Channel-Server connects all channels of all instances of the software-radio together and makes it possible that everybody can listen to what the other radios are sending.

At EPFL, the Federal Institute of Technology in Lausanne, Switzerland, we use the software-radio both in class and for research purposes.

This chapter gives an overview of what we did with the software-radio until the end of 2003, what we are doing now in winter/spring 2004, and what we are planning to do during the rest of this year.

In class, it has been used to demonstrate the different parts of a radio-transmission, such as modulation, spreading, coding and matched filtering.

For research, we used it succesfully to demonstrate the usability of LDPC-codes over the air and to verify their theoretical performance.

We are looking in the challenges arising from MIMO transmission that is coded with LDPC-codes. There are timing constraints to be solved, as well as theoretical challenges with regard to the MIMO channel to be met.

Different projects for the software-radio are in preparation. These include a better matched filter (channel estimation), ZigBee implementation and the obligatory GPS-decoder.

For the time being, the software-radio is taking a direction towards point-to-point communications in MIMO-channels. We would very much like to study the implications of multi-point to multi-point communications, as well as low-tech implementations of a communication.

Point-to-point communications are quite well known. In fact, every commercially available transmission technology today only works in a point-to-point configuration, usually surrounded with a method to be sure that only one person is sending at the same time on the same frequency.

Different theories describe the possiblity of having more than one sender at the same time and being able to reconstruct the signal at the other end. It would be very interesting to study these theories in a real environment in order to give a feed-back about problems arising when implementing such theories.

The current hardware in use is capable taking advantage of several MHz of spectrum to transmit and receive. HAM-radios only have a couple of kHz of spectrum available for the transcpetion. It would be interesting to study transmission using a sound-card and a HAM-radio, perhaps to propose a better and faster transmission than AX.25.