discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] OFDM test with USRP


From: Henry Jin
Subject: Re: [Discuss-gnuradio] OFDM test with USRP
Date: Thu, 19 Mar 2015 16:10:07 -0700

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 Braun <address@hidden> wrote:
On 19.03.2015 14:11, Henry Jin 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.
 
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. 
 

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.

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. 
 

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.

I see. Currently, I'm using 48 data subcarriers out of 64 in total.
 

Cheers,
M

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Best,
Henry 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]