Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hello, The USRP2 has a high data rate and it needs a lot of resources, I don't think that it is a good idea to run both USRP2's on one machine. Ben Yahmed Miklos Christine wrote: Hello, I don't encounter this problem anymore. Someone else was trying to debug the code. I tried to run both USRP2's on one machine with 2 gigabit ethernet ports. It did not seem to work. Does anyone know if it is possible to run both USRP2's on one machine? Thanks, Miklos Christine On Mon, May 11, 2009 at 1:45 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr wrote: Hi, I do not encounter this problem, the simple_mac run in a correct way for me. Do you use the latest versions of the firmware and fpga? Ben Yahmed Miklos Christine wrote: Hello Ben, When I try to run the version of simple_mac that you posted, I get an error. It seems like an infinite loop that prints to stdout: 2nstreams: It happens at the call to fg.rxpath.start() . Do you have the same problem? Thanks, Miklos Christine On Wed, May 6, 2009 at 10:46 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr wrote: Hi all, I modified the gain in the bbn_80211_rx.py file from 46 to 27 and the loss ratio has fallen down to 15-20%. Do you have any idea about the best value to put? this is the ping capture: # ping 10.0.0.1PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=1 ttl=64 time=51.9 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=2 ttl=64 time=52.0 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=3 ttl=64 time=52.0 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=4 ttl=64 time=49.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=5 ttl=64 time=49.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=6 ttl=64 time=46.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=7 ttl=64 time=45.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=10 ttl=64 time=35.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=12 ttl=64 time=35.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=13 ttl=64 time=34.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=15 ttl=64 time=32.5 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=16 ttl=64 time=33.0 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=17 ttl=64 time=29.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=18 ttl=64 time=29.8 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=19 ttl=64 time=28.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=20 ttl=64 time=28.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=21 ttl=64 time=27.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=22 ttl=64 time=25.8 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=23 ttl=64 time=24.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=24 ttl=64 time=23.6 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=25 ttl=64 time=22.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=26 ttl=64 time=20.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=27 ttl=64 time=21.5 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=28 ttl=64 time=11.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=29 ttl=64 time=10.9 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=30 ttl=64 time=10.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=31 ttl=64 time=11.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=32 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=33 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=34 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=36 ttl=64 time=9.74 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=38 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=39 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=40 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=41 ttl=64
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi, I do not encounter this problem, the simple_mac run in a correct way for me. Do you use the latest versions of the firmware and fpga? Ben Yahmed Miklos Christine wrote: Hello Ben, When I try to run the version of simple_mac that you posted, I get an error. It seems like an infinite loop that prints to stdout: 2nstreams: It happens at the call to fg.rxpath.start() . Do you have the same problem? Thanks, Miklos Christine On Wed, May 6, 2009 at 10:46 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr wrote: Hi all, I modified the gain in the bbn_80211_rx.py file from 46 to 27 and the loss ratio has fallen down to 15-20%. Do you have any idea about the best value to put? this is the ping capture: # ping 10.0.0.1PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=1 ttl=64 time=51.9 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=2 ttl=64 time=52.0 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=3 ttl=64 time=52.0 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=4 ttl=64 time=49.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=5 ttl=64 time=49.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=6 ttl=64 time=46.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=7 ttl=64 time=45.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=10 ttl=64 time=35.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=12 ttl=64 time=35.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=13 ttl=64 time=34.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=15 ttl=64 time=32.5 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=16 ttl=64 time=33.0 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=17 ttl=64 time=29.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=18 ttl=64 time=29.8 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=19 ttl=64 time=28.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=20 ttl=64 time=28.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=21 ttl=64 time=27.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=22 ttl=64 time=25.8 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=23 ttl=64 time=24.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=24 ttl=64 time=23.6 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=25 ttl=64 time=22.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=26 ttl=64 time=20.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=27 ttl=64 time=21.5 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=28 ttl=64 time=11.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=29 ttl=64 time=10.9 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=30 ttl=64 time=10.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=31 ttl=64 time=11.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=32 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=33 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=34 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=36 ttl=64 time=9.74 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=38 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=39 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=40 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=41 ttl=64 time=10.8 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=44 ttl=64 time=9.83 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=45 ttl=64 time=10.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=47 ttl=64 time=9.91 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=48 ttl=64 time=10.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=49 ttl=64 time=11.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=50 ttl=64 time=10.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=51 ttl=64 time=10.4 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=52 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=53 ttl=64 time=10.0 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=54 ttl=64 time=16.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=55 ttl=64 time=10.1 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=56 ttl=64 time=10.6 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=58 ttl=64 time=9.69 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=60 ttl=64 time=10.2 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=62 ttl=64 time=9.91 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=63 ttl=64 time=10.3 ms 64 bytes from 10.0.0.1 http://10.0.0.1: icmp_seq=65 ttl=64
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi all, I modified the gain in the bbn_80211_rx.py file from 46 to 27 and the loss ratio has fallen down to 15-20%. Do you have any idea about the best value to put? this is the ping capture: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=51.9 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=52.0 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=52.0 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=49.2 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=49.4 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=46.3 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=45.7 ms 64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=35.2 ms 64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=35.1 ms 64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=34.3 ms 64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=32.5 ms 64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=33.0 ms 64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=29.7 ms 64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=29.8 ms 64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=28.7 ms 64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=28.1 ms 64 bytes from 10.0.0.1: icmp_seq=21 ttl=64 time=27.2 ms 64 bytes from 10.0.0.1: icmp_seq=22 ttl=64 time=25.8 ms 64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=24.2 ms 64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=23.6 ms 64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=22.4 ms 64 bytes from 10.0.0.1: icmp_seq=26 ttl=64 time=20.4 ms 64 bytes from 10.0.0.1: icmp_seq=27 ttl=64 time=21.5 ms 64 bytes from 10.0.0.1: icmp_seq=28 ttl=64 time=11.1 ms 64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=10.9 ms 64 bytes from 10.0.0.1: icmp_seq=30 ttl=64 time=10.2 ms 64 bytes from 10.0.0.1: icmp_seq=31 ttl=64 time=11.3 ms 64 bytes from 10.0.0.1: icmp_seq=32 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1: icmp_seq=33 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1: icmp_seq=34 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1: icmp_seq=36 ttl=64 time=9.74 ms 64 bytes from 10.0.0.1: icmp_seq=38 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1: icmp_seq=39 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1: icmp_seq=40 ttl=64 time=11.2 ms 64 bytes from 10.0.0.1: icmp_seq=41 ttl=64 time=10.8 ms 64 bytes from 10.0.0.1: icmp_seq=44 ttl=64 time=9.83 ms 64 bytes from 10.0.0.1: icmp_seq=45 ttl=64 time=10.4 ms 64 bytes from 10.0.0.1: icmp_seq=47 ttl=64 time=9.91 ms 64 bytes from 10.0.0.1: icmp_seq=48 ttl=64 time=10.1 ms 64 bytes from 10.0.0.1: icmp_seq=49 ttl=64 time=11.1 ms 64 bytes from 10.0.0.1: icmp_seq=50 ttl=64 time=10.4 ms 64 bytes from 10.0.0.1: icmp_seq=51 ttl=64 time=10.4 ms 64 bytes from 10.0.0.1: icmp_seq=52 ttl=64 time=10.7 ms 64 bytes from 10.0.0.1: icmp_seq=53 ttl=64 time=10.0 ms 64 bytes from 10.0.0.1: icmp_seq=54 ttl=64 time=16.3 ms 64 bytes from 10.0.0.1: icmp_seq=55 ttl=64 time=10.1 ms 64 bytes from 10.0.0.1: icmp_seq=56 ttl=64 time=10.6 ms 64 bytes from 10.0.0.1: icmp_seq=58 ttl=64 time=9.69 ms 64 bytes from 10.0.0.1: icmp_seq=60 ttl=64 time=10.2 ms 64 bytes from 10.0.0.1: icmp_seq=62 ttl=64 time=9.91 ms 64 bytes from 10.0.0.1: icmp_seq=63 ttl=64 time=10.3 ms 64 bytes from 10.0.0.1: icmp_seq=65 ttl=64 time=11.0 ms 64 bytes from 10.0.0.1: icmp_seq=67 ttl=64 time=10.1 ms 64 bytes from 10.0.0.1: icmp_seq=68 ttl=64 time=11.0 ms 64 bytes from 10.0.0.1: icmp_seq=69 ttl=64 time=15.5 ms ^C --- 10.0.0.1 ping statistics --- 69 packets transmitted, 55 received, 20% packet loss, time 68792ms rtt min/avg/max/mdev = 9.695/20.881/52.076/13.669 ms Ben Yahmed wrote: Hi all, I succeeded to make the simple_mac.py working. now it's pinging correctly but with a huge loss ratio. At first I disabled the carrier sense functions but after I reactivated them but I'm not sure these functions are working. I attached the 80211_mac folder so any suggestion or amelioration is welcome. I used this command line to run the python file: ./simple_mac.py -S 8 -v I also hard_coded my mac adress so you need to change it before use. you can see here the results that I have obtained by ping: [r...@wlab28 ~]# ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. From 10.0.0.2 icmp_seq=2 Destination Host Unreachable From 10.0.0.2 icmp_seq=3 Destination Host Unreachable From 10.0.0.2 icmp_seq=4 Destination Host Unreachable From 10.0.0.2 icmp_seq=5 Destination Host Unreachable From 10.0.0.2 icmp_seq=6 Destination Host Unreachable From 10.0.0.2 icmp_seq=7 Destination Host Unreachable 64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=7.66 ms 64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=15.3 ms 64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=7.57 ms 64 bytes from 10.0.0.1: icmp_seq=33 ttl=64 time=8.12 ms 64 bytes from 10.0.0.1: icmp_seq=42 ttl=64 time=7.63 ms 64 bytes from 10.0.0.1: icmp_seq=49 ttl=64 time=8.13 ms 64 bytes from 10.0.0.1: icmp_seq=55 ttl=64 time=7.67 ms 64 bytes from 10.0.0.1: icmp_seq=56 ttl=64 time=7.74 ms 64 bytes from 10.0.0.1: icmp_seq=57 ttl=64 time=7.61 ms 64 bytes from 10.0.0.1: icmp_seq=69 ttl=64 time
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Good News I finally succeeded to receive with an USRP2 packets sent with another USRP2. I tryed to modify the parameters and found the magic combination: ./bbn_80211b_tx.py -f 2.4G -e eth1 -i 24 -r 20 gr_fir_ccf: using SSE Network interface: eth1 USRP2 address: 00:50:c2:85:30:cb Using TX d'board id 0x0060 Tx baseband frequency: 2.4G Tx DUC frequency: 0 Tx residual frequency: 0 Tx interpolation rate: 24 Samples per data bit: 8 DATA: Hello world Sending pkt 0 Sending pkt 1 Sending pkt 2 Sending pkt 3 Sending pkt 4 Sending pkt 5 Sending pkt 6 Sending pkt 7 Sending pkt 8 Sending pkt 9 Sending pkt 10 Sending pkt 11 Sending pkt 12 Sending pkt 13 Sending pkt 14 Sending pkt 15 Sending pkt 16 Sending pkt 17 Sending pkt 18 Sending pkt 19 ./bbn_80211b_rx.py -f 2.4G -v Bits Per Encoded Sample = 16 adc frequency = 1 decimation frequency = 24 input_rate = 416 gain = 46.0 desired freq = 24.0 baseband frequency 24.0 dxc frequency 0.0 Samples per data bit = 8 gr_fir_ccf: using SSE callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1405840, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1406760, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1407128, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1407496, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1407872, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1408232, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1408600, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1408992, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1409360, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1409720, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1410096, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1410456, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1410840, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1411384, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1411616, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1412352, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1412440, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1412808, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1413016, rate=1 Mbps callback PKT: len=15, rssi=-96, src=UNKNOWN, time=1413384, rate=1 Mbps ___ 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
Hi, Did you try to send and receive packets between 2 USRP2? I tryed but without any result. Are you sure that it's working correctly? I will have a look to the code in more details and tell you if something will work. Ben Yahmed Smith L. wrote: 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
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
I run wireshark on the eth0 to see the traffic between USRP2 and the PC while running the rx file. ok for the test code. Colby Boyer wrote: Ah, so wireshark on a 802.11b card can capture packets sent by the USRP2? I will modify my test code so that it usable by some one else. It is sorta hacked together and difficult to understand. I'll try to send it to the list sometime today. On Mon, Apr 20, 2009 at 2:14 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr wrote: Hi all, Thank you Colby for the update. I just run the code and it seems to work, but when I send packets from another USRP2 with the same frequency (bbn_80211b_tx_port2.py) I don't see anything happening. when I run wireshark, a huge number of packets was arriving, something like 11000 packets /s with the protocol 0xbeef I don't know how it should work exactly, but I think that the USRP2 is capturing the signal without beeing able to differentiate the packtes sent by the other USRP2. Can you share with us the code that works with the file to see the output of bbn_80211b_rx.py ? Ben Yahmed Colby Boyer wrote: 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 mailto:csbo...@berkeley.edu mailto:csbo...@berkeley.edu mailto: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.com mailto:colby.bo...@gmail.com mailto:colby.bo...@gmail.com mailto: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 mailto:maher.ben_yah...@sophia.inria.fr mailto:maher.ben_yah...@sophia.inria.fr mailto: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 mailto:vale...@ftw.at mailto:vale...@ftw.at mailto:vale...@ftw.at mailto:vale...@ftw.at mailto: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
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi all, Thank you Colby for the update. I just run the code and it seems to work, but when I send packets from another USRP2 with the same frequency (bbn_80211b_tx_port2.py) I don't see anything happening. when I run wireshark, a huge number of packets was arriving, something like 11000 packets /s with the protocol 0xbeef I don't know how it should work exactly, but I think that the USRP2 is capturing the signal without beeing able to differentiate the packtes sent by the other USRP2. Can you share with us the code that works with the file to see the output of bbn_80211b_rx.py ? Ben Yahmed Colby Boyer wrote: 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 mailto: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.com mailto: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 mailto: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 mailto: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
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 http://lists.gnu.org/mailman
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
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 all, I'm very interested in the code you are discussing and as a first step I installed gnuradio and the svn code taken from https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version on a fedora core 10 and tried to test the bbn_80211b_test.py, but I encountred this problem: # ./bbn_80211b_test.py gr_fir_ccf: using SSE Traceback (most recent call last): File ./bbn_80211b_test.py, line 120, in module main() File ./bbn_80211b_test.py, line 101, in main tb = my_block(rx_callback, options.spb, options.alpha, options.snr) File ./bbn_80211b_test.py, line 53, in __init__ self.packet_transmitter = bbn_80211b_mod_pkts(spb=spb, alpha=alpha, gain=1) File /root/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py, line 67, in __init__ self.xpsk_mod = bbn_80211b.bbn_80211b_mod(*args, **kwargs) File /root/usrp2_version/gr-bbn/src/examples/bbn_80211b.py, line 95, in __init__ gr.hier_block2.__init__(self, bbn_80211b, gr.io_signature(1, 1, gr.sizeof_char), gr.io_signature(1, 2, gr.sizeof_gr_complex)) File /usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py, line 42, in __init__ self._hb = hier_block2_swig(name, input_signature, output_signature) File /usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1009, in hier_block2_swig return _gnuradio_swig_py_runtime.hier_block2_swig(*args, **kwargs) RuntimeError: Hierarchical blocks do not yet support arbitrary or variable numbers of inputs or outputs (bbn_80211b) do you have any idea about the origin of this problem? Thank you in advance. ___ 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
Thank you for your help, the error disappeared Ben Yahmed Johnathan Corgan wrote: The issue is with the output signature being declared in the last part of the above line. It is trying to create a hierarchical block with a variable number of output ports. This functionality is not yet supported. In the past, we silently ignored this, and if the block didn't actually try to use the feature, it would work okay. To be more robust, we recently made this a hard error, which is why the above error message started happening. Looking at the code, it appears that all you need to do is change the line to have an output signature of 1, 1 instead of 1, 2. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
