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 <[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
>
>
> Speaking of DySPAN, I will look into that. Really thanks.
> >
> >
> > On Sat, May 7, 2011 at 8:55 PM, Tom Rondeau <[email protected]> wrote:
> > > On Fri, May 6, 2011 at 4:34 PM, Yang <[email protected]> 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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
