discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic F


From: Kieran Brownlees
Subject: Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration
Date: Mon, 30 Aug 2010 14:07:05 +1200

Hi Venkat,

A couple of things to try:
Try removing the tb.stop() call, lock will stop the flowgraph anyway.
You may need to 'disconnect' (essentially undo all the connect calls) the path before recreating it. In the first instance try the disconnect_all() method, but from memory that had some issues so you could try calling disconnect for each block which was connected.

It has been awhile since I battled with the locking system of GNU Radio so I am a little rusty, hopefully it helps!

Kieran

On Mon, Aug 30, 2010 at 12:27 PM, Venkat Vinod <address@hidden> 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 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
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]