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 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