# Re: OFDM test with USRP **URL:** \ **Category:** GNU Radio\ **Created:** [March 19, 2015, 6:22pm UTC](https://www.ruby-forum.com/t/re-ofdm-test-with-usrp/234655 "2015-03-19T18:22:05Z")\ **Posts on this page:** 4\ **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, 6:22pm UTC](https://www.ruby-forum.com/t/re-ofdm-test-with-usrp/234655/1 "2015-03-19T18:22:05Z")
Hi Marcus, Thanks for your very detailed comments. My purpose of testing the PER is to facilitate evaluations on further modifications of the codes. I’d like to set up a benchmark like the ones I have shown and then draw a PER vs SNR curve to show the performance just like how we do evaluations theoretically. So I prefer to find the root cause of this phenomenon rather than using error correction or re-transmission. > 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. Originally, I feed in some fixed sequences. The working range of the const value is even smaller, around (0.035, 0.025). So later I replaced it with the random source. Indeed, I saw some improvement but yet not good enough. > 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. > According to my knowledge, the OFDM transceiver blocks I used is the > latest > one. I’ve read all the related codes so I know that there is actually > equalization done on the receiver end. Besides, the more advanced > example > you referred to is actually a breaking down of the receiver block that I > used. In other words, that is the internal implementation of the > receiver > block I used. I will try checking the sample values as you suggested. Also, maybe I’ll also use another USRP to test but I doubt it matters. Best, Henry * * * Message: 20 Date: Thu, 19 Mar 2015 13:37:53 +0100 From: Marcus M?ller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: removed\_email\_address@domain.invalid Subject: Re: [Discuss-gnuradio] OFDM test with USRP Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=“windows-1252” 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. ---
**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, 10:12pm UTC](https://www.ruby-forum.com/t/re-ofdm-test-with-usrp/234655/2 "2015-03-19T22:12:53Z")
Hi Marcus, I later added a throttle and time scope to the tx end to see how large the amplitude can be. Indeed, when the multiplier is 60m, the amplitude increases beyond 1, which will be clipped by the USRP driver. Setting it to be 0.45 seems like a safe choice. For small amplitude cases such as when the multiplier is 20m, the SNR is also low. The reason the OFDM receiver fails to receive many packets is actually because the threshold used in digital.ofdm\_sync\_sc\_cfb() for the plateau detector. Currently, the code leaves the threshold value to be default, which is 0.9. In low SNR cases, in fact, we need to set it smaller to tolerate noise. Originally, let’s say the synchronization rate is only 1% or even lower, after this adjustment, it can be over 90%. I suggest adding a parameter in ofdm\_txrx.py to adjust this parameter. Back to the high SNR cases, one issue puzzling me now is that when the multiplier is 60m, although indeed there are samples exceeding the amplitude limitation of 1, many other samples (in fact most of them) have a small amplitude less than 0.5. This greatly limits the overall SNR we can get. I wonder if there can be any improvements over this? Thanks Henry ---
**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, 11:17pm UTC](https://www.ruby-forum.com/t/re-ofdm-test-with-usrp/234655/3 "2015-03-19T23:17:34Z")
On 19.03.2015 14:11, Henry J. wrote: > Hi Marcus, > > I later added a throttle and time scope to the tx end to see how large > the amplitude can be. Indeed, when the multiplier is 60m, the amplitude > increases beyond 1, which will be clipped by the USRP driver. Setting it > to be 0.45 seems like a safe choice. You might be able to push it a bit more. But definitely stay clear from 1. > For small amplitude cases such as when the multiplier is 20m, the SNR is > also low. The reason the OFDM receiver fails to receive many packets is > actually because the threshold used in digital.ofdm\_sync\_sc\_cfb() for > the plateau detector. Currently, the code leaves the threshold value to > be default, which is 0.9. In low SNR cases, in fact, we need to set it > smaller to tolerate noise. Originally, let’s say the synchronization > rate is only 1% or even lower, after this adjustment, it can be over > 90%. I suggest adding a parameter in ofdm\_txrx.py to adjust this parameter. Hm. S&C works fine for low SNRs, and changing the threshold is usually not required, due to normalization. I’d be hesitant to add that parameter, there might be another issue here. When you say low SNR, which regime are you talking about? Because the slicers (QPSK demapping) will usually fail before the detection. > Back to the high SNR cases, one issue puzzling me now is that when the > multiplier is 60m, although indeed there are samples exceeding the > amplitude limitation of 1, many other samples (in fact most of them) > have a small amplitude less than 0.5. This greatly limits the overall > SNR we can get. I wonder if there can be any improvements over this? This is a well-known OFDM issue. You can choose an encoding that will limit PAPR, use pilot tones that decrease PAPR… and many other PAPR-reducing techniques. This also depends on how many subcarriers you use. For random data, your PAPR usually stays within 2\*ln(N), which is usually not that bad. Cheers, M ---
**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 20, 2015, 12:11am UTC](https://www.ruby-forum.com/t/re-ofdm-test-with-usrp/234655/4 "2015-03-20T00:11:42Z")
Hi Martin, Thanks for the FOSDEM 14 video on youtube (although maybe not posted by you). Your talk is very informative and helpful. On Thursday, March 19, 2015, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > You might be able to push it a bit more. But definitely stay clear from 1. There is a typo here. The max multiplier I can set is 0.045. This value is based on the display on the time scope. The value ensures that every sample stays below the limit of 1. > > > > Hm. S&C works fine for low SNRs, and changing the threshold is usually not > required, due to normalization. I’d be hesitant to add that parameter, > there might be another issue here. When you say low SNR, which regime are > you talking about? Because the slicers (QPSK demapping) will usually fail > before the detection. Since there seems no available SNR estimators for OFDM yet in GNURadio, I implemented one myself. Although it seems to be not quite accurate, but it can serve as a reference. The low SNR I was talking about is around 13 dB. The observation that motivates me to modify the threshold is that the receiver can almost fully decode every packet it received (i.e., the PER is quite low, around 2%). However, I noted that in fact many packets are missing by observing the inconsistent packet\_number in the tag debug at the receiver end. Conservatively speaking, more than 80% missed. So I figure that maybe it is because the sync module fails to detect a peak. By adding some debug code, I am able to find the peak gap between each other is random and large, not constant and small (It should be the exact or nearly exact number of samples in the whole frame). So by lowering the threshold, now it seems to be working as expected as now many packets can indeed be received and decoded. To play safe, I only lower the threshold when needed. If the SNR is high, default value can still be used. > PAPR-reducing techniques. > This also depends on how many subcarriers you use. For random data, your > PAPR usually stays within 2\*ln(N), which is usually not that bad. I see. Currently, I’m using 48 data subcarriers out of 64 in total. > Cheers, > M > > * * * > > Discuss-gnuradio mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) Best, Henry