Implementation of dynamic spectrum access

Hi all,

I am recently doing a project on gnu radio and usrp2. My goal is to
implement DSA: let Tx sense some bands, choose available one by energy
detection, then tune the usrp2 to this frequency and transmit a signal.

This might sound quite simple and basic for you, but I find it very hard
to get started. I have tried some ways:

  1. To write blocks for GRC:
    I have written a energy detection block find no way to realize the band
    switching function. Also, my energy detection block can only sense the
    signal USRP2 received from a fixed frequency (i.e. from usrp2_source
    block). How could I change the frequency during the detection? I cannot
    think of a way to make the one-way flow of GRC to do some feedback
    functions.

  2. To extend/modify usrp_spectrum_sense.py:
    I cannot figure out what is going on in gr_bin_statistic block (even
    with the detailed explanation from Firas): dose it just copy data from
    FFT and window block and save them in a .dat file? If it can generate
    the raw file, what is happening in the main_loop and m.data? Is m.data a
    file too?

Sorry for so much words but I feel I am totally lost in scripts. I am
still new to this and I cannot find a place to dive into and get work
done. I believe there should be some quite simple and straightforward
way to realize DSA. Would anyone point a way for me to go?

Any help would be appreciated. Thank you.

On Fri, May 6, 2011 at 4:34 PM, Yang [email protected] wrote:

I have written a energy detection block find no way to realize the band

Sorry for so much words but I feel I am totally lost in scripts. I am still
new to this and I cannot find a place to dive into and get work done. I
believe there should be some quite simple and straightforward way to realize
DSA. Would anyone point a way for me to go?

Any help would be appreciated. Thank you.

Yang
Sent with Sparrow http://www.sparrowmailapp.com

The IEEE DySPAN conference (which just finished) has had many demos and
papers about realizing DSA using GNU Radio. If you have access to the
IEEE
proceedings, you should find various references to people who have built
GNU
Radio programs for this purpose, at least as far back as the 2007
conference. You might find some useful ideas from any papers published
or
the websites of the demonstrators.

Having done some of this myself, I would say that you could have a
thread
operating in Python that is waiting for a message from a GNU Radio sink
block. The message would contain some information about the spectrum
usage
that you could then use to retune the USRP sink. So the retuning is done
in
the Python domain and not directly from a GR block.

A more complicated (but possibly more elegant) method would be to use
the
message passing interface. You would set it up so that a work function
would
make some decision on the free channel that would send a message to the
USRP
sink to change frequencies. The most difficult part of this is due to
our
lack of documentation and examples of using the messages.

Tom

Thanks for reply.
My plan is to extend the usrp_spectrum_sense.py: grab its output data
and
let a py script find the best available frequency in the data; then put
this
frequency into the usrp2_source block of file transmitter. In such
case, my
py script would contain two top_block and the second one, file
transmitter,
would run after the first one stops. Is this possible? When you say
threading, do you mean two top_block?

Speaking of DySPAN, I will look into that. Really thanks.

On Sun, May 8, 2011 at 2:03 AM, yulong yang [email protected] wrote:

Thanks for reply.
My plan is to extend the usrp_spectrum_sense.py: grab its output data and
let a py script find the best available frequency in the data; then put this
frequency into the usrp2_source block of file transmitter. In such case, my
py script would contain two top_block and the second one, file transmitter,
would run after the first one stops. Is this possible? When you say
threading, do you mean two top_block?

Not really. I was thinking about a separate Python thread function, much
like how we did the receiver code in benchmark_rx.py in the digital
example.

Tom

On Sun, May 8, 2011 at 1:42 PM, Yang [email protected] wrote:

Yang,
I was talking about benchmark_rx.py, not the transmitter. There is a
callback (sorry, not actually a thread) that sits and waits for a
message
from the demod chain called rx_callback. I’m suggesting that you use a
similar technique to send a message about the frequency information, and
then you could use the callback to set the frequency of the device.

I’m also not talking about a simple drop-in replacement for any code
that we
have. We have a lot of examples that will all do various pieces of what
you
want, and you are going to have to synthesize them to make your DSA
application.

