discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Implementation of dynamic spectrum access


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Implementation of dynamic spectrum access
Date: Sun, 8 May 2011 15:23:27 +0100

On Sun, May 8, 2011 at 1:42 PM, Yang <address@hidden> wrote:
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):


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



 
On 2011年5月8日星期日 at 下午5:34, Tom Rondeau wrote:
On Sun, May 8, 2011 at 2:03 AM, yulong yang <address@hidden> 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


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


On Sat, May 7, 2011 at 8:55 PM, Tom Rondeau <address@hidden> wrote:
On Fri, May 6, 2011 at 4:34 PM, Yang <address@hidden> wrote:
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.
-- 
Yang
Sent with Sparrow


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


 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]