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 (address@hidden)
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
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
address@hidden
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|