======Signal Flow======
\index{Signal Flow|(}
For a correct understanding of what happens in the software-radio and where
to insert a new module, it is very good to have an overview of the
signal-flow that goes through the radio. As of the writing of this chapter,
new hardware is being installed in our lab. For this reason, this chapter is
seperated into three sections:
* Common: the common signal-flow
* ICS-hardware: the signal-flow specific to the ICS-cards
* STM-hardware: the signal-flow specific to the STM-cards
=====Common=====
en:research:sr:manuel:signal_common|The common part of the signal-flow|fig:signal_common
In figure fig:signal_common you see an overview of the most common
architecture when building a software-radio. On the left-hand side you see
the transmitting modules while on the right-hand side the receiving modules
are located. Each transmission is built around a //slot// which is a
constant time-slice in the transmission.
====Transmitting====
The most common implementation starts with two blocks that have bits as
output. The //Source// may be anything, from a pseudo-random sequence to a
part of a network-transmission.
These bits go through a //Coding// block, where redundant information
is added, in order to assure some error-resistance when receiving the data.
The ouput of this operation are again bits. For the coding we have
ldpc-codes, convolutional-codes or spreading-sequences which allow also for to
seperate multiple users if they send at the same time-instant.
en:research:sr:manuel:qpsk_space|QPSK signal space|fig:qpsk-signal-space
digraph structs {
node [shape=record];
struct7 [label="Data 1 | Midamble | Data 2";width=5];
}
Position of the midamble|fig:midamble
After the coding, the bits get //Mapped// into symbols. The most common
mapping is a QPSK-mapping, where two bits define one symbol, as can be seen in figure
fig:qpsk-signal-space. The mapper-module supports also other
PSK-mappings or QAM-mappings. But commonly the QPSK-mapping is used.
In the middle of this block, a test-sequence is inserted which is called
//Midamble//, because of it's position in the block, as can be seen in
figure fig:midamble. The goal of this test-sequence is to be able to
estimate the channel at the receiving end and to perform a matched filtering
afterwards, cancelling out any effects due to the channel.
Once these four basic operations are done, the block composed of complex
symbols goes through the hardware-specific part.
====Receiving====
Out of the hardware-specific part, we get again a block composed of complex
symbols. If we have a flat fading channel with only one tap, that is a direct
line-of sight, as well as a perfect synchronisation between the sending and
the receiving part (which is usually NOT the case), then this receivd symbols
would be the same as the sent ones.
In common transmissions, this is not the case. For this reason we have the
//Matched Filtering//, where the midamble from the sending chain is used
to estimate the channel-parameters. Using these channel-parameters, one can
improve the received quality of the signal. The output of this module is the
filtered signal without the midamble. This module usually produces also
information used by other modules, such as //SNR// or //amplitude// of
the signal.
Now that the received signal is filtered, it is ready to be sliced.
//Slicing// denotes the fact of taking a hard decision on the received
symbols. For a QPSK-signal, the quadrant of the symbol gives directly the two
bits. If the signal-alphabet is bigger, one has to calculate the distances
between the received symbol and all possible emitted symbols, and then taking
the smallest distance. A hard decision is usually the worst thing to do.
For example the LDPC-decoder takes the complex symbols directly from the
matched filter and achieves much better results.
After the slicing, we have again a block of bits, which run through the
//Decoder//, where an algorithm tries to correct for transmission errors.
As noted before, decoding on bits is not ideal, but it is what happens in
most school-book examples...
The decoder ouputs again a block of bits that should contain no errors
anymore. This block can now be either used for the network-transmission,
reception of an image, or just to count the number of residual errors, in
order to evaluate a code/decoder-pair.
=====Hardware=====
The hardwares job is to take the signal at it's sampling frequency,
something around 1-10MHz, and to mix it so that it falls in the
carrier-frequency, 1.9GHz, or 2.4-2.48GHz. In order to relieve the hardware
of some very difficult filtering, it is important that the signal sent to the
hardware does not occupy the whole sampling-frequency bandwith, but rather
just a portion of it.
Furthermore it is important that, as the outgoing signal is filtered, as less
as possible intersymbol interference is produced. For this reason, we apply a
root-raised cosine filter, whose Fourier transform is the square root
of the commonly used raised-cosine spectrum. If a root-raised cosine filter is
used at both the transmitter and the receiver, the product of the transfer
functions will be a raised cosine that will give rise to an output having a
minimal inter-symbol interference at the receiver.
The ICS- and STM-hardware differ mostly in two aspects:
* Band while the ICS-hardware wants to have the signal in baseband, the STM-hardware needs the signal in passband
* Signal Unit the ICS-hardware works with complex samples, while the STM-hardware only works with real samples
en:research:sr:manuel:hardware-base|The signal preparation for ICS|fig:hardware-basebanden:research:sr:manuel:hardware-passband|The signal preparation for STM|fig:hardware-passband
The figures fig:hardware-baseband and fig:hardware-passband
depict the steps done to the signal from the fourier-transform point of
view. The range of the fourier-transform has been chosen to be
-\frac{1}{2}..\frac{1}{2}, but one could have
-\frac{f}{2}..\frac{f}{2}
or
-\frac{\pi}{2}..\frac{\pi}{2}
without changing the meaning at all.
====ICS-hardware====
\index{Hardware!ICS}
In figure fig:hardware-baseband, you can see the preperation necessary
for sending the signal to the ICS-hardware. The signal is first upsampled by
a factor of two. This is done by inserting a zero in between two complex
symbols.
Next we apply the lowpass RRC-filter and now we have a signal that occupies
half the bandwith, but at double the symbol rate. Thus, we didn't loose
information.
On the receiving side, exactly the contrary needs to be done: first we apply
the RRC-filter, then we downsample by a factor of two. The filtering is
necessary, as there might be some other signal next to ours. And, because the
reception sample-rate is twice the symbol-rate, we have to downsample by a
factor of two.
====Philips-hardware====
\index{Hardware!Philips}
The latest hardware that is not yet installed has been developed by Philips. It
contains the A/D- and D/A-converters directly on the same board as the RF-part.
The connection to the PC is made via two SCSI-cables, and the PCI-card only
contains simple glue logic to put the data on the PCI-bus or to read it from
there.
This hardware works at 1.9GHz and has a bandwith of 5MHz.
====STM-hardware====
\index{Hardware!STM}
Looking at figure fig:hardware-passband, you can see that for the
STM-hardware, we need to upsample by a factor of four. The filter chosen for
the pulse-shaping is a passband-filter, that has a bandwith of 1/4.
Because the hardware accepts only real samples, we can't keep the signal at
baseband, as a loss of the signal would happen. You can see that by taking
the real-part of the signal, it gets mirrored at the axis. If you do this
with a baseband signal, information loss occurs.
These three operations are done using advanced MMX-operations that manage to
take advantage of the special structures of the filters and the signal.
\index{Signal Flow|)}