Hi Marcus, Thanks a lot, following your suggestion:
· I add a 512-FFT on the receiver side, but how can I only pick the first 200 subcarriers? I set the max output buffer of FFT as 200, but I don't think it works. How can I deal with it? · After FFT in receiver side, I connect the estimator to it, the output is unstable with some fluctuations. The picture 'SNR output' is the first 1024 output of estimator, how can I calculate the SNR? Many thanks, Yan From: Marcus Müller [mailto:marcus.muel...@ettus.com] Sent: 03 May 2016 13:10 To: Yan Huang; discuss-gnuradio@gnu.org Cc: Martin Braun Subject: Re: [Discuss-gnuradio] How to test and change SNR in GNURadio by B210 Dear Yan, If I want to change the SNR, can I add a Noise Source to the USRP Source to change it? Well, sure, but then you have two sources of noise: the noise inferred via reception of the signal with additive noise, and the added noise source power. It's a change, but it's pretty hard to quantify. You should really be starting with a simulation only! Don't add more unknowns to a system you need to estimate. But the problem is I don't know how to estimate the noise power of the receive signal. Well, that is the hard part, indeed. You could really just reverse the OFDM mapping by doing an FFT of appropriate size, but you'd infer errors: You don't have any timing or frequency recovery, and I really *don't know* how the existing estimators react to that. To be completely honest: reading the comments/documention of the estimators, it's clear that they were designed for the use case of PSK in time domain, and some were hand-tweaked to give good numbers in that case. I'd have to do quite some math to figure out how the different estimators would react to things like jitter or to ISI due to imperfect orthogonality, phase impairments due to overly high PAPR... You could really just reverse the 512-IFFT you do on the transmitter side, pick the 200 subcarriers that actually contain your 200 PSK signals, estimate the SNR in these, convert those SNR values back to a signal-only powers by means of observing the overall power per subcarrier, subtract that overall signal power from the overall input power to calculate noise power, and calculate overall SNR based on that. That ignores the effects mentioned in the previous paragraph, but would give you a rough number. It's worth mentioning that this includes the (512-200) unused subcarriers of your OFDM transmitter - but you said you want to apply Parseval, and hence, we'll have to roll with all the frequency and time domain. Frankly, you could as well just estimate the powers in the unoccupied FFT bins, postulate noise is white, extrapolate from that to the overall noise in all bins, and calculate SNR based on that. I think that's the obvious route here - but it seems you have already discarded that idea; why? If you need this for more than giving you a rough idea of how noisy the transmission is, you won't get around describing your exact assumptions about the PSK signal, and the statistical properties of your noise, after the OFDM de-mapping. I'm pretty sure there's quite some literature out there that already deals with SNR in OFDM systems. However, as explained in my previous mail, for all practical purposes, the raw sum-SNR is pretty irrelevant, probably. For example, have a look at the LTE standards - they have pretty complex methods, based on estimating a lot of known pilot symbols that are deliberately spread all over the time-frequency plane. Yes, that "wastes" spectrum just to obtain channel state information (not only noise power and signal attenuation, but also phase shift on the individual subcarriers), but since the receivers needs that CSI anyway to reliably decode the signal(s), the "transmission quality estimates" are pretty much a lucky by-product. Now, I'd like to recommend removing the "OFDM mod" block, which is outdated and really not recommended for usage in new designs, and using "OFDM Transmitter" instead. Refer to /usr/(local)/share/gnuradio/examples/digital/ofdm/ofdm_loopback.grc for usage of that. When you look at rx_ofdm.grc in that directory (which contains practically the insides of the "OFDM Receiver" block) , you'll notice the "OFDM Channel Estimation" and the "OFDM Frame Equalizer" blocks, as well as the "header_equalizer" variable. All these are backed by C++ classes in gr-digital, and I can only recommend reading the documentation, and in your case, since this seems to be your scientific focus, the source code of those - [1] should be your entry point; have a look at the documentation of gr::digital::ofdm_chanest_vcvc first. Reading Schmidl and Cox is probably an interesting thing to do, too! Especially the second half of that paper goes into detail about how they actually estimated and evaluated performance, which is a nice thing that imho more papers should do. The equalizer taps generated are of central importance here - you'll notice that their amplitude response should be inversely proportional to the frequency attenuation of the channel. That, together with observation of the output power of the equalizer used with these taps, in relation to the input power, would probably be an interesting starting point to acquire an SNR estimate. Sadly, I don't have cited Kammeyer at hand - and it's in German, so I guess your university's library won't have it around, so I can't look up the mentioned channel estimation noise reduction method. However, the code //TODO comment mentions it's really just using an FFT to get rid of the noise in bins that aren't relevant to the signal, anyway. It seems to be kind of a low-pass filter, if you want so. Martin, um, am I telling nonsense? Best regards, Marcus [1] http://gnuradio.org/doc/doxygen/group__ofdm__blk.html On 03.05.2016 12:24, Yan Huang wrote: Hi Marcus, Thank you for kind reply. Actually I want to calculate the sum-Signal to sum-Noise ratio, as you have referred Parseval to calculate it. · But the problem is I don't know how to estimate the noise power of the receive signal. · If I want to change the SNR, can I add a Noise Source to the USRP Source to change it? Many thanks, Yan From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of Marcus Müller Sent: 29 April 2016 19:20 To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] How to test and change SNR in GNURadio by B210 Dear Yan, 2.Can I use 'MPSK USRP Estimator' to test SNR to test SNR in this situation? OFDM containing BPSK symbols is not a PSK modulation in time domain; so you're using the wrong estimator as is. Therefore: 1.why the SNR I get is nearly 0(about 10^-3)? If I increase the noise amplitude, the SNR increase slightly(about 10^-1), I think it will decrease as noise increase. Because you're sending something that to the wrong receiver should look like wideband, not-quite-white noise. More energy from a white noise source seems to accidentally increase the SNR estimate. 3.How can I read the SNR information by using 'MPSK USRP Estimator prob'? Not at all, if you want to use OFDM. Generally, this is a very specific estimator for a very specific problem. In multi-carrier system, definining a single SNR is challenging theoretically - and questionable in effect, too. What's the bandwidth of your signal if you've got unoccupied carriers? What's the signal power? Do you look at noise and signal power for the whole system as one, or do you consider the individual carriers individually? If individually, is overall SNR the minimum subcarrier SNR, a sum-Signal to sum-Noise ratio (for OFDM, Parseval would make that simple), or is it maybe some non-linear combination that might make more sense when considering the overall system? And: What is the meaning of SNR here, and what do you intend to use it for? Wouldn't [$\frac{\text E_b}{N_0}$] make more sense? If it does, what is [$N_0$] in the constellation domain (ie. after reversing the OFDM modulation)? Of course, you can OFDM-demodulate (read: DFT) the receiver signal and put it through the MPSK SNR estimator; but that would mean that you'll have to do all the mathematical derivation of how that SNR relates to its input. Notice that if the noise your channel adds isn't really white for all DFT bins (it's probably not, because OFDM in practice isn't infinitely steep at the edges, and due to some effects the subcarriers might not be perfectly orthogonal, either, adding self-interference), you might end up with more noise in some subcarriers than others. BER-over-SNR curves tend to be nonlinear, so this might pose a problem for the interpretation of the SNR as tool to estimate the BER. I haven't actually measured that effect, and to be honest, I don't think it's going to be terrible. What's more important, however, is that you use OFDM exactly when your channel is non-flat; that's because dividing your overall bandwidth into smaller subchannels allows for easier per-subchannel equalization. Now, that means that the signal power will vary between different subcarriers in a situation where you'd prefer OFDM over single-carrier systems - and that makes it necessary to estimate the signal power per subcarrier, which means you will very likely have different SNRs for different subcarriers. Best regards, Marcus On 29.04.2016 19:02, Yan Huang wrote: Hi all, I'm using USRP B210 to employ spectrum sensing, I want to plot ROC curve of the sensing output signal. So I need to test and change the SNR of the receive signal. The attached picture is the flowgraph I use. I choose 'MPSK USRP Estimator' to test SNR since my tx signal is BPSK. The problem is: 1.why the SNR I get is nearly 0(about 10^-3)? If I increase the noise amplitude, the SNR increase slightly(about 10^-1), I think it will decrease as noise increase. 2.Can I use 'MPSK USRP Estimator' to test SNR to test SNR in this situation? 3.How can I read the SNR information by using 'MPSK USRP Estimator prob'? Many thanks in advance. Kind regards, Yan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
