Hello All,
I am having some difficulties implementing a cognitive receiver program
that
involves dynamically reconfiguring the USRP between sensing the spectrum
and
acting as a receiver based on the results of the spectrum sensing. The
program I am developing is mostly based on the usrp_spectrum_sense.py
for
the sensing part and benchmark_rx.py for the receiving part. The
specifications for our platform are at the end of the e-mail.
The general logic of my program is to run one flow graph which is
connected
in the same way as in the usrp_spectrum_sense program. After obtaining
the
results from the spectrum sensing, I wish to reconfigure the flow graph
to
connect the USRP to receive and demodulate a user-defined number of
packets
just as in the benchmark_rx program whenever we deem the spectrum to be
free, after which we could revert to the configuration in the first flow
graph and continue until the program is terminated.
Here is some code of the most relevant parts of the program:
#################################################################
CODE :
class my_top_block():
def init(self, frame_count):
…
self.tb = gr.top_block()
self.u =
usrp.source_c(fusb_block_size=options.fusb_block_size,
fusb_nblocks=options.fusb_nblocks)
…
self.tb.connect(self.u, s2v, fft, c2mag, stats)
…
def set_freq(self, target_freq):
return self.u.tune(0, self.subdev, target_freq)
def set_next_freq(self):
target_freq = self.next_freq
min_center_freq = self.min_center_freq
max_center_freq = self.max_center_freq
power_norm = self.power_norm
frame_count = self.frame_count
if (target_freq == self.prev_freq + self.freq_step):
main_loop(self)
.....
if self.next_freq > self.max_center_freq:
self.next_freq = self.min_center_freq
self.prev_freq = self.min_center_freq - self.freq_step
self.finished_sensing = True
"""
Make a decision on reception mode or sleep mode based on the
value
of avg_frame_power
“”"
if target_freq == self.min_center_freq and self.finished_sensing
==
True:
print "The average power for previous frame %d :"
%frame_count,
self.avg_frame_power
frame_count += 1
self.finished_sensing = False
if (self.avg_frame_power > 50):
print "Sensing Mode : USRP in Sleep"
self.stats.sleep_mode(True,1000) # THIS IS OUR
MODIFICATION
WE USE IN gr_bin_statistics_f.cc
#
IN
PLACE OF USING time.sleep(); WE KNOW THIS WORKS
#
WITH NO PROBLEMS
else:
print "Receiver Mode : USRP to Switch to Receiving Packets
"
self.tb.stop()
self.tb.lock() # THIS IS
WHERE WE WANT TO RECONFIGURE TO RECEIVE
#
PACKETS
self.rx_path =
receive_path(self.tb,self.u,self.demodulator,self.options,self.samples_per_symbol,
self.decim,self.rx_subdev_spec,self.rx_freq,self.subdev)
self.tb.unlock() # THIS IS WHERE THE PROGRAM FREEZES
return target_freq
…
class receive_path(my_top_block):
def
init(self,tb,u,demodulator,options,samples_per_symbol,decim,rx_subdev_spec,rx_freq,subdev):
…
self.tb.connect(self.u,self.channel_filter, self.probe)
self.tb.connect(self.channel_filter, self._demodulator)
self.tb.connect(self._demodulator, self.correlator,
self.framer_sink)
#self._watcher = _queue_watcher_thread(self._rcvd_pktq,
rx_callback)
…
def main_loop(tb):
.... # THIS IS WHERE WE CALCULATE THE avg_frame_power AND PRINT
RESULTS
TO OUTPUT FILES
if name == ‘main’:
frame_count = 1
my_tb = my_top_block(frame_count) # start executing
flow
graph in another thread…
try:
my_tb.tb.run()
except KeyboardInterrupt:
pass
#################################################################
Since I have been unable to switch from the sensing path to the
receiving
path with no errors, I haven’t begun to deal
with switching back from the receiving path to the sensing path yet. I
know
that the program is freezing at the unlock() statement, since I have
debugged the program at execution time line-by-line using the standard
pdb
Python debugger.
From viewing the version 3.2.2 API
documentationhttp://gnuradio.org/doc/doxygen/index.htmlfor the
gr_top_block class, there is a note saying that “the lock() and
unlock() methods should not be called from a flowgraph thread or the
program
will be become deadlocked”. I was wondering if someone could clarify
what
exactly is meant by this statement. I take this to mean that the locking
and
unlocking cannot be performed from within that same instance of the
gr_top_block, or else the unlock() will continually wait for the already
executing thread to stop, which will never happen since this thread is
needed to be run to maintain the initial my_top_block instance. Is this
what
is meant by the documentation for the gr_top_block class? Also, can
anyone
recommend a general method to circumvent this problem if we are doing
things
the wrong way?
Thank you very much for your help.
Setup Specifications: GNU Radio version 3.2.2 running on Ubuntu 9.04,
USRP 1
with RFX2400 daughterboard
