Quick Question.. Is there a reason you do not want to use time.sleep(). Just curious?
On Sun, Aug 29, 2010 at 8:27 PM, Venkat Vinod <[email protected]> wrote: > 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 > documentation<http://gnuradio.org/doc/doxygen/index.html>for 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 > > -- > Venkat Vinod Patcha & Ben Carroll > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
