As the signal-processing part and the framework is very flexible, different operating-modes are possible:
In the following sections, the advantages of each of these are listed.
As the name indicates, this is used to test the basic functionality of a module. Usually it includes a simple chain that has only the most basic components in it in order to test the module. Like this one can test the module in a simple environment, before going through the more real and more complete test in a real-time communication.
To test a mapper-module that maps bits into complex symbols, it would be enough to have the chain as depicted in fig. @show modules: source->mapper->block->slicer->sink@ For convenience, the source can contain readable text-messages that are printed by the sink and can be verified by hand.
The block module exists in different variants, where MIMO channels and multi-tap fading channels can be simulated, both in a convenient, deterministic manner.
As already described in section 9.3, the software-radio can be run either locally without the RF-hardware and in a user-space mode, or it can be run in real-time using special RF-hardware for transmission and reception. While the former is much more easy to debug, only the latter allows to make real-world measurements and confirmation of theoretical results.
In the software-radio, both modes are transparent to the user, as the decision between the simulation or the real-time mode only has to be taken when running it. For the user, in either case, the channel is represented by the STFA.
Sometimes it is too complicated to take care about all the synchronisation and fading-problems. Then you can chose to run your modules to test in a local-loop, and thus always be synchronised.
When running in simulation-mode, the channel-server makes sure that the sent samples are received at the same time. If you run the radio in real-time mode, then you have to make sure to connect the output of the cards with the input through a cable.
TODO: update for ICS-example
This section describes a basic system with two radios, following the example of the radio found in Radios/Simple/BS and Radios/Simple/MS. It is important to know about this if you want to do more than just run the examples. You will learn about the most important modules, how to put them together and what make the thing going.
Looking at fig. 11.1, you can see two parts: a master and a client11.1. The communication channel in this example consists of three slots, of which only two are occupied11.2. The part in the middle, where the tree slots reside, is called STFA, which means Slot To Frame Allocation. This is the most basic module that you will find in mostly all of the software-radio. The input of the STFA are sent through the antenna, while the received signal from the antenna is passed through the output of the STFA. As you can see in , the antenna is a placeholder for either a real channel or just a simulation.
This is a short overview of the different modules:
The masters task is to send out the synchronisation-signal on it's slot 1, combined with the data-signal that tells an eventual client its required tx-gain. The tx-gain of the client is calculated with the power received on slot 2. If it is below a certain threshold, the master considers that no client is sending, and puts the tx-power to 0. If the receiving-power is above a certain threshold, the tx-gain is adjusted to what the master would like to hear. This task in fact is done automatically by the sch_send module.
While the master is quite static, the client has to do lots more:
Once the primary synchronisation is achieved, it will set up some modules to decode and demodulate the synchronisation-channel, as well as set up a tx-channel on slot 2.
After this it has to keep up the synchronisation, because the master and the client don't have exactly synchronised clocks.
Linus Gasser 2004-04-14