[Discuss-gnuradio] Proposal method for Wi-Fi channel sensing with USRP2 (explanation and question)

[Juan Ramon Gutierrez Agullo]

Hi

I'm a Spanish Telecommunitacion Engineering student in his last year and
I'm doing my final degree project related to USRP2.One part of this
project is the measurement of the channel usage in the  Wi-Fi band
(2,4GHz and 5.2GHz).

I've built the next flow graph:

[USRP2 source (i.e. freq = 2.4G)]-->[Head]-->[FFT Filter]-->[Complex to
Mag^2]-->[Stream to vector] --> [TCP sink(client)]

The TCP server converts the message received from the USRP2 into a
float, using numpy library:

value_measured = numpy.fromstring (stream_received_from_usrp2,
numpy.float32)

Result:

I launch the flow graph and I wait unit it finishes.
The measured data is an array of float numbers. I work out the maximum
value and the average of all the floats and I use this values to decide
whether the channel is busy or not.

If I choose a really busy Wi-Fi channel (ie: channel 1, @ 2.412GHz), the
obtained results are (acording to the gaining, decimation,... values
I've chosen):

MAX Value = 434.435
Average = 1.4530

But, if I choose an empty Wi-Fi channel, the obtained results are:

MAX Value = 2.839
Average = 0.34955

I've repeated this many times and probably it's not a accurate way to
measure 'how busy is the channel' but I'm able to test if there are
Wi-Fi transmissions.

BUT, I've the following question/problem:

The TCP server (which receives the USRP2's measurements) doesn't receive
the same amount of data in consecutive measures. I mean, if I run the
graph, the number of samples that sends to the TCP server isn't always
the same. I thought that I could fix this value with the Head Block, but
obviously I'm wrong.

How could I fix the value of the measured data?

I've thought to do this without sockets, recording this values directly
from USRP2 to a "variable sink". I can get it with a graphical sink but
not with a non-graphical sink.

I hope someone can tell me if I'm wrong or not with this method, or I
should improve it.

Thank you for your time,

Juan Ramon Gutierrze