Tom

How I understand of benchmark is that in the script it start the block,
wait for the packet to generate and then send it out. Do you mean this
“threading wait”? Is a block a thread?

So do you mean to import the spectrum_sense block in benchmark file and
make the transmitter wait when it dose its sensing?

Also, when I look at the code of benchmark_tx, it seems that it actually
get its block from the transmit_path.py, but I am still confused about
some places (with #comment):

tb.start()

nbytes = int(1e6 * options.megabytes)
n = 0
pktno = 0
pkt_size = int(options.size)

while n < nbytes:
if options.from_file is None:
data = (pkt_size - 2) * chr(pktno & 0xff)
else:
data = source_file.read(pkt_size - 2)
if data == ‘’:
break;

payload = struct.pack(’!H’, pktno & 0xffff) + data
send_pkt(payload) #in the definition of function send_pkt it has 2
parameters,but here only assigns one and the other is assigned later. Is
this anything special?
n += len(payload)
sys.stderr.write(’.’)
if options.discontinuous and pktno % 5 == 4:
time.sleep(1)
pktno += 1

send_pkt(eof=True)

tb.wait() # I assume it is waiting for the packet to generate, but why
it starts to wait after the packet is generated?


Yang
Sent with Sparrow

Dear Yang,

My master work is on this topic. I have a recent paper on this which as
below,

M. Adib Sarijari, Rozeha A. Rashid, N. Fisal, A. C. C. Lo, S. K. S.
Yusof,
N. H. Mahalin.
http://trg.fke.utm.my/members/adib/publications/WWRF%202011-2(2).pdf
Dynamic
Spectrum Access Using Cognitive Radio Utilizing GNU Radio and USRP .
WWRF
2011, Doha.

more on my work can be found in my website:
http://trg.fke.utm.my/members/adib/

Tom R. wrote:

I’m also not talking about a simple drop-in replacement for any code that
we
have. We have a lot of examples that will all do various pieces of what
you
want, and you are going to have to synthesize them to make your DSA
application.

Tom

Tom, its very interesting to see and learn your work on DSA. could you
forward this paper to us in the forum? i think the paper is not uploaded
yet. plus, its also great if I can try the code that you have done. is
it
open to be download, tested and learned?

we also have a work on parallel sensing and transmit which will
eliminate
the sensing time limitation and trade-off. we will published this in a
very
near time =) …

Adib


Mohd Adib Sarijari
Universiti Teknologi Malaysia
www.fke.utm.my
www.utm.my

View this message in context:
http://old.nabble.com/Implementation-of-dynamic-spectrum-access-tp31559416p31573367.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Mon, May 9, 2011 at 2:00 AM, adib_sairi [email protected] wrote:

we
forward this paper to us in the forum? i think the paper is not uploaded


Mohd Adib Sarijari
Universiti Teknologi Malaysia
www.fke.utm.my
www.utm.my

Adib,
No, I’m afraid I can’t help you there. This was from when I was working
on
my Ph.D. years ago at Virginia Tech and I no longer have access to the
code.
Any papers I have can be found in IEEE Xplore or from the SDR Forum (now
Wireless Innovation Forum). I was also mostly interested in the
development
of a cognitive engine that I applied to the DSA problem, not really DSA
itself.

Tom

Hey Adib, thanks for the information, I will look into your
publications.


Yang
Sent with Sparrow

Ah, I got it. I will look into that.

Btw, generally speaking, how is the efficiency the spectrum sensing in
gnu radio? I use the spectrum_sense.py to sense 9M a step and generate
256 bins which takes me nearly 1 second to sense 1M. It is really
slow…

Yang
Sent with Sparrow

Adib,
No, I’m afraid I can’t help you there. This was from when I was working
on
my Ph.D. years ago at Virginia Tech and I no longer have access to the
code.
Any papers I have can be found in IEEE Xplore or from the SDR Forum (now
Wireless Innovation Forum). I was also mostly interested in the
development
of a cognitive engine that I applied to the DSA problem, not really DSA
itself.

Tom

