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
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 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 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
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi Everyone, I think I understand the problem with the DBPSK/DQPSK. Currently, the modulate function modulates the entire packet as 2Mbps. However, the PLCP decode function expects the packet to be DBPSK for the header and then DQPSK for rest of the payload. The solution I have devised is to rewrite the C++ processing blocks used by the modulator to handle the bit rate change. If anyone else has a better idea to handle the switch, it would be greatly appricated. --Colby On Mon, May 11, 2009 at 1:45 AM, Ben Yahmed 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 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:
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
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 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: 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:
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
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Yahmed 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. I have a vague recollection that the BBN folks had a similar experience/instruction to manually tweak the gains (depending on the enviornment, tx/rx separation, etc.), and that there was no one-size-fits-all. An AGC would be really nice, but not sure what the best way to do that would be. Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKAeGwgfOzzR5bXIgRAhGYAKCYKijBqNRyk/NJtfJgaGwp2YCimACfRlcY 8nl86VfeVBFpe0HzOTj9YKY= =Pg+K -END PGP SIGNATURE- ___ 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
Has anyone been able to get 2Mbps to work, which uses DQPSK instead of DBPSK? I have had no luck, even with the test script. . . --Colby On Sun, Apr 26, 2009 at 9:39 PM, Colby Boyer csbo...@berkeley.edu wrote: I think some of the work my group will require porting the mac layer to the USRP2. I'll keep the list posted. --Colby On Sat, Apr 25, 2009 at 2:32 PM, maher.ben_yah...@sophia.inria.fr wrote: The next step is to convert the simple_mac.py inorder to work with USRP2. Who is interested in this work? Ben Yahmed It was a firmware problem, and after updating the latest firmware I was able to transmit/receive at 1Mbps. -Colby Good work everyone! =) On Fri, Apr 24, 2009 at 11:23 AM, Colby Boyer csbo...@berkeley.edu wrote: Hi, I am unable to replicate the results. Are you using the code from the CGRAN repo without any modifcations? I am also receiving a usrp2::ctor reset_db failed error. Could this be a problem? Thanks, Colby On Fri, Apr 24, 2009 at 10:41 AM, Eric Blossom e...@comsec.com wrote: On Fri, Apr 24, 2009 at 02:15:36PM +0200, Ben Yahmed wrote: 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: Yeah! 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 think some of the work my group will require porting the mac layer to the USRP2. I'll keep the list posted. --Colby On Sat, Apr 25, 2009 at 2:32 PM, maher.ben_yah...@sophia.inria.fr wrote: The next step is to convert the simple_mac.py inorder to work with USRP2. Who is interested in this work? Ben Yahmed It was a firmware problem, and after updating the latest firmware I was able to transmit/receive at 1Mbps. -Colby Good work everyone! =) On Fri, Apr 24, 2009 at 11:23 AM, Colby Boyer csbo...@berkeley.edu wrote: Hi, I am unable to replicate the results. Are you using the code from the CGRAN repo without any modifcations? I am also receiving a usrp2::ctor reset_db failed error. Could this be a problem? Thanks, Colby On Fri, Apr 24, 2009 at 10:41 AM, Eric Blossom e...@comsec.com wrote: On Fri, Apr 24, 2009 at 02:15:36PM +0200, Ben Yahmed wrote: 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: Yeah! 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
The next step is to convert the simple_mac.py inorder to work with USRP2. Who is interested in this work? Ben Yahmed It was a firmware problem, and after updating the latest firmware I was able to transmit/receive at 1Mbps. -Colby Good work everyone! =) On Fri, Apr 24, 2009 at 11:23 AM, Colby Boyer csbo...@berkeley.edu wrote: Hi, I am unable to replicate the results. Are you using the code from the CGRAN repo without any modifcations? I am also receiving a usrp2::ctor reset_db failed error. Could this be a problem? Thanks, Colby On Fri, Apr 24, 2009 at 10:41 AM, Eric Blossom e...@comsec.com wrote: On Fri, Apr 24, 2009 at 02:15:36PM +0200, Ben Yahmed wrote: 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: Yeah! 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
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] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Yep! It works also here between USRPs2 with the code from colby's branch (also with other parameters, as far as interp*spb=~200). The problem is the DSSS... I don't know why, but whenever Barker is enabled, nothing works anymore... :-( Have you tried? Colby mentioned that even the test has problem with Barker. Best Regards, Danilo On Friday 24 April 2009 14:15:36 Ben Yahmed wrote: 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 cut ./bbn_80211b_rx.py -f 2.4G -v cut ___ 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
On Fri, Apr 24, 2009 at 02:15:36PM +0200, Ben Yahmed wrote: 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: Yeah! 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, I am unable to replicate the results. Are you using the code from the CGRAN repo without any modifcations? I am also receiving a usrp2::ctor reset_db failed error. Could this be a problem? Thanks, Colby On Fri, Apr 24, 2009 at 10:41 AM, Eric Blossom e...@comsec.com wrote: On Fri, Apr 24, 2009 at 02:15:36PM +0200, Ben Yahmed wrote: 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: Yeah! 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
It was a firmware problem, and after updating the latest firmware I was able to transmit/receive at 1Mbps. -Colby Good work everyone! =) On Fri, Apr 24, 2009 at 11:23 AM, Colby Boyer csbo...@berkeley.edu wrote: Hi, I am unable to replicate the results. Are you using the code from the CGRAN repo without any modifcations? I am also receiving a usrp2::ctor reset_db failed error. Could this be a problem? Thanks, Colby On Fri, Apr 24, 2009 at 10:41 AM, Eric Blossom e...@comsec.com wrote: On Fri, Apr 24, 2009 at 02:15:36PM +0200, Ben Yahmed wrote: 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: Yeah! 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 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 that the
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
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
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] [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] [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] [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
On Tue, Apr 7, 2009 at 5:02 AM, Ben Yahmed maher.ben_yah...@sophia.inria.fr wrote: 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)) RuntimeError: Hierarchical blocks do not yet support arbitrary or variable numbers of inputs or outputs (bbn_80211b) 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
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
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Updated from the trunk and I'm not getting that msg anymore. Everything seems to be ok now. 2009/4/3 Eric Blossom e...@comsec.com On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote: I fixed the problem. The top_block on bbn_80211b_tx_port was not being properly initialized. It seems to be working now, but when I use 8 samples per data bit instead of 4 I randomly got the following error: usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes) Does anyone know what this mean? I'm sending the working code. Can you update from the trunk and try this again. We added what we believe is a work around for this problem on 3/26 in r10689 on the trunk. 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
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 2009/4/3 Eric Blossom e...@comsec.com On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote: I fixed the problem. The top_block on bbn_80211b_tx_port was not being properly initialized. It seems to be working now, but when I use 8 samples per data bit instead of 4 I randomly got the following error: usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes) Does anyone know what this mean? I'm sending the working code. Can you update from the trunk and try this again. We added what we believe is a work around for this problem on 3/26 in r10689 on the trunk. 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
I fixed the problem. The top_block on bbn_80211b_tx_port was not being properly initialized. It seems to be working now, but when I use 8 samples per data bit instead of 4 I randomly got the following error: usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes) Does anyone know what this mean? I'm sending the working code. 2009/4/2 Tiago Rogério Mück ti...@lisha.ufsc.br Hi all, I'm trying to port the tx code to the usrp2 based on Colby's branch and i'm having some problems. The program freezes when the 3rd packet is being sent. The program uses a gr.message_source to buffer the packets and convert them into a data flow to the modulator, and the problem is that, for some reason, the data flow isn't flowing and the packets are accumulating in the msg_source. Since the msg_source's queue size is 2, the method to add the 3rd packet to the queue blocks because the queue is full. I didn't figured out whats the problem with my code. The bbn80211b_test.py woks, so the problem is probably related to the connection of the modulator block with the usrp2 sink or to the configuration of the usrp2. I'm sending the files i have modified. 2009/3/31 Colby Boyer csbo...@berkeley.edu Hi all, I created a branch on the cgran server for the usrp2 code. If anyone is interested in still using the usrp with the hier_block2, just dont use the rx/tx.py files. The rest of the files should work with the usrp1. Cheers, Colby On Mon, Mar 30, 2009 at 3:58 PM, George Nychis gnyc...@cmu.edu wrote: Hi all, CGRAN's trac has a core dumping issue that I still have not figured out how to address yet. So, if you're using the wiki and get blank pages or a 500 internal server error, sorry. I've been trying to sort it out, but no luck yet: http://www.gossamer-threads.com/lists/trac/users/40954 It should not affect the svn server though. - George 2009/3/30 Colby Boyer csbo...@berkeley.edu The cgran server seems to be down. I'll let you know when I am able to get an account. On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer colby.bo...@gmail.comwrote: Sure. I will try to get a cgran account and upload my code to their SVN. It would then be easy to see the changes I made. On Mon, Mar 30, 2009 at 2:21 AM, Costantini, Andrea costant...@ftw.at wrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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 #!/usr/bin/env python # # Copyright 2005 Free Software Foundation, Inc. # # Copyright (c) 2006 BBN Technologies Corp. All rights reserved. # Effort sponsored in part by the Defense Advanced Research Projects # Agency (DARPA) and the Department of the Interior National Business # Center under agreement number NBCHC050166. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. # from gnuradio import gr, gru, blks2 from gnuradio import usrp2 from gnuradio import eng_notation from gnuradio.eng_option import
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote: I fixed the problem. The top_block on bbn_80211b_tx_port was not being properly initialized. It seems to be working now, but when I use 8 samples per data bit instead of 4 I randomly got the following error: usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes) Does anyone know what this mean? I'm sending the working code. Can you update from the trunk and try this again. We added what we believe is a work around for this problem on 3/26 in r10689 on the trunk. 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
Great to hear. I will be able to start testing with two USRPs soon. I am waiting on some hardware. I will let the list know what I find out. On Fri, Apr 3, 2009 at 9:09 AM, Eric Blossom e...@comsec.com wrote: On Fri, Apr 03, 2009 at 10:45:18AM -0300, Tiago Rogério Mück wrote: I fixed the problem. The top_block on bbn_80211b_tx_port was not being properly initialized. It seems to be working now, but when I use 8 samples per data bit instead of 4 I randomly got the following error: usrp2::tx_raw: FIXME: short packet: 7 items (56 bytes) Does anyone know what this mean? I'm sending the working code. Can you update from the trunk and try this again. We added what we believe is a work around for this problem on 3/26 in r10689 on the trunk. 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 trying to port the tx code to the usrp2 based on Colby's branch and i'm having some problems. The program freezes when the 3rd packet is being sent. The program uses a gr.message_source to buffer the packets and convert them into a data flow to the modulator, and the problem is that, for some reason, the data flow isn't flowing and the packets are accumulating in the msg_source. Since the msg_source's queue size is 2, the method to add the 3rd packet to the queue blocks because the queue is full. I didn't figured out whats the problem with my code. The bbn80211b_test.py woks, so the problem is probably related to the connection of the modulator block with the usrp2 sink or to the configuration of the usrp2. I'm sending the files i have modified. 2009/3/31 Colby Boyer csbo...@berkeley.edu Hi all, I created a branch on the cgran server for the usrp2 code. If anyone is interested in still using the usrp with the hier_block2, just dont use the rx/tx.py files. The rest of the files should work with the usrp1. Cheers, Colby On Mon, Mar 30, 2009 at 3:58 PM, George Nychis gnyc...@cmu.edu wrote: Hi all, CGRAN's trac has a core dumping issue that I still have not figured out how to address yet. So, if you're using the wiki and get blank pages or a 500 internal server error, sorry. I've been trying to sort it out, but no luck yet: http://www.gossamer-threads.com/lists/trac/users/40954 It should not affect the svn server though. - George 2009/3/30 Colby Boyer csbo...@berkeley.edu The cgran server seems to be down. I'll let you know when I am able to get an account. On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer colby.bo...@gmail.comwrote: Sure. I will try to get a cgran account and upload my code to their SVN. It would then be easy to see the changes I made. On Mon, Mar 30, 2009 at 2:21 AM, Costantini, Andrea costant...@ftw.atwrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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 # # Copyright 2005 Free Software Foundation, Inc. # # Copyright (c) 2006 BBN Technologies Corp. All rights reserved. # Effort sponsored in part by the Defense Advanced Research Projects # Agency (DARPA) and the Department of the Interior National Business # Center under agreement number NBCHC050166. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. # from gnuradio import gr, gru, blks2 from gnuradio import usrp2 from bbn_80211b_pkt import * # / # transmit path # / class bbn_80211b_transmit_path(gr.hier_block2): def __init__(self, interp, spb, use_barker, interface=, mac_addr=None): gr.hier_block2.__init__(self, bbn_80211b_transmit_path, gr.io_signature(0,0,0), gr.io_signature(0,0,0)) self.normal_gain
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer On Fri, Mar 27, 2009 at 2:06 AM, Costantini, Andrea costant...@ftw.atwrote: Dear all, I'm trying to port the Douglas BBN 802.11b code on the USRP2 working with the last version of GNU-Radio (3.2SVN) The last version of Douglas bbn 802.11b already work with hier_blok2 but not with USRP2, so, in order to do this porting I followed the recommendations below : - http://www.opensubscriber.com/message/discuss-gnuradio@gnu.org/9944619.html - http://sdrblog.wordpress.com/2009/03/12/port-usrp1-code-to-usrp2/ I just have modified the files bbn_80211b_tx.py and bbn_80211b_transmit_path.py because it should be by means of these ones that we can access to USRP2. I obtain the following error: Traceback (most recent call last): File bbn_80211b_tx.py, line 108, in module main() File bbn_80211b_tx.py, line 72, in main tb = my_block(options.interp, options.spb, options.barker) File bbn_80211b_tx.py, line 22, in __init__ self.txpath = bbn_80211b_transmit_path(interp_rate, spb, use_barker) File /home/usrptest1/bbn_80211_doug/src/examples/bbn_80211b_transmit_path.py, line 44, in __init__ self.packet_transmitter = bbn_80211b_mod_pkts(tb, spb=spb, NameError: global name 'tb' is not defined I am not able to solve this error and debug the new code :-( Any suggestion about this porting will be welcome Best regards Andrea Here below there are my two modified codes: ## # bbn_802.11b_tx.py ## from gnuradio import gr, gru, blks2 from gnuradio import usrp2 from gnuradio import eng_notation from gnuradio.eng_option import eng_option from optparse import OptionParser import random import time import struct import sys # from current dir from bbn_80211b_transmit_path import bbn_80211b_transmit_path class my_block(gr.top_block): def __init__(self, interp_rate, spb, use_barker): gr.top_block.__init__(self) self.txpath = bbn_80211b_transmit_path(interp_rate, spb, use_barker) #def __init__(self, tx_subdev_spec, interp_rate, spb, use_barker): # gr.flow_graph.__init__(self) # self.txpath = bbn_80211b_transmit_path(tx_subdev_spec, \ #interp_rate, spb, use_barker) # / # main # / def main(): def send_pkt(payload='', eof=False): return tb.txpath.send_pkt(payload, eof) def rx_callback(ok, payload): print ok = %r, payload = '%s' % (ok, payload) parser = OptionParser (option_class=eng_option) #parser.add_option(-T, --tx-subdev-spec, type=subdev, default=None, # help=select USRP Tx side A or B) parser.add_option(-f, --freq, type=eng_float, default=2.4e9, help= \ set Tx and Rx frequency to FREQ [default=%default], metavar=FREQ) parser.add_option(-S, --spb, type=int, default=8, help=set samples/baud [default=%default]) parser.add_option(-i, --interp, type=int, default=32, help= set fpga interpolation rate to INTERP [default=%default]) parser.add_option(-r, --reps, type=int, default=20, help= Number of packets to send [default=%default]) parser.add_option(-b, --barker, action=store_true, default=False, help=Use Barker Spreading [default=%default]) (options, args) = parser.parse_args () if len(args) != 0: parser.print_help() sys.exit(1) if options.freq 1e6: options.freq *= 1e6 # build the graph tb = my_block(options.interp, options.spb, options.barker) #print bitrate: %sb/sec % (eng_notation.num_to_str(tb.txpath.bitrate()),) print spb: %3d % (tb.txpath.spb(),)
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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 Douglas! Yes, I was referring to your branch (thank you for that). This comment on the CGRAN made me thinking that also the tx path was changed: bbn_80211b_tx.py - douggeiger: Works with hier_block2 - with some help from code found … Have you uploaded some work-in-progress on the rx path with USRP2? I would really like to look at it, so that I could use it as starting point for working on the tx path. Thanks, Best Regards, Andrea Douglas Geiger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you're referring to my developer branch on CGRAN of the bbn_80211b code, I do not believe the transmit code currently works with GNURadio 3.2. I have gotten the receive code working, and am working on a version that talks to the USRP2, but I have not touched the transmit code at all. It likely still needs to be converted to the new hier_block2 API. Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJzP0ugfOzzR5bXIgRAvw5AJsFsrmRYoJ8+5h8kvVge4NIxWyfkgCdHRi7 l6IzEovyQ3dEvvYMZKlCm5s= =52+W -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Costantini, Andrea wrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). I had started working on getting the receive-side code working with the USRP2 (i.e. modifying the bbn_80211b_rx.py) - although I've had to put it aside to deal with some other matters recently. There's a good summary of the function calls that need to be changed at: http://sdrblog.wordpress.com/2009/03/12/port-usrp1-code-to-usrp2/ I had made similar modifications to the tunnel.py from the gnuradio-examples before - and it is roughly the same. I may be returning to that code soon, and would then be able to share it. If you get things working in the meantime, I'd be happy to include in my CGRAN branch (or you can get a CGRAN account and start your own - I'd love to have help!). Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ0ODZgfOzzR5bXIgRAt/6AKChymI2931pPft/TtV0ivkQrCCGoQCgpjfA hS9ZYkm1Kvz3TaRI+0zbsb0= =oRfS -END PGP SIGNATURE- ___ 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
The cgran server seems to be down. I'll let you know when I am able to get an account. On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer colby.bo...@gmail.com wrote: Sure. I will try to get a cgran account and upload my code to their SVN. It would then be easy to see the changes I made. On Mon, Mar 30, 2009 at 2:21 AM, Costantini, Andrea costant...@ftw.atwrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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, CGRAN's trac has a core dumping issue that I still have not figured out how to address yet. So, if you're using the wiki and get blank pages or a 500 internal server error, sorry. I've been trying to sort it out, but no luck yet: http://www.gossamer-threads.com/lists/trac/users/40954 It should not affect the svn server though. - George 2009/3/30 Colby Boyer csbo...@berkeley.edu The cgran server seems to be down. I'll let you know when I am able to get an account. On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer colby.bo...@gmail.comwrote: Sure. I will try to get a cgran account and upload my code to their SVN. It would then be easy to see the changes I made. On Mon, Mar 30, 2009 at 2:21 AM, Costantini, Andrea costant...@ftw.atwrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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 created a branch on the cgran server for the usrp2 code. If anyone is interested in still using the usrp with the hier_block2, just dont use the rx/tx.py files. The rest of the files should work with the usrp1. Cheers, Colby On Mon, Mar 30, 2009 at 3:58 PM, George Nychis gnyc...@cmu.edu wrote: Hi all, CGRAN's trac has a core dumping issue that I still have not figured out how to address yet. So, if you're using the wiki and get blank pages or a 500 internal server error, sorry. I've been trying to sort it out, but no luck yet: http://www.gossamer-threads.com/lists/trac/users/40954 It should not affect the svn server though. - George 2009/3/30 Colby Boyer csbo...@berkeley.edu The cgran server seems to be down. I'll let you know when I am able to get an account. On Mon, Mar 30, 2009 at 8:36 AM, Colby Boyer colby.bo...@gmail.comwrote: Sure. I will try to get a cgran account and upload my code to their SVN. It would then be easy to see the changes I made. On Mon, Mar 30, 2009 at 2:21 AM, Costantini, Andrea costant...@ftw.atwrote: Hi Colby, I am glad that I am not the only one trying to port the code. I guess you are in a more advanced state. I wasn't even able to run the test.py. ;-) Would you like to share your modified code (even if it is not finished)? so that I try to understand your modifications. Best Regards, Andrea P.S. For the USRP2 api, I usually compare the USRP2 and USRP swig code (e.g. usrp2.py and usrp_swig.py). Colby Boyer wrote: Hi Andrea, I am also working to port the 802.11b code to the USRP2. I have finished converting the code to hier_block2, and the bbn_80211b_test.py script works correctly and it can send packets in simulation. I am currently working on modifying the rx, and tx files to connect to the USRP2, but been struggling to make progress. I have not had much luck finding any documentation for the USRP2 function calls, so I am sorta lost on what to change in rx, tx and tx transmit path files. Does anyone have any links to the usrp2 api? I would be more than happy to share the modifications I made (built largly upon Douglas's work) with rest of the GNU radio community. Regards, Colby Boyer ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Costantini, Andrea wrote: Dear all, I'm trying to port the Douglas BBN 802.11b code on the USRP2 working with the last version of GNU-Radio (3.2SVN) The last version of Douglas bbn 802.11b already work with hier_blok2 but not with USRP2, so, in order to do this porting I followed the recommendations below : - http://www.opensubscriber.com/message/discuss-gnuradio@gnu.org/9944619.html - http://sdrblog.wordpress.com/2009/03/12/port-usrp1-code-to-usrp2/ I just have modified the files bbn_80211b_tx.py and bbn_80211b_transmit_path.py because it should be by means of these ones that we can access to USRP2. I obtain the following error: Traceback (most recent call last): File bbn_80211b_tx.py, line 108, in module main() File bbn_80211b_tx.py, line 72, in main tb = my_block(options.interp, options.spb, options.barker) File bbn_80211b_tx.py, line 22, in __init__ self.txpath = bbn_80211b_transmit_path(interp_rate, spb, use_barker) File /home/usrptest1/bbn_80211_doug/src/examples/bbn_80211b_transmit_path.py, line 44, in __init__ self.packet_transmitter = bbn_80211b_mod_pkts(tb, spb=spb, NameError: global name 'tb' is not defined I am not able to solve this error and debug the new code :-( Any suggestion about this porting will be welcome Best regards Andrea If you're referring to my developer branch on CGRAN of the bbn_80211b code, I do not believe the transmit code currently works with GNURadio 3.2. I have gotten the receive code working, and am working on a version that talks to the USRP2, but I have not touched the transmit code at all. It likely still needs to be converted to the new hier_block2 API. Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJzP0ugfOzzR5bXIgRAvw5AJsFsrmRYoJ8+5h8kvVge4NIxWyfkgCdHRi7 l6IzEovyQ3dEvvYMZKlCm5s= =52+W -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
