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 On Thu, Mar 19, 2015 at 10:17 AM, Henry Jin <henry.ji...@gmail.com> wrote: > 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. > > > 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. > 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 <marcus.muel...@ettus.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] OFDM test with USRP > Message-ID: <550ac321.10...@ettus.com> > 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 Jin 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. > > > > > 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/8g3kg2tg6pdh0dy/grc_ofdm_tx.grc?dl=0 > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
