Hi Yan, > My original intention is to test whether there are signal transmission > in a certain spectrum band. So at first I want to use energy detection > and other methods to test which band has signal, and then compare the > probability of detection in different SNR. > Unless your FFT is sized so that it exactly represents one channel per FFT bin, the FFT is superfluous and won't do anything useful, then, because power is equivalent in time and frequency domain.
> I store the samples in /out.dat, cos I want to use the sample to > calculate the detection probability.(But now I don’t know how to get > detection probability, I wonder whether I can use the data to > calculate it.) I don't think that will help you. You need to think about how to estimate detection probability, and then record the data. Otherwise, you'll have data that you can't use.... Best regards, Marcus On 12.02.2016 15:51, Yan Huang wrote: > > Hi all, > > > > Thank you Marcus for your kind reply. > > > > My original intention is to test whether there are signal transmission > in a certain spectrum band. So at first I want to use energy detection > and other methods to test which band has signal, and then compare the > probability of detection in different SNR. > > > > I store the samples in /out.dat, cos I want to use the sample to > calculate the detection probability.(But now I don’t know how to get > detection probability, I wonder whether I can use the data to > calculate it.) > > > > Thanks, > > > > Yan > > > > > > *From:*discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org > [mailto:discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] *On > Behalf Of *Marcus Müller > *Sent:* 12 February 2016 11:52 > *To:* discuss-gnuradio@gnu.org > *Subject:* Re: [Discuss-gnuradio] The threshold of energy detection > > > > Hi Yan, > > > The threshold block converts your signal to 1 if you've been above the > "high" value, unless it has fallen below "low" again. Everywhere else, > it's 0. See the "documentation" tab in the block properties, or the > GNU Radio doxygen manual [1]. > > But: Parseval's theorem states that energy in frequency and in time > domain are directly proportional, so your > > stream to vector -> FFT->complex to mag²-> vector to stream>moving average > > can simply be replaced with a > > complex to mag²->moving average > > if detecting the average energy in your signal is all you want , which > seems probable, seeing that length(average)≈length(FFT). > > I'm not quite sure what your original intention was when storing > (FFT->mag²->average) samples in test_sensor/out.dat; the signal after > moving averaging is neither really frequency nor time domain. Out of > curiosity: what do you want with that data? > > There's very valid applications for frequency domain filters (a moving > average is actually but a low pass FIR filter, in principle), but the > convolution that filtering usually means is often replaced with a > multiplication in time domain, which is much less CPU-intense and > mathematically equivalent! > > Best regards, > Marcus > > [1] > https://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1threshold__ff.html#details > ¹ For new applications, I recommend Qt rather than WX -- the latter > isn't going to be around forever. > > On 12.02.2016 12:02, Yan Huang wrote: > > Hi all, > > > > I’m using USRP B210 to do spectrum sensing, and the flow graph as > attached file. It can get a result that there is a peak at 5.8 GHz > which is the receiving signal frequency. > > > > But if I change the Moving Average block to a threshold, there is > no output like previous one. > > > > I want to ask how can I get a result have a peak at 5.8 GHz in > frequency domain using threshold. I can only get 1 or 0 in time > domain not in frequency domain. > > > > Is there anyone can give me some advice? Thanks in advance. > > > > > > Yours Sincerely > > > > 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 <mailto:Discuss-gnuradio@gnu.org> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > 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
