Re: [Discuss-gnuradio] Re: debug freezing
peak detector can output 1 or 0. What is it outputting? feldmaus wrote: Josh Blum josh at joshknows.com writes: That says that throttling is not your issue. You are probably correct to think that the peak detect block stopped outputting samples. -Josh Is this because i did not configure the Peak-Detector correctly, or because it is a bug ? Regards Markus ___ 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] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi All, I've been trying to run some hardware tests between two USRP2s, but I have had no success in receiving packets. I am using the modified TX from Tiago. I feel sorta confident that the TX code works, because when I run the usrp2_fft.py, I see a wave form being transmitted over the channel. Has anyone have any success on receiving packets between two USRP2s? When RX/TX there is a usrp2::ctor reset db failed error. Could this cause problems for the RX/TX? I am using the firmware that was shipped with the USRP2. Thanks, Colby Boyer On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr wrote: Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File ./bbn_80211b_rx.py, line 179, in module main () File ./bbn_80211b_rx.py, line 174, in main app = app_flow_graph() File ./bbn_80211b_rx.py, line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File ./bbn_80211b_rx.py, line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py, line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs) TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 arguments (1 given) do you have any idea about the origin of this problem? Thank you in advance. On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote: / Updated from the trunk and I'm not getting that msg anymore./ / / / Everything seems to be ok now./ Glad to hear it! Thanks for letting us know. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi Colby! We have also tried without success. We have used the TX path from Tiago and a modified version of the RX path (firmware and FPGA at their latest update). I also felt confident that the the TX path works, and consequently that the RX path had some problem. So we have tried to transmit with the USRP2 and receive with a real IEEE802.11 chipset (Ralink chipset RT2500). This chipset has no firmware and we modified the linux driver so as to: - avoid mac CRC (Everything received on the MAC layer is passed to the higher layers); - set fixed modulation schemes (i.e. DBPSK 1Mbps); - set PLCP long preamble. - set complete monitor/passive mode. The chipset detects some transmitted frames. This could be an indication that the PLCP preamble/header is correct (?). However the PLCP payload is just rubbish. We have also tried to submit stupid payloads (like ) and I have the impression that what we receive is just random. :-( If we obtain some successful result in the next few days, I'll let you know! Best Regards, Danilo On Friday 17 April 2009 09:17:38 Colby Boyer wrote: Hi All, I've been trying to run some hardware tests between two USRP2s, but I have had no success in receiving packets. I am using the modified TX from Tiago. I feel sorta confident that the TX code works, because when I run the usrp2_fft.py, I see a wave form being transmitted over the channel. Has anyone have any success on receiving packets between two USRP2s? When RX/TX there is a usrp2::ctor reset db failed error. Could this cause problems for the RX/TX? I am using the firmware that was shipped with the USRP2. Thanks, Colby Boyer On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr wrote: Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File ./bbn_80211b_rx.py, line 179, in module main () File ./bbn_80211b_rx.py, line 174, in main app = app_flow_graph() File ./bbn_80211b_rx.py, line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File ./bbn_80211b_rx.py, line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py, line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs) TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 arguments (1 given) do you have any idea about the origin of this problem? Thank you in advance. On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote: / Updated from the trunk and I'm not getting that msg anymore./ / / / Everything seems to be ok now./ Glad to hear it! Thanks for letting us know. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: debug freezing
Josh Blum josh at joshknows.com writes: peak detector can output 1 or 0. What is it outputting? I get 1 and 0 when it is not freezed. I uploaded a screenshot, but i am not sure whether this works, http://img228.imageshack.us/my.php?image=peakdetected.jpg There you can see that i get 1 at a peak otherwise 0. The blue wave in the scope shows the peaks and the red wave is the signal i am searching peaks for. The signal is at 1020 kHz. Some frequencies results in a freezing of my graphical elements. Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP USRP2
Hi, I am new to USRP. Would like to know about where can we access PCB files or gerber files for USRP1 USRP2? Are we allowed to make modifications to the hardware as per the requirement changes...!! What are the licences applicable for hardware development. Pl advice. Thanks, Sudhir. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
That's good news. The code I sent seemed to be working but i realy didn't tested it. We have only one USRP2 here and we were trying to receive pkts using a 802.11b PCI card (Realtek RTL8180L chipset), but without success (some problems with the card configuration). 2009/4/17 Valerio, Danilo vale...@ftw.at Hi Colby! We have also tried without success. We have used the TX path from Tiago and a modified version of the RX path (firmware and FPGA at their latest update). I also felt confident that the the TX path works, and consequently that the RX path had some problem. So we have tried to transmit with the USRP2 and receive with a real IEEE802.11 chipset (Ralink chipset RT2500). This chipset has no firmware and we modified the linux driver so as to: - avoid mac CRC (Everything received on the MAC layer is passed to the higher layers); - set fixed modulation schemes (i.e. DBPSK 1Mbps); - set PLCP long preamble. - set complete monitor/passive mode. The chipset detects some transmitted frames. This could be an indication that the PLCP preamble/header is correct (?). However the PLCP payload is just rubbish. We have also tried to submit stupid payloads (like ) and I have the impression that what we receive is just random. :-( If we obtain some successful result in the next few days, I'll let you know! Best Regards, Danilo On Friday 17 April 2009 09:17:38 Colby Boyer wrote: Hi All, I've been trying to run some hardware tests between two USRP2s, but I have had no success in receiving packets. I am using the modified TX from Tiago. I feel sorta confident that the TX code works, because when I run the usrp2_fft.py, I see a wave form being transmitted over the channel. Has anyone have any success on receiving packets between two USRP2s? When RX/TX there is a usrp2::ctor reset db failed error. Could this cause problems for the RX/TX? I am using the firmware that was shipped with the USRP2. Thanks, Colby Boyer On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr wrote: Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File ./bbn_80211b_rx.py, line 179, in module main () File ./bbn_80211b_rx.py, line 174, in main app = app_flow_graph() File ./bbn_80211b_rx.py, line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File ./bbn_80211b_rx.py, line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py, line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs) TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 arguments (1 given) do you have any idea about the origin of this problem? Thank you in advance. On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote: / Updated from the trunk and I'm not getting that msg anymore./ / / / Everything seems to be ok now./ Glad to hear it! Thanks for letting us know. Eric ___ 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] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
I'm trying to modify the bbn_80211b_rx.py code inorder to receive packets but in every step I'm facing an AttributeError like: AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'make_format' AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'set_format' AttributeError: 'module' object has no attribute 'set_gain' AttributeError: 'gr_hier_block2_sptr' object has no attribute 'subdev' It seems that the code has not been switched correctly to work with usrp2 and still make reference to usrp classes. Did you try to run the bbn_80211b_rx.py with the usrp2 that you have? Tiago Rogério Mück wrote: That's good news. The code I sent seemed to be working but i realy didn't tested it. We have only one USRP2 here and we were trying to receive pkts using a 802.11b PCI card (Realtek RTL8180L chipset), but without success (some problems with the card configuration). 2009/4/17 Valerio, Danilo vale...@ftw.at mailto:vale...@ftw.at Hi Colby! We have also tried without success. We have used the TX path from Tiago and a modified version of the RX path (firmware and FPGA at their latest update). I also felt confident that the the TX path works, and consequently that the RX path had some problem. So we have tried to transmit with the USRP2 and receive with a real IEEE802.11 chipset (Ralink chipset RT2500). This chipset has no firmware and we modified the linux driver so as to: - avoid mac CRC (Everything received on the MAC layer is passed to the higher layers); - set fixed modulation schemes (i.e. DBPSK 1Mbps); - set PLCP long preamble. - set complete monitor/passive mode. The chipset detects some transmitted frames. This could be an indication that the PLCP preamble/header is correct (?). However the PLCP payload is just rubbish. We have also tried to submit stupid payloads (like ) and I have the impression that what we receive is just random. :-( If we obtain some successful result in the next few days, I'll let you know! Best Regards, Danilo On Friday 17 April 2009 09:17:38 Colby Boyer wrote: Hi All, I've been trying to run some hardware tests between two USRP2s, but I have had no success in receiving packets. I am using the modified TX from Tiago. I feel sorta confident that the TX code works, because when I run the usrp2_fft.py, I see a wave form being transmitted over the channel. Has anyone have any success on receiving packets between two USRP2s? When RX/TX there is a usrp2::ctor reset db failed error. Could this cause problems for the RX/TX? I am using the firmware that was shipped with the USRP2. Thanks, Colby Boyer On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr wrote: Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File ./bbn_80211b_rx.py, line 179, in module main () File ./bbn_80211b_rx.py, line 174, in main app = app_flow_graph() File ./bbn_80211b_rx.py, line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File ./bbn_80211b_rx.py, line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py, line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs) TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 arguments (1 given) do you have any idea about the origin of this problem? Thank you in advance. On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote: / Updated from the trunk and I'm not getting that msg anymore./ / / / Everything seems to be ok now./ Glad to hear it! Thanks for letting us know. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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
Re: [Discuss-gnuradio] Re: debug freezing
feldmaus wrote: Josh Blum josh at joshknows.com writes: peak detector can output 1 or 0. What is it outputting? I get 1 and 0 when it is not freezed. I uploaded a screenshot, but i am not sure whether this works, http://img228.imageshack.us/my.php?image=peakdetected.jpg There you can see that i get 1 at a peak otherwise 0. The blue wave in the scope shows the peaks and the red wave is the signal i am searching peaks for. The signal is at 1020 kHz. Some frequencies results in a freezing of my graphical elements. Do you think that it might be possible for peak detector to output always the same number at some frequencies? Replace the peak detector with a source of constant 0 or a source of constant 1, do the plots appear frozen? It seems that if you give the graphical sinks a signal that never changes, the plotted waveforms will also not change. Further, if your scope is triggering on channel 1 (the blue) and blue is constant, the scope cannot find a trigger point, and stop plotting new samples until a trigger point is found. -josh Regards Markus ___ 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] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi Ben, I uploaded my files to the usrp2_version in the CGRAN server. It uses the same files I used to run my USRP2 tests, so it should interface with the hardware correctly. Let me know if it does not. Bests, Colby On Fri, Apr 17, 2009 at 10:15 AM, Colby Boyer colby.bo...@gmail.com wrote: Hi Ben, Perhaps I haven't updated the CGRAN repo yet. I'll take a look and try to get back to you within an hour. Colby 2009/4/17 Ben Yahmed maher.ben_yah...@sophia.inria.fr I'm trying to modify the bbn_80211b_rx.py code inorder to receive packets but in every step I'm facing an AttributeError like: AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'make_format' AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'set_format' AttributeError: 'module' object has no attribute 'set_gain' AttributeError: 'gr_hier_block2_sptr' object has no attribute 'subdev' It seems that the code has not been switched correctly to work with usrp2 and still make reference to usrp classes. Did you try to run the bbn_80211b_rx.py with the usrp2 that you have? Tiago Rogério Mück wrote: That's good news. The code I sent seemed to be working but i realy didn't tested it. We have only one USRP2 here and we were trying to receive pkts using a 802.11b PCI card (Realtek RTL8180L chipset), but without success (some problems with the card configuration). 2009/4/17 Valerio, Danilo vale...@ftw.at mailto:vale...@ftw.at Hi Colby! We have also tried without success. We have used the TX path from Tiago and a modified version of the RX path (firmware and FPGA at their latest update). I also felt confident that the the TX path works, and consequently that the RX path had some problem. So we have tried to transmit with the USRP2 and receive with a real IEEE802.11 chipset (Ralink chipset RT2500). This chipset has no firmware and we modified the linux driver so as to: - avoid mac CRC (Everything received on the MAC layer is passed to the higher layers); - set fixed modulation schemes (i.e. DBPSK 1Mbps); - set PLCP long preamble. - set complete monitor/passive mode. The chipset detects some transmitted frames. This could be an indication that the PLCP preamble/header is correct (?). However the PLCP payload is just rubbish. We have also tried to submit stupid payloads (like ) and I have the impression that what we receive is just random. :-( If we obtain some successful result in the next few days, I'll let you know! Best Regards, Danilo On Friday 17 April 2009 09:17:38 Colby Boyer wrote: Hi All, I've been trying to run some hardware tests between two USRP2s, but I have had no success in receiving packets. I am using the modified TX from Tiago. I feel sorta confident that the TX code works, because when I run the usrp2_fft.py, I see a wave form being transmitted over the channel. Has anyone have any success on receiving packets between two USRP2s? When RX/TX there is a usrp2::ctor reset db failed error. Could this cause problems for the RX/TX? I am using the firmware that was shipped with the USRP2. Thanks, Colby Boyer On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr wrote: Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File ./bbn_80211b_rx.py, line 179, in module main () File ./bbn_80211b_rx.py, line 174, in main app = app_flow_graph() File ./bbn_80211b_rx.py, line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File ./bbn_80211b_rx.py, line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py, line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs) TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 arguments (1 given) do you have any idea about the origin of this problem? Thank you in advance. On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote: / Updated from the trunk and I'm not getting that msg anymore./ / / / Everything seems to be ok now./ Glad to hear it! Thanks for letting us know. Eric ___ Discuss-gnuradio mailing list
Re: [Discuss-gnuradio] USRP2 benchmark_rx.py, benchmark_tx.py, transmit_path_usrp2.py, receive_path_usrp2.py, pick_bitrate.py
Hi, This is what I get when I run benchmark _tx.py and benchmark_rx.py respectively on USRP2 with transmit_path_usrp2.py and receive_path_usrp2.py respectively: benchmark_tx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_tx.py -f 2400M -v usrp2::ctor reset_db failed usrp2::ctor set_rx_gain failed usrp2::ctor set_tx_interp failed usrp2::ctor set_rx_scale_iq failed gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board 43 Tx amplitude 12000 modulation: gmsk_mod bitrate: 500kb/s samples/symbol:2 interp: 100 Tx Frequency:2.4G ...m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ benchmark_rx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_rx.py -f 2400M -v usrp2::ctor reset_db failed gr_fir_fff: using SSE bits per symbol = 1 MM clock recovery omega = 2.00 MM clock recovery gain mu = 0.175000 MM clock recovery mu = 0.50 MM clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board 39 Rx gain: 35 modulation: gmsk_demod bitrate: 500kb/s samples/symbol:2 decim: 100 Rx Frequency:2.4G Now the same thing for usrp1 but using transmit_path.py and receive_path.py which is already provided in gnuradio: benchmark_tx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_tx.py -f 2400M -v gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board A: Flex 2400 Tx MIMO B Tx amplitude 12000 modulation: gmsk_mod bitrate: 500kb/s samples/symbol:2 interp: 128 Tx Frequency:2.4G ...m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ benchmark_rx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_rx.py -f 2400M -v gr_fir_fff: using SSE bits per symbol = 1 MM clock recovery omega = 2.00 MM clock recovery gain mu = 0.175000 MM clock recovery mu = 0.50 MM clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board A: Flex 2400 Rx MIMO B Rx gain: 45 modulation: gmsk_demod bitrate: 500kb/s samples/symbol:2 decim:64 Rx Frequency:2.4G I am using the same pick_bitrate.py file that is already provided in gnuradio. As it can be seen that both usrp systems have the default bit rate irrespective of whether it acts as receiver or transmitter. My concern is with the interpolation and decimation. Do I need to make changes to the pick_bitrate.py file for USRP2? If yes, then what kind of changes. I also observed that even though USRP2 shows a bit rate of 500kbps, however I believe that its transmitting too fast which does not allow USRP1 to receive correctly.I would greatly appreciate any help in this matter. Thanks in advance. Smith Eric Blossom wrote: On Tue, Apr 14, 2009 at 01:48:21PM -0700, Smith L. wrote: Hi, I am trying to establish communication between USRP2 and USRP1. I am using RFX2400 daughterboard. I am using Ubuntu 8.10. I am using the svn version of GNU Radio. I dont know the revision number. I am not able to receive anything on USRP2 when USRP1 is transmitting and vice versa. The python codes for USRP2 work perfectly fine. I guess there is some problem with the ADC and DAC incompatibility (interpolation and decimation) between USRP2 and USRP1. I am attaching all the necessary files that I am using currently. I would appreciate if someone can look at these files and help me to sort out the problem. My guess is that the two
Re: [Discuss-gnuradio] USRP2 benchmark_rx.py, benchmark_tx.py, transmit_path_usrp2.py, receive_path_usrp2.py, pick_bitrate.py
On Fri, Apr 17, 2009 at 11:24:00AM -0700, Smith L. wrote: I am using the same pick_bitrate.py file that is already provided in gnuradio. As it can be seen that both usrp systems have the default bit rate irrespective of whether it acts as receiver or transmitter. My concern is with the interpolation and decimation. Do I need to make changes to the pick_bitrate.py file for USRP2? If yes, then what kind of changes. I also observed that even though USRP2 shows a bit rate of 500kbps, however I believe that its transmitting too fast which does not allow USRP1 to receive correctly.I would greatly appreciate any help in this matter. At a minimum, you will need to call pick_tx_bitrate and pick_rx_bitrate providing proper rates for the ADC and DAC. They default to the values appropriate for the USRP1. However, it looks like you'll need a USRP2 version since they encode the acceptable ranges for interpolation and decimation which are different between the USRP1 and USRP2. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP USRP2
On Fri, Apr 17, 2009 at 02:18:20PM +0530, Chitla S wrote: Hi, I am new to USRP. Would like to know about where can we access PCB files or gerber files for USRP1 USRP2? Are we allowed to make modifications to the hardware as per the requirement changes...!! What are the licences applicable for hardware development. Pl advice. Thanks, Sudhir. The schematics are available, the PCB files and gerbers are not. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi All, So I ran a sanity test on the TX and RX functions. In the tx.py file, I added a file sink to record the data being sent to the USRP2. In the rx.py file I added a file source to read that data, rather than reading samples from the USRP2. When I did this, it was able to successfully demodulate the packets from reading the sample data from a file. So TX is working(?) unless something is going wrong with initializing/sending stuff to the hardware. So perhaps the rx is not correctly reading samples in from the USRP2? Thoughts? Colby On Fri, Apr 17, 2009 at 10:53 AM, Colby Boyer csbo...@berkeley.edu wrote: Hi Ben, I uploaded my files to the usrp2_version in the CGRAN server. It uses the same files I used to run my USRP2 tests, so it should interface with the hardware correctly. Let me know if it does not. Bests, Colby On Fri, Apr 17, 2009 at 10:15 AM, Colby Boyer colby.bo...@gmail.comwrote: Hi Ben, Perhaps I haven't updated the CGRAN repo yet. I'll take a look and try to get back to you within an hour. Colby 2009/4/17 Ben Yahmed maher.ben_yah...@sophia.inria.fr I'm trying to modify the bbn_80211b_rx.py code inorder to receive packets but in every step I'm facing an AttributeError like: AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'make_format' AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'set_format' AttributeError: 'module' object has no attribute 'set_gain' AttributeError: 'gr_hier_block2_sptr' object has no attribute 'subdev' It seems that the code has not been switched correctly to work with usrp2 and still make reference to usrp classes. Did you try to run the bbn_80211b_rx.py with the usrp2 that you have? Tiago Rogério Mück wrote: That's good news. The code I sent seemed to be working but i realy didn't tested it. We have only one USRP2 here and we were trying to receive pkts using a 802.11b PCI card (Realtek RTL8180L chipset), but without success (some problems with the card configuration). 2009/4/17 Valerio, Danilo vale...@ftw.at mailto:vale...@ftw.at Hi Colby! We have also tried without success. We have used the TX path from Tiago and a modified version of the RX path (firmware and FPGA at their latest update). I also felt confident that the the TX path works, and consequently that the RX path had some problem. So we have tried to transmit with the USRP2 and receive with a real IEEE802.11 chipset (Ralink chipset RT2500). This chipset has no firmware and we modified the linux driver so as to: - avoid mac CRC (Everything received on the MAC layer is passed to the higher layers); - set fixed modulation schemes (i.e. DBPSK 1Mbps); - set PLCP long preamble. - set complete monitor/passive mode. The chipset detects some transmitted frames. This could be an indication that the PLCP preamble/header is correct (?). However the PLCP payload is just rubbish. We have also tried to submit stupid payloads (like ) and I have the impression that what we receive is just random. :-( If we obtain some successful result in the next few days, I'll let you know! Best Regards, Danilo On Friday 17 April 2009 09:17:38 Colby Boyer wrote: Hi All, I've been trying to run some hardware tests between two USRP2s, but I have had no success in receiving packets. I am using the modified TX from Tiago. I feel sorta confident that the TX code works, because when I run the usrp2_fft.py, I see a wave form being transmitted over the channel. Has anyone have any success on receiving packets between two USRP2s? When RX/TX there is a usrp2::ctor reset db failed error. Could this cause problems for the RX/TX? I am using the firmware that was shipped with the USRP2. Thanks, Colby Boyer On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr wrote: Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File ./bbn_80211b_rx.py, line 179, in module main () File ./bbn_80211b_rx.py, line 174, in main app = app_flow_graph() File ./bbn_80211b_rx.py, line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File ./bbn_80211b_rx.py, line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py, line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs)
Re: [Discuss-gnuradio] USRP2 benchmark_rx.py, benchmark_tx.py, transmit_path_usrp2.py, receive_path_usrp2.py, pick_bitrate.py
Hi, I already tried to set the value of the converter_rate in pick_tx_bitrate and Pick_rx_bitrate according to the ADC and DAC specifications of u...@. I set it to 200e6 in pick_tx_bitrate and in pick_rx_bitrate. But even that did not worked. I am confused with how to modify the pick_bitrate.py file for usrp2. I am not able to determine the different parameters that I need to provide for usrp2. If anyone has already worked on it then please help me to modify the pick_bitrate file for usrp2. Also if any other changes are required in other python files. Thanks in advance. Smith Eric Blossom wrote: On Fri, Apr 17, 2009 at 11:24:00AM -0700, Smith L. wrote: I am using the same pick_bitrate.py file that is already provided in gnuradio. As it can be seen that both usrp systems have the default bit rate irrespective of whether it acts as receiver or transmitter. My concern is with the interpolation and decimation. Do I need to make changes to the pick_bitrate.py file for USRP2? If yes, then what kind of changes. I also observed that even though USRP2 shows a bit rate of 500kbps, however I believe that its transmitting too fast which does not allow USRP1 to receive correctly.I would greatly appreciate any help in this matter. At a minimum, you will need to call pick_tx_bitrate and pick_rx_bitrate providing proper rates for the ADC and DAC. They default to the values appropriate for the USRP1. However, it looks like you'll need a USRP2 version since they encode the acceptable ranges for interpolation and decimation which are different between the USRP1 and USRP2. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/USRP2-benchmark_rx.py%2C-benchmark_tx.py%2C-transmit_path_usrp2.py%2C-receive_path_usrp2.py%2C-pick_bitrate.py-tp23047724p23106148.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 benchmark_rx.py, benchmark_tx.py, transmit_path_usrp2.py, receive_path_usrp2.py, pick_bitrate.py
On Fri, Apr 17, 2009 at 02:24:44PM -0700, Smith L. wrote: Hi, I already tried to set the value of the converter_rate in pick_tx_bitrate and Pick_rx_bitrate according to the ADC and DAC specifications of u...@. I set it to 200e6 in pick_tx_bitrate and in pick_rx_bitrate. But even that did not worked. I am confused with how to modify the pick_bitrate.py file for usrp2. I am not able to determine the different parameters that I need to provide for usrp2. If anyone has already worked on it then please help me to modify the pick_bitrate file for usrp2. Also if any other changes are required in other python files. Thanks in advance. Smith The converter rates should both be 100e6. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Transmission
Hi all, Did any body else had a problem while transmitting through USRP board? I am using Basic Tx/Rx board. When I tried to send a sinusoidal signal of 50Khz (through GRC) and tried to look at at the transmitted signal on to the oscilloscope by probing the Tx SMA connector, it displayed a sinusoid of 25Mhz with a constant DC offset. I guess there is an up conversion to an IF frequency is been done in USRP, but do anybody know is there any fixed frequency the signal is up converted to? At what mamimum power can a signal be transmitted using USRP?Is there a way we can control Transmission Power? Also when I unplugged the power to USRP and the USB cable, then also I was able to see a sinusoid, on the scope, of 60Mhz. Is there anything we need to enable in order to make the transmitter work? Also is there any kind of reference manual available for the Basic TX/Rx Daughter board? Thanks Regards, Somya Ajmera New Email names for you! Get the Email name you#39;ve always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Re: gr-howto-write-a-block
George Nychis wrote: On Fri, Apr 17, 2009 at 1:09 AM, William Sherman li...@ruby-forum.comwrote: Do I need to building gr-howto-write-a-block-3.1.3 from inside the gnuradio directory instead of just some random directory where it is currently located? The point of the standalone (random) tree is so that it doesn't need to be inside the GNU Radio tree to work ;) Did you do a sudo make install also? - George I did a make install at the end. I do not have sudo privileges. Is sudo necessary? The full sequence I am executing is, automake env LDFLAGS=-L/usr/pkg/lib -R/usr/pkg/lib CPPFLAGS=-I/usr/pkg/include ./configure --prefix=/u/students/renyu/Masters/ren_static/installdir make make install make install creates a lib and include folder in installdir with howtoren.pyo, pyc, py, so la (my new block is a howtoren module with the one block bin_statistics_mean_f. I read on the howto write your own block tutorial that you need to get python to see where your new module is: The build tree is everything from topdir (the one containing configure.ac) down. The path to the install tree is prefix/lib/pythonversion/site-packages, where prefix is the --prefix argument to configure (default /usr/local) and version is the installed version of python. A typical value is /usr/local/lib/python2.3/site-packages. We normally set our PYTHONPATH environment variable to point at the install tree, and do this in ~/.bash_profile or ~/.profile. This allows our python apps to access all the standard python libraries, plus our locally installed stuff like GNU Radio. I created ~/.bash_profile and ~/.profile, with contents: setenv PYTHONPATH /u/students/renyu/Masters/ren_static/installdir/lib/python2.5/site-packages/ However I still can't from gnuradio import howtoren. Any advice? This is my howtoren.py for verification: # This file was automatically generated by SWIG (http://www.swig.org). # Version 1.3.31 # # Don't modify this file, modify the SWIG interface instead. import _howtoren import new new_instancemethod = new.instancemethod try: _swig_property = property except NameError: pass # Python 2.2 doesn't have 'property'. def _swig_setattr_nondynamic(self,class_type,name,value,static=1): if (name == thisown): return self.this.own(value) if (name == this): if type(value).__name__ == 'PySwigObject': self.__dict__[name] = value return method = class_type.__swig_setmethods__.get(name,None) if method: return method(self,value) if (not static) or hasattr(self,name): self.__dict__[name] = value else: raise AttributeError(You cannot add attributes to %s % self) def _swig_setattr(self,class_type,name,value): return _swig_setattr_nondynamic(self,class_type,name,value,0) def _swig_getattr(self,class_type,name): if (name == thisown): return self.this.own() method = class_type.__swig_getmethods__.get(name,None) if method: return method(self) raise AttributeError,name def _swig_repr(self): try: strthis = proxy of + self.this.__repr__() except: strthis = return %s.%s; %s % (self.__class__.__module__, self.__class__.__name__, strthis,) import types try: _object = types.ObjectType _newclass = 1 except AttributeError: class _object : pass _newclass = 0 del types def _swig_setattr_nondynamic_method(set): def set_attr(self,name,value): if (name == thisown): return self.this.own(value) if hasattr(self,name) or (name == this): set(self,name,value) else: raise AttributeError(You cannot add attributes to %s % self) return set_attr class howtoren_bin_statistics_mean_f_sptr(object): Proxy of C++ howtoren_bin_statistics_mean_f_sptr class thisown = _swig_property(lambda x: x.this.own(), lambda x, v: x.this.own(v), doc='The membership flag') __repr__ = _swig_repr def __init__(self, *args): __init__(self) - howtoren_bin_statistics_mean_f_sptr __init__(self, p) - howtoren_bin_statistics_mean_f_sptr this = _howtoren.new_howtoren_bin_statistics_mean_f_sptr(*args) try: self.this.append(this) except: self.this = this def __deref__(*args): __deref__(self) return _howtoren.howtoren_bin_statistics_mean_f_sptr___deref__(*args) __swig_destroy__ = _howtoren.delete_howtoren_bin_statistics_mean_f_sptr __del__ = lambda self : None; def history(*args): history(self) - unsigned int return _howtoren.howtoren_bin_statistics_mean_f_sptr_history(*args) def output_multiple(*args): output_multiple(self) - int return _howtoren.howtoren_bin_statistics_mean_f_sptr_output_multiple(*args) def relative_rate(*args): relative_rate(self) - double return _howtoren.howtoren_bin_statistics_mean_f_sptr_relative_rate(*args) def start(*args): start(self) - bool return
Re: [Discuss-gnuradio] GNU Radio 3.2 Release Candidate 2 available for testing
On Tue, Apr 14, 2009 at 3:23 PM, Johnathan Corgan jcor...@corganenterprises.com wrote: GNU Radio 3.2 release candidate 2 is now available for download and testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.2rc2.tar.gz The associated firmware and FPGA bitstream images for the USRP2 are: http://gnuradio.org/releases/usrp2-bin/release/txrx_edk10.1_r3.2rc2.bin http://gnuradio.org/releases/usrp2-bin/release/u2_rev3_ise10.1sp3_r3.2rc2.bin This release contains all the features, fixes, and bugs of the GNU Radio development trunk as of 4/14/09. Our goal is for this to be the last release candidate before the formal 3.2 release. Those of you with your own GNU Radio projects who wish to stabilize on the 3.2.x API should begin using the above instead of the development trunk. We will be making changes to the trunk software that will break API compatibility soon after the formal release. As always, we will maintain the 3.2.x series of releases such that upgrades to newer releases will not break existing code. In addition, to the extent possible, we will merge and release selected functionality from the development trunk that is consistent with this requirement. Johnathan Corgan Corgan Enterprises LLC Here is my setup: OS: Ubuntu 8.04 USRP1 with 2 LFRX and 2LFTX daughterboards I primary use the USRP as a 4 channel Digitizer and have been running gnuradio-3.1.3 without any problems so far. To test 3.2rc2 I tried running the multi_fft.py which is available in the gnuradio-examples/python/multi-antenna/ directory. I commented out the portion which checks for the the number of channels available and the daughterboard ID since I didn't have the BASIC_RX. Here is the major change that I found. The value of len(self.subdev) = 4 in 3.1.3 and =6 in 3.2rc2. Shouldn't this be 4 as it was previously? Regards, Karthik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.2 Release Candidate 2 available for testing
On Fri, Apr 17, 2009 at 7:04 PM, Karthik karthik1...@gmail.com wrote: The value of len(self.subdev) = 4 in 3.1.3 and =6 in 3.2rc2. Shouldn't this be 4 as it was previously? It appears this was an inadvertent consequence of the change in the daughterboard code for the BasicRX and LFRX boards, to allow use as a complex input device. These daughterboards now have three subdevs instead of two, so when the above variable is created by concatenating the daughterboard table from each side, it comes out as six instead of four. I can't test it right now, but I think it is as simple as changing the comparison to use 6 instead of 4. Thanks for the bug report. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.2 Release Candidate 2 available for testing
On Fri, Apr 17, 2009 at 07:04:25PM -0700, Karthik wrote: On Tue, Apr 14, 2009 at 3:23 PM, Johnathan Corgan jcor...@corganenterprises.com wrote: GNU Radio 3.2 release candidate 2 is now available for download and testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.2rc2.tar.gz The associated firmware and FPGA bitstream images for the USRP2 are: http://gnuradio.org/releases/usrp2-bin/release/txrx_edk10.1_r3.2rc2.bin http://gnuradio.org/releases/usrp2-bin/release/u2_rev3_ise10.1sp3_r3.2rc2.bin This release contains all the features, fixes, and bugs of the GNU Radio development trunk as of 4/14/09. Our goal is for this to be the last release candidate before the formal 3.2 release. Those of you with your own GNU Radio projects who wish to stabilize on the 3.2.x API should begin using the above instead of the development trunk. We will be making changes to the trunk software that will break API compatibility soon after the formal release. As always, we will maintain the 3.2.x series of releases such that upgrades to newer releases will not break existing code. In addition, to the extent possible, we will merge and release selected functionality from the development trunk that is consistent with this requirement. Johnathan Corgan Corgan Enterprises LLC Here is my setup: OS: Ubuntu 8.04 USRP1 with 2 LFRX and 2LFTX daughterboards I primary use the USRP as a 4 channel Digitizer and have been running gnuradio-3.1.3 without any problems so far. To test 3.2rc2 I tried running the multi_fft.py which is available in the gnuradio-examples/python/multi-antenna/ directory. I commented out the portion which checks for the the number of channels available and the daughterboard ID since I didn't have the BASIC_RX. Here is the major change that I found. The value of len(self.subdev) = 4 in 3.1.3 and =6 in 3.2rc2. Shouldn't this be 4 as it was previously? Thanks for pointing this out. Fixed in [10877] to work with old and new handling of Basic Rx d'boards. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Transmission
On Fri, Apr 17, 2009 at 03:58:56PM -0700, Somya Ajmera wrote: Hi all, Did any body else had a problem while transmitting through USRP board? I am using Basic Tx/Rx board. When I tried to send a sinusoidal signal of 50Khz (through GRC) and tried to look at at the transmitted signal on to the oscilloscope by probing the Tx SMA connector, it displayed a sinusoid of 25Mhz with a constant DC offset. I guess there is an up conversion to an IF frequency is been done in USRP, but do anybody know is there any fixed frequency the signal is up converted to? At what mamimum power can a signal be transmitted using USRP?Is there a way we can control Transmission Power? Also when I unplugged the power to USRP and the USB cable, then also I was able to see a sinusoid, on the scope, of 60Mhz. Is there anything we need to enable in order to make the transmitter work? Also is there any kind of reference manual available for the Basic TX/Rx Daughter board? Thanks Regards, Somya Ajmera Try this: $ usrp_siggen.py -i 64 --sine -w 50k -a 16000 -f 5M And look at it with a spectrum analyzer. You'll see a sine wave at 5.050 MHz. The Basic Tx has a transformer-coupled output, and that will attenuate output below 1MHz. For help understanding the above command, try $ usrp_siggen.py --help Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP USRP2
Hi Eric, I am able to locate USRP1 schematic files. Could you pl. let me know the link for USRP2 schematic files. Thanks in advance. Regds/Sudhir. On Sat, Apr 18, 2009 at 1:20 AM, Eric Blossom e...@comsec.com wrote: On Fri, Apr 17, 2009 at 02:18:20PM +0530, Chitla S wrote: Hi, I am new to USRP. Would like to know about where can we access PCB files or gerber files for USRP1 USRP2? Are we allowed to make modifications to the hardware as per the requirement changes...!! What are the licences applicable for hardware development. Pl advice. Thanks, Sudhir. The schematics are available, the PCB files and gerbers are not. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Overrun Problem
Hi all, I am testing an application, which receives data from usrp. The datarate is 2M, and samples_per_symbol is 2, decimation is 16. I am using a PC, with Ubuntu 8.10, intel pentium 4 cpu 2.40G, and 768M Memory. But the shell displays uOuOuO when running. I know it means usrp overrun. I am not opening any large programs except internet brower. Because i cannot change the decimation and sample_per_symbol, What method can i use to avoid usrp overrun? Any help in this regard would be highly appreciated, and thank you for your help! Regards, Lizhao ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
