Signal Processing

Our goal was to find a suitable tradeoff between code re-use and performance of the software-radio. This is why we chose to have a modular framework, running on a RTLinux-platform. In the following sections, you will learn about the following items:

• DBG the interface to the GUI
• Framework which makes it possible that modules can interact with each other and the outer world
• STFA the interface to the channel

DBG

Framework

The modules, which define the specific task of the software-radio, are surrounded by a framework that takes care of the book-keeping tasks necessary to guarantee a good working together of the different modules.

There are three parts:

• Modules the specific description of different signal-processing parts, like pulse-shape filter, coding, mapping, and others
• CDB Class Data Base, where a reference to every available module is stored
• SDB Subsystem Data Base, which contains a reference to every instantiated and thus active module, as well as the glue that makes it work

Modules

The communication system is built out of modules. Each of the modules has a classroom-style function. As an example, in a simple one-way communication system, the transmitter could consist of a first module that maps bits into signal space points and a second module that maps signal space points into samples. In the corresponding receiver you may find a module that implements the matched filter, and another module that decides what was transmitted.

Signal processing modules have inputs and outputs for the signals being processed. They also have a configuration-part to control the behavior of the module (e.g. the desired amplification for an amplifier) and statistics to display relevant information (e.g. internal variables). This is shown in fig. 8.1.

Figure 8.1: Two simple chains and a module in detail

Each of the modules can exist in multiple copies. The framework (composed of CDB and SDB) makes sure that each copy can work independently of the other copies, not unlike the class/instance-behaviour of C++ or other object-oriented languages.

CDB and SDB

The Class Data Base (CDB) and Subsystem Data Base (SDB) make it possible to use the modules in an object-oriented approach. While the CDB holds the static information about a module, such as the names and types of the configuration-parameters, the SDB holds an actual implementation of a module, with the specific configuration-values that may differ from one implementation to another.

An overview of the CDB and SDB can be found in fig. 8.2. It shows part of a running software-radio that has two transmitting and two receiving slots. ^8.1 On the left side you see the CDB that holds a description of each module that has been loaded in the software-radio. On the right-hand side, you see the actual instantiations of some modules present in the CDB.

The loading of the modules happens usually at start-up, but theoreticaly it's also possible to load further modules once the software-radio has been started. While loading, a module informs the CDB about it's presence, and includes the input/output signal-types, it's name, configuration and statistics-names and -types. After that, the module is inscribed in the CDB, but not yet not active.

Once a module is needed in the software-radio, it is instantiated, that is, a running instance of the module is created. This includes reservation of memory needed for the different variable parts, as well as initialisation of these parts. After a module is instantiated, it can be connected to other modules and can perform signal processing.

Figure 8.2: The CDB and SDB

STFA

The Slot To Frame Allocator (STFA) is a module that makes the connection between the antenna and the rest of the modules. It offers a frame-based, slotted TDD interface to the rest of the signal-processing modules.

There exist two STFAs, one for the old hardware and one for the new, ICS-based hardware. The first is called stfa, while the second is called stfa_ics.