> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:discuss- > [EMAIL PROTECTED] On Behalf Of Dominik Auras > Sent: Tuesday, February 27, 2007 10:09 AM > To: discuss-gnuradio@gnu.org > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio