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 <martin.br...@ettus.com> 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Best, Henry
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
