RE: [Discuss-gnuradio] OFDM - on air?

[Tom Rondeau]

> -----Original Message-----
> From: address@hidden [mailto:discuss-
> address@hidden On Behalf Of Dominik Auras
> Sent: Tuesday, February 27, 2007 10:09 AM
> To: address@hidden
> Subject: [Discuss-gnuradio] OFDM - on air?
> 
> Hello,
> 
> I'm currently trying to make your ofdm simulation work with two usrp
> rev4. The scripts benchmark_ofdm_tx.py and ...rx.py are modified in
> order to send (I looked on the examples in the directory
> "examples/python/digital/").
> 
> Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two
> Flex2400RF boards used. (Maybe my first faults lay here)

Actually, your first fault was using the code ;) We made a lot of progress
last week, but we still have a ways to go before we get it to work over the
air. OFDM requires a high dynamic range, and clipping can happen easily. We
haven't really analyzed this yet. 

If you want to start playing around with it, benchmark_ofdm.py does a
loopback simulation with optional AWGN and multipath channels between the Tx
and Rx blocks. We're hoping to inject some quiet time into this simulation
to test the signal acquisition capabilities. That is, we know that under
steady-state conditions we synchronize pretty well, but we don't know the
transient behavior when we first get s signal into the receiver.
 
> I also recorded some seconds to a file so I can now replay the same
> scenario.
> 
> The first thing I observe is that the synchronisation needs to know a
> value for the SNR. Fiddling around with that, the synchronizer starts
> the sampler even if no signal present (at high SNR-value), but no
> samples get through it if the value is lower than 8.

Yes. We hope to make that more automatic if we can.
 
> The correlator block thinks to have found the known symbols sometimes in
> the noise. And, very confusing to me, the first ofdm symbol, after the
> correlation found a peak, is always the first known symbol - even in
> absence of a signal.
> 
> The message "found at search delta..." appears very often, compared to
> your simulation.
> It looks like the following lines (I also edited some blocks to output
> debug info):

That's a little disturbing. The search delta should only appear if we
correlate to the known PN sequences. Granted, we didn't do a good job in
creating these two symbols, I still don't think we should often randomly
correlate against noise with 200 symbols.
 
> found at search delta: 1,
> demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
> 9  bf  f9  f5  16  73  45  9c   a  e2         len: 25
> bin 1   h_sqrd = ( 37442.839844, 1714.728149 )   power = 42633.847656
> real(h)/p = 0.878242    angle = 0.045764
> 
> This is repeated until I kill the process. There are also other outputs,
> with more "demod out" lines grouped together etc.

Yes, we've injected a lot of debug information here, but I thought the code
checked in had that output turned off. Are you using the newest code (and
yes, I did just check a few new things in that we didn't do before Matt
left).
 
> e.g. the first lines after the gr_buffer warning
> bin 0   h_sqrd = ( 2.125927, 1.626051 )  power = 2.299746
> real(h)/p = 0.924418    angle = 0.652948
> found at search delta: 0,
> demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
> 9  bf  f9  f5  16  73  45  9c   a  e2         len: 25
> demod out:   18  3c  8d  b3  e7   9  5b  cf  f4  d6  52  3d  a0  d2  be
> 1a  a8  9c  4a  a7  a1  36  9a  85  19         len: 25
> demod out:   e9  9c  88  d9  c4  93  db  c7  c6  9d  87  49  21  b1  3a
> 40  12  6f  27  30  de  a5  c8  97  f2         len: 25
> demod out:   7f  a5  bb  14  54  b4  84  e5  e9  3f  e9  9d  f5  a5  44
> 54   0  fb   6  21   0  44  49  9f  fa         len: 25
> 
> 
> Thank you very much in advance
> You did a great work on gnuradio!!
> Dominik

Thanks! It's a bit premature still, but I'm sure we'll all be glad for more
feedback as it comes together.

Tom