# OFDM test with USRP **URL:** \ **Category:** GNU Radio\ **Created:** [March 19, 2015, 1:35am UTC](https://www.ruby-forum.com/t/ofdm-test-with-usrp/234639 "2015-03-19T01:35:47Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 19, 2015, 1:35am UTC](https://www.ruby-forum.com/t/ofdm-test-with-usrp/234639/1 "2015-03-19T01:35:47Z")
Hi everyone, 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. To quantify the packet reception performance, I modified digital.crc32\_bb so that even when the crc test fails, the wrong packet is still fed to the output. In this way, I can evaluate the packet error rate (PER). 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). In this range, the PER can be 0. However, when the const value increases, for example, to 0.06. the PER is around 0.0044. When we further increase the const value to 0.08, the PER is above 10% or even higher. I guess this is probably because the input signal amplitude of the USRP needs to be in a certain working range. However, it seems to me this range is too small. Besides, how can I find some numerical statistics about the amplitude limitation? On the other hand, if the amplitude is decreased to 0.02, many packets will be failed to synchronize. But I do observed that the packets successfully synchronized are also correctly decoded. In other words, the PER is still 0, but the number of packets correctly decoded is actually much smaller than the number of packets sent. I also tried to enable the two disabled blocks in the files but it is of no help. Thanks for any comments. link: [https://www.dropbox.com/s/ndrtide1g73u5ju/grc\_ofdm\_rx.grc?dl=0](https://www.dropbox.com/s/ndrtide1g73u5ju/grc_ofdm_rx.grc?dl=0) [https://www.dropbox.com/s/8g3kg2tg6pdh0dy/grc\_ofdm\_tx.grc?dl=0](https://www.dropbox.com/s/8g3kg2tg6pdh0dy/grc_ofdm_tx.grc?dl=0) ---
**Author:** ![henry32](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f9ae1b/32.png) [@henry32](https://www.ruby-forum.com/u/henry32)\ **Post date:** [March 19, 2015, 1:39pm UTC](https://www.ruby-forum.com/t/ofdm-test-with-usrp/234639/2 "2015-03-19T13:39:53Z")
Hi Henry, > 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.0044 > That 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. Greetings, Marcus On 03/19/2015 01:34 AM, Henry J. wrote: > Hi everyone, > > 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.