oh its too bad we cannot see the code. I follow some of your work on
cognitive engine when you are with VT during my literature of my master,
it
was a nice work your team done in VT with CR.

Last time there was a colleague in this forum introduce me to the CROSS
which done by VT (i also cite this in my thesis) …and inside the CROSS
there is a cognitive engine. is this your work? =)

thanks tom.

Adib


Mohd Adib Sarijari
Universiti Teknologi Malaysia

my website: http://trg.fke.utm.my/members/adib/
my faculty: http://www.fke.utm.my/
my university: http://www.utm.my/

View this message in context:
http://old.nabble.com/Implementation-of-dynamic-spectrum-access-tp31559416p31582189.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Tue, May 10, 2011 at 3:05 AM, adib_sairi [email protected]
wrote:

itself.
Last time there was a colleague in this forum introduce me to the CROSS
which done by VT (i also cite this in my thesis) …and inside the CROSS
there is a cognitive engine. is this your work? =)

thanks tom.

Adib

While CROSS isn’t my code, the general design of the cognitive engine is
very much like what I set up in my work and dissertation, so I’m
assuming
it’s largely based off it.

Tom

Yang-56 wrote:

Ah, I got it. I will look into that.

Btw, generally speaking, how is the efficiency the spectrum sensing in gnu
radio? I use the spectrum_sense.py to sense 9M a step and generate 256
bins which takes me nearly 1 second to sense 1M. It is really slow…

you can see why it is slow when you use spectum_sense.py by browsing in
this
forum. search for the spectrum sense discussion =)

in my case, i modify the code of fftsink_nongl.py (I cite it in my
thesis
and in my coming paper in korea) …the modification enable me to form an
energy detector spectrum sensor. and it is quite fast (in 0.xx ms).
actually
it can be faster if you use faster PC and optimized same part of the
code. I
am on my way to do this… we also currently working on parallel or
simultaneous spectrum sensing with data transmission. therefore, we will
eliminate the constrain on sensing time and all its tradeoff.

Wallahualam.

Adib


Mohd Adib Sarijari
Universiti Teknologi Malaysia

my website: http://trg.fke.utm.my/members/adib/
my faculty: http://www.fke.utm.my/
my university: http://www.utm.my/

View this message in context:
http://old.nabble.com/Implementation-of-dynamic-spectrum-access-tp31559416p31582151.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hello Adib,

CROSS was the product of Tim N. and myself, and was created a couple
of
years ago. Development stopped some time ago, and the documentation is
wildly out-of-date, but the code is still freely available:
http://www.cornet.wireless.vt.edu/trac/wiki/Cross

http://www.cornet.wireless.vt.edu/trac/wiki/CrossCROSS does provide a
skeleton cognitive engine, and a framework to wrap it in, but it does
not
provide a working cognitive engine out-of-the-box. The goal of the
project
was to develop something we could sit on top of any SDR platform -
GNURadio,
OSSIE, whatever, and establish a distributed waveform.

I’ve actually never looked at Tom’s work, so I can’t comment on the
similarities. It may be very similar. My understanding, and Tom can
correct me if I’m wrong, was that Tom’s dissertation focused mostly on
the
CE component itself. CROSS is algorithm and CE agnostic; it cares only
about how the components talk to each other.

Glad to hear you found it useful enough to cite, and I hope this helps!

Cheers,
Ben

Hi Adib,
I read your publications on gnuradio. What method did you use to sense
the spectrum? How could you achieve that sensing time, 0.xx ms? I
searched the forum for spectrum sense but find no explanation for slow
sensing.

Is there any other sensing methods applicable to gnuradio? The logic of
spectrum_sense.py seems to be perfect.

Cheers,


Yang
Sent with Sparrow

Hi Adib,
I read your publications on gnuradio. What method did you use to sense
the spectrum? How could you achieve that sensing time, 0.xx ms? I
searched the forum for spectrum sense but find no explanation for slow
sensing.

Is there any other sensing methods applicable to gnuradio? The logic of
spectrum_sense.py seems to be perfect.

Cheers,

Yang
Sent with Sparrow

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs