Re: [Discuss-gnuradio] OFDM test with USRP

[Henry Jin]

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 <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] OFDM test with USRP
Message-ID: <address@hidden>
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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio