|Subject:||Re: [Discuss-gnuradio] OFDM test with USRP|
|Date:||Thu, 19 Mar 2015 13:37:53 +0100|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0|
I have built a tx and a rx grc flowchart for OFDM using USRP. I found the range of the amplitude of the input is fairly small in order to get it working (i.e., the USRP at the rx end can successfully decode the packets.) I wound if anyone can share some thoughts about this? I've been stuck here for several days.there's very many factors limiting the decodability of a transmission -- the main being SNR, especially since you get problems the further you move away, but also aspects like the increased multipath effects, that the equalizer might or might not be up to compensate.
What you're seeing might be something else, though:
Through my test, I found the const in multiply_const in the tx part (which corresponds to amplitude adjustment) needs to be (0.05, 0.025).that value definitely has the effect of limiting the sample amplitude that goes into your USRP. The USRP driver framework maps values from -1;1 to (DAC_min; DAC_max), basically. Driving the USRP with values close to (or even over) 1.0 will lead to clipping/gain compression problems. However, small values of course lead to "weak signal" on average, leading to low SNR. The OFDM Tx that you use internally uses apropriate scaling to limit the values to magnitudes <= 1.0, so I'm a bit surprised your constant is so small.
That is a problem so common in transmitters, especially in OFDM, that there's an abbreviation for that PAPR - Peak-to-Average Power ratio.
You often combat that by doing appropriate coding, with the aim of guaranteing that no info symbols that map to time signals with strong peaks exist. However, that means that you can't use all the information "capacity" of the OFDM words -- and will be slower in the end. You can solve that by ignoring the clipped/compressed peaks and fix the resulting packets by doing error correction -- but that also comes at the price of less bits per second, since you have to add sufficient redundancy in the transmitter. Your third option is to just don't care so much and retransmit broken packets -- for low packet error rates, that might be sufficient.
I'm a bit surprised, though -- you just feed in random information, and that should be white, which means that packets with unhealthily high PAPR are seldom.
You should save the samples that come out of the OFDM mod block using a file sink, and analyze them later; look for samples with magnitude >1.0 (they shouldn't be there, because the output of the internal IFFT is scaled with 1/sqrt(fftlen)).
However, when the const value increases, for example, to 0.06. the PER is around 0.0044That doesn't sound half bad, considering you don't do any equalizing. I think (I'm not totally sure, was too lazy to look into the source code just now) that the OFDM implementation (you're using the older one, the newer one is cooler) doesn't do much on the receiving side to recover the signal.
Have a look at the rx_ofdm example (in /usr/[local/]share/gnuradio/examples/digital/, or so). That's a bit more advanced than your RX.
On 03/19/2015 01:34 AM, Henry Jin wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|