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