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

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

Reply via email to