[Discuss-gnuradio] Gnuradio website
gnuradio.org is showing a redmine internal error. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP, GNU Radio on Windows
Hi Jason, yes I tried running a script from command line and it says: ImportError: No module named gnuradio. I want to tell you that for installing the whole needed packages I used a python script gnuinstall.py and it went quite good. My first installation was with cygwin, but I couldn't install GNURadio. The biggest problem is that I couldn't found any tutorial that could explain the whole installation process (what paths has to be set, etc.). I'm really very surprised that there hasn't been made any Windows installation package, maybe I will make one but now I have to understand what's the problem with all these paths. Anyway thank you very much for any idea you and anybody may have regarding my problem. Best regards, Szalontai Levente. From: John Wilson johnmwilso...@gmail.com To: Florian Eugen florian_eu...@yahoo.com Cc: Jason Abele ja...@ettus.com; discuss-gnuradio@gnu.org Sent: Thu, August 5, 2010 2:21:06 PM Subject: Re: [Discuss-gnuradio] USRP, GNU Radio on Windows Hey, This may seem like a dumb suggestion but have you tried running the scripts from the command line to see why they're failing? Start with something simple like dial_tone.py (from the python/audio subfolder in gnuradio-examples). I've never used minGW, but I had no problems getting GNURadio installed and working with cygwin. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration
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
Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration
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 venkatvi...@gmail.com 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
Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration
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 venkatvi...@gmail.comwrote: 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 #
Re: [Discuss-gnuradio] Re: making a small USRP board
Will it support FDD full duplex? I'd like to run OpenBTS on a smaller USRP. -Lin 2010/8/28 William Cox wc...@ncsu.edu: Yes, same functions, just smaller and only one rx/tx pair. -William On Friday, August 27, 2010, Abdalaleem Andy James Potter ajpot...@youdinar.com wrote: Would it have the same functionality? On 27 Aug 2010, at 22:05, William Cox wrote: I'm interested in making a much smaller USRP1 board. Has anyone tried this? I was planning on stripping out the 2nd AD9862 and the power supply circuit. Is there anything I should watch out for? Thanks. -William ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio website
On Sun, Aug 29, 2010 at 10:47:22AM -0400, Philip Balister wrote: gnuradio.org is showing a redmine internal error. Philip Fixed with big hammer :-) Looks like the version of redmine we're using leaks memory and eventually (a couple of weeks?) consumes all memory and swap... Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration
On Sun, Aug 29, 2010 at 07:27:21PM -0500, Venkat Vinod 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 : else: print Receiver Mode : USRP to Switch to Receiving Packets self.tb.stop() Don't call stop. Just call lock. self.tb.lock() # THIS IS WHERE WE WANT TO RECONFIGURE TO RECEIVE # PACKETS ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] new version of kalibrate available, v0.4.1
Kalibrate is a program I wrote that scans GSM frequency bands and looks for base stations. It also caculates the offset between your local oscillator and a GSM base station's oscillator. (Kalibrate was originally just designed to calculate the oscillator offset. It's just convenient for kal to also search for GSM base stations.) I've released a bug-fix version, 0.4.1. This version contains the following fixes: (o) Support for Mac OS X (i.e., support for POSIX shared memory rather than just SysV shared memory) (o) Specifying the FPGA master clock frequency actually works now. (o) Some constants subtly depend on the sample rate. I've removed the decimation option and now calculate that automatically. I'd also like to thank Mark J. Blair for his help getting kal to work with Mac OS X. As usual, kal can be found here: http://thre.at/kalibrate ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 2rx and 2tx c++ example code
Hi All, I'm a newbie on GNU Radio. I have an USRP with 2 RFX900 Daughterboards, and use GNU Radio 3.2.2 Is there any c++ example code to generate 2Rx and 2Tx Frequencies ? Sorry for these beginner question. Thank you in advance. Regards, Harsha M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
