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 On 2011年5月8日星期日 at 下午10:23, Tom Rondeau wrote: > On Sun, May 8, 2011 at 1:42 PM, Yang <yyl....@gmail.com> 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 <yyl....@gmail.com> 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 <trondeau1...@gmail.com> > > > > wrote: > > > > > On Fri, May 6, 2011 at 4:34 PM, Yang <yyl....@gmail.com> 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 > > > > > > > > > > > > > > > > > > > > > > > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
