> 2- Select the probability of detection you want, lets say 95% (0.95);
> 3- Sort the energies you calculated in 1 in ascending order;
> 4- You threshold will the value of the energy at the position
> N*(1-0.95), where N is the length of your sorted list in step 3.

and there you go, a receiver operation characteristic is born! :)

The interesting point is that in 1) you say that you calculate the
energy in a channel. That's not the same algorithm for all receivers --
for example, if you wanted to detect whether a DECT channel was used,
you might simply use the avg(mag²) of a channel bandwidth that you
extracted e.g. via a classical band pass filter , but you might also
chose to use matched filtering to actually try to maximize detection
SNR; which one you chose would depend on your objective (detection
whether there's *any* energy in the channel, or detection of how much
that energy would interfere with DECT). Another transceiver technology
might employ OFDM with a cyclic prefix and a constant frame length, and
detection of that might happen by finding the energy of the CP in a
periodogram at the known frame duration. Yet other systems might use a
static preamble to announce, time-synchronize and equalize the channel.
Detection thereof might be a very high-quality measure (as it's a known
signal you could correlate against), and be very useful for
understanding how much SNR the observed transceiver might actually be
seein, but totally useless for detecting other interferers in the same band.

Best regards,
Marcus

On 12.02.2016 17:34, Maicon Kist wrote:
> Hi Yan,
>
> about the detection probability I can give you some hints.
>
> When I implemented an energy detector in GNU Radio I did the following
> algorithm to obtain a good threshold value:
> 1- Calculate the energy of the channel when I know it was *occupied*
> over a period of time;
> 2- Select the probability of detection you want, lets say 95% (0.95);
> 3- Sort the energies you calculated in 1 in ascending order;
> 4- You threshold will the value of the energy at the position
> N*(1-0.95), where N is the length of your sorted list in step 3.
>
> Basically, you will set as threshold the 5-percentil (for 95% of
> detection probability) of the energies calculated when the channel is
> occupied.
>
> Best regards.
>
> On February 12, 2016 at 12:56:47, Marcus Müller
> ([email protected] <mailto:[email protected]>) wrote:
>
>> 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:* [email protected]
>>> [mailto:[email protected]]
>>> *On Behalf Of* Marcus Müller
>>> *Sent:* 12 February 2016 11:52
>>> *To:* [email protected]
>>> *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
>>>
>>>     [email protected] <mailto:[email protected]>
>>>
>>>     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
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> -- 
> Maicon Kist
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to