Re: [Discuss-gnuradio] OFDM: troubles regarding FFT size and decimation factor

[Sebastian Schmid]

Hi everybody.

(I had some problems with In-Reply-To header, so I hope this gets posted 
in the right thread. Otherwise I'm sorry, this message refers to 
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-12/msg00392.html)

Thank you for your answer, Martin.

Martin Braun wrote:
> I'm not sure what your decimation factor does.
By "decimation factor" I mean the ratio the USRPs 100 MS/s gets divided 
with. So a decimation factor of 16 would result in a sampling rate of 
(100 MS/s / 16) = 6.25 MS/s. In the source code I uploaded it's defined 
in send_receive.py and called "samp_rate_div", using 
set_samp_rate(100e6/samp_rate_
div) to set the USRPs sampling rate.

Martin Braun wrote:
> You're using your own OFDM codes, not the GNU Radio ones, right? Can 
you share these?

I uploaded the relevant code, to give some more details:
https://www.dropbox.com/sh/xdo456tvcqiwdwx/Y-6pcz_rR4 
<https://www.dropbox.com/sh/xdo456tvcqiwdwx/Y-6pcz_rR4>

I already tried to shorten it, but unfortunately it's still a bit 
confusing, as the person who wrote it did somehow bypass GNU Radio a bit 
and implemented a lot himself. Therefore, I give my best to describe how 
the code works:

To give a short abstract of the system: 
https://www.dropbox.com/s/iphz1ix4b1as4pd/network_overview.png 
<https://www.dropbox.com/s/iphz1ix4b1as4pd/network_overview.png>
PC1 commands PC2 and PC3 to alternatingly send some data, at first PC2 
is the transmitter and PC3 the receiver, then the other way round.
The network controller (generating and evaluating all the data, using 
NumPy (I)FFT) commands the network daemons to send data and collects 
received data from them via Ethernet.
The network daemons start the send_receive top_block and read from / 
push to send_receive.py queues by add_complex_list_to_queue() and 
fetch_complex_list_from_queue() functions.
send_receive.py is the top_block, connecting message queues to 
jwdiplom.modulator (adding cyclic prefix) / jwdiplom.demodulator 
(Schmidl & Cox synchronisation) blocks, which are connected to UHD 
source/sink.
The PCs running network daemons each are equipped with two network 
cards, one for communication with network controller and one for 
communication between send_receive and the USRP2 devices by UHD.

More in detail:
PC 1 is the network controller, running nc_kanalmessung_AB_BA.py. This 
Python script at first initializes the network daemons running on PC 2 
and 3, it loads the settings dictionary from ofdmsettings.py and chooses 
the right preamble. It does an IFFT on the preamble (so it's in time 
domain, line 99) and sends this parameters by Ethernet to the daemons 
using send_ethernet_packet() (line 135).
On line 107 it creates random data using modulation.py. Again using 
modulation.py, it PSK modulates the random data, adds the pilot and 
empty carriers (as defined in ofdmsettings.py) and does the IFFT 
(modulation.py, line 46). This ready-to-send time domain data is send 
frame by frame to the network daemons (nc_kanalmessung_AB_BA.py, line 
114), once more using send_ethernet_packet() function.

Now it's time to look at network_daemon.py, running on PCs 2 and 3. As 
one can see there are several threads running, at first InitThread gets 
started, waiting for nc_kanalmessung_AB_BA.py sending the parameters and 
preamble. After this happened the GNU Radio action begins: It starts the 
top_block of send_receive.py (handing over the parameters).

send_receive.py features two message queues connected to 
jwdiplom.modulator and jwdiplom.demodulator.
These message queues are read out / feed with data by 
fetch_complex_list_from_queue() (send_receive.py, line 84) and 
add_complex_list_to_queue() (send_receive.py, line 91) functions, which 
get accessed by InputThread and OutputThread in network_daemon.py.

jwdiplom.modulator just adds a cyclic prefix and is connected to 
uhd_usrp_sink_0.
jwdiplom.demodulator implements a Schmidl & Cox synchronization, it is 
connected to uhd_usrp_source_0.
The source files are located in /gr-jwdiplom/python but for easier 
comprehension I made some .grc files and exported them:
https://www.dropbox.com/s/2s7ssy5ypp0ekjy/ofdm_modulator.grc.png 
<https://www.dropbox.com/s/2s7ssy5ypp0ekjy/ofdm_modulator.grc.png>
https://www.dropbox.com/s/34lo5yytx9accgq/ofdm_demodulator.grc.png 
<https://www.dropbox.com/s/34lo5yytx9accgq/ofdm_demodulator.grc.png>

The demodulator block uses two custom blocks:
 - jwdiplom.schmidl_cox_correlator, implementing formula (6) from 
Schmidl & Cox "Robust Frequency and Timing Synchronization for OFDM" 
paper (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=650240 
<http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=650240>)
 - jwdiplom.stream_to_vector_syncd, selecting the right (payload) 
samples according to the sync signal provided by the plateau detector


I know that's a lot of text (and source code) and not relying on GNU 
Radios standard OFDM implementation makes it hard for others to review 
but it would be great if someone could help.

Regards,
Sebastian