[Discuss-gnuradio] USRP2 Carrier Sensing using Raw Samples
Hello, I recently ran an experiment using the USRP2 to collect IQ samples using usrp2_rx_cfile.py. I want to detect when the an 802.11b channel is busy using these raw samples. I've seen the use of the filter y[n] = alpha*x[n] + (1-alpha)*y[n-1] with alpha as 0.001 in the carrier sensing BBN 802.11 code. The default threshold was set to 30 dB. I've imported the data to Matlab and calculated the magnitude squared of each sample and ran it through this filter, but it appears that the data does not match the packets that I sent. The carrier sensing code might correspond to the USRP, but are there any direct changes I would need to make for the USRP2 to use the carrier sensing code? I've read through this post: http://www.ruby-forum.com/topic/120841 but it deals with the USRP at the FPGA level. Anyone have any suggestions? Thanks, Miklos Christine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building complete FM receiver/transmitter with two dell laptops and two usrp radios
You will need to checkout the latest branch of the BBN code. You should checkout the usrp2_version of the code. https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version - Miklos On Tue, Nov 10, 2009 at 6:03 PM, Adam Lee adamryan...@gmail.com wrote: hello, i've gone through a few tutorials and have recently been trying to install and run the bbn 802.11b code in particular to test out the transmitter and receiver but have run into a myriad of troubles including having to change references, include standard libraries in code, and now the code cant find a block called 'blks'. Is there any code out there that is up to date that doesn't require so much tinkering? I just want to test my two pieces of equipment. Thank you for any help or references, if anyone knows how to find 'blks' i would appreciate that as well, thank you. ___ 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] About the simple_mac.py in bbn80211
Can you describe what errors you are getting? - Miklos On Thu, Oct 15, 2009 at 2:58 PM, Chen Chen morningchen1...@gmail.comwrote: Hi, I download the bbn80211, and want to use the simple_mac.py to do some experiment. But this code is not compile with the new version of GNU Radio, thus cause many errors. Does anyone do the modification of this script so that it can work with the new GNU Radio version? Thank you very much. Best, Chen Chen ___ 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] Error Compiling BBN USRP2 Code
I never received this error in 32-bit ubuntu. I did a ./bootstrap, but receive this error: configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level configure.ac:40: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:41: error: possibly undefined macro: AC_ENABLE_SHARED configure.ac:42: error: possibly undefined macro: AC_DISABLE_STATIC configure.ac:43: error: possibly undefined macro: AC_PROG_LIBTOOL configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level ./bootstrap: 28: libtoolize: not found configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level doc/Makefile.am:77: `%'-style pattern rules are a GNU make extension doc/Makefile.am:80: `%'-style pattern rules are a GNU make extension src/bbn/Makefile.am:60: Libtool library used but `LIBTOOL' is undefined src/bbn/Makefile.am:60: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/bbn/Makefile.am:60: to `configure.ac' and run `aclocal' and `autoconf' again. src/bbn/Makefile.am:60: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure src/bbn/Makefile.am:60: its definition is in aclocal's search path. Thanks, Miklos On Thu, Oct 1, 2009 at 5:29 PM, Chen Chen morningchen1...@gmail.com wrote: Hi, Have you done the ./bootstrap step? Chen Chen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling BBN USRP2 Code
Fixed it. Thanks, Miklos On Fri, Oct 2, 2009 at 10:49 AM, Miklos Christine mchrist...@berkeley.eduwrote: I never received this error in 32-bit ubuntu. I did a ./bootstrap, but receive this error: configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level configure.ac:40: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:41: error: possibly undefined macro: AC_ENABLE_SHARED configure.ac:42: error: possibly undefined macro: AC_DISABLE_STATIC configure.ac:43: error: possibly undefined macro: AC_PROG_LIBTOOL configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level ./bootstrap: 28: libtoolize: not found configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level doc/Makefile.am:77: `%'-style pattern rules are a GNU make extension doc/Makefile.am:80: `%'-style pattern rules are a GNU make extension src/bbn/Makefile.am:60: Libtool library used but `LIBTOOL' is undefined src/bbn/Makefile.am:60: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/bbn/Makefile.am:60: to `configure.ac' and run `aclocal' and `autoconf' again. src/bbn/Makefile.am:60: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure src/bbn/Makefile.am:60: its definition is in aclocal's search path. Thanks, Miklos On Thu, Oct 1, 2009 at 5:29 PM, Chen Chen morningchen1...@gmail.comwrote: Hi, Have you done the ./bootstrap step? Chen Chen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error Compiling BBN USRP2 Code
I checked out the bbn code from: svn co https://www.cgran.org/cgran/projects/bbn_80211/branches/usrp2_version/ I'm using the newest stable release of Gnuradio 3.2.2 on Ubuntu 9.04 64-bit. When I do ./configure in the gr-bbn folder, it doesn't give me an error. Once I type make, I get this: cd . /bin/bash /home/mwc/Research/gnuradio-80211b/branch/multiple_bit_rates/gr-bbn/missing --run automake-1.10 --gnu configure.ac:47: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd config/gr_scripting.m4:22: GR_SCRIPTING is expanded from... configure.ac:47: the top level doc/Makefile.am:77: `%'-style pattern rules are a GNU make extension doc/Makefile.am:80: `%'-style pattern rules are a GNU make extension src/bbn/Makefile.am:60: Libtool library used but `LIBTOOL' is undefined src/bbn/Makefile.am:60: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/bbn/Makefile.am:60: to `configure.ac' and run `aclocal' and `autoconf' again. src/bbn/Makefile.am:60: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure src/bbn/Makefile.am:60: its definition is in aclocal's search path. make: *** [Makefile.in] Error 1 I've compiled this code with Ubuntu 32-bit version before and never received this error. Does anyone know why I get this error or a solution for it? Thanks, Miklos Christine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn code error
I don't think that your problem is with compiling Gnuradio. It seems to be an issue with linking your python library files. - Miklos On Wed, Sep 23, 2009 at 7:47 AM, maher manai manmah...@yahoo.fr wrote: i'm using gnuradio 3.2.1 version (installed on fedora 10), i installed bbn code (usrp2 version) and i have some errors when i run examples [r...@maher examples]# ./bbn_80211b_test.py Traceback (most recent call last): File ./bbn_80211b_test.py, line 35, in module from bbn_80211b_pkt import * File /home/maher/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py, line 32, in module from gnuradio import bbn ImportError: cannot import name bbn i think that the problem is coming from gnuradio installation because when i installed gnuradio i ignored some errors wich are The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-qtgui These components will not be built. if the error is coming from installation what shall i do if not i want to know the problem is caused by what thanks ___ 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] USRP2 Sample 2.4 GHz Channel
Yes, that is exactly what I'm looking for. However, when running
usrp2_rx_cfile.py with decimation = 4, I get a 'S' printing to stdout. Is
anyone else able to run usrp2_rx_cfile.py and not get that overrun message?
What could be the reason for 'S'? Is it a limitation on how fast we can
write the samples to the hard disk?
I want to keep the maximum number of samples possible.
Thanks,
Miklos Christine
On Wed, Sep 16, 2009 at 6:52 AM, Douglas Geiger
doug.gei...@bioradiation.net wrote:
When you say sample the channel - are you trying to look at the IQ
samples coming right out of the USRP2? In which case, the easiest way
to start would be to use the usrp2_rx_cfile.py script, then you can
load the file into Matlab/Octave/etc. to take a look at. If you want
to record samples coming out of one of a block in the flowgraph (e.g.
in the 802.11b scripts) - you can modify the flowgraph to connect up a
file_sink at each point you want to record data from.
Doug
On Tue, Sep 15, 2009 at 9:41 PM, Miklos Christine
mchrist...@berkeley.edu wrote:
Hello,
I'm trying to sample the 802.11b wireless channels but the USRP2. I'm
currently using revision 10689 of Gnuradio.
I've added code to bbn_80211b_rx.py to connect the gr_probe_signal_f() to
the top block.
To sample the channel, I use gr.probe_signal_f().
Here's the code to connect the block:
self.connect(self.u, self.conv_c2f, self.probe2)
Then I use the gr.probe_signal_f().level() to retrieve the signal in a
loop.
data_file = open('data.txt', 'w')
T1 = time.asctime()
while cs_samples 100:
CST = self.tb.probe_channel()
data_file.write(str(CST) + '\n')
cs_samples += 1
data_file.close()
T2 = time.asctime()
def probe_channel(self):
return self.probe2.level()
I was wondering if this is the fastest way to sample the channel from
python. When I compute how long this process takes, it appears that I can
get a sample every 8-9 microseconds, which seems a lot slower than what
the
USRP2 is built to do. Am I sampling the channel in an incorrect way?
I'm running this on a machine with a Intel Quad Q9650 @ 3GHz.
Thanks,
Miklos Christine
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Sample 2.4 GHz Channel
Hello,
I'm trying to sample the 802.11b wireless channels but the USRP2. I'm
currently using revision 10689 of Gnuradio.
I've added code to bbn_80211b_rx.py to connect the gr_probe_signal_f() to
the top block.
To sample the channel, I use gr.probe_signal_f().
Here's the code to connect the block:
self.connect(self.u, self.conv_c2f, self.probe2)
Then I use the gr.probe_signal_f().level() to retrieve the signal in a loop.
data_file = open('data.txt', 'w')
T1 = time.asctime()
while cs_samples 100:
CST = self.tb.probe_channel()
data_file.write(str(CST) + '\n')
cs_samples += 1
data_file.close()
T2 = time.asctime()
def probe_channel(self):
return self.probe2.level()
I was wondering if this is the fastest way to sample the channel from
python. When I compute how long this process takes, it appears that I can
get a sample every 8-9 microseconds, which seems a lot slower than what the
USRP2 is built to do. Am I sampling the channel in an incorrect way?
I'm running this on a machine with a Intel Quad Q9650 @ 3GHz.
Thanks,
Miklos Christine
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Output Stream Data Rates
Hello, Is possible to increase the output stream data rates? In gr_block.h, it mentions that all output streams must produce data at the same rate, but is the output stream data rate fixed? I'm working with a USRP2 and using gnuradio revision 10689 with the bbn 80211 mac layer code. Thanks, Miklos Christine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 80211_mac Carrier Sensing
Hello, I had a couple of questions about the carrier sensing functionality of the USRP2 and the BBN 802.11 code. When we call the carrier_sensing function and it returns a value in dB, how does the USRP2 sample its data? I know that it takes an average of the samples of the channel by using an IIR filter with the parameter alpha = 0.001. I calculated the sample period to be approximately 10 usec. Does the USRP2 actually sample faster (i.e. 1 usec), filter/decimate the data before returning a value every 10 usec? How fast can the USRP2 actually sample data? Does anyone suggest a value for alpha? With the given alpha, the carrier sensing block is storing values of the channel on the order of 10s of msec ago. Packets should last about 1-2 msec, so storing information for that long does not make a lot of sense. Thanks, Miklos Christine ___ 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
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
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
[Discuss-gnuradio] USRP2 Gnuradio 3.1.3 and BBN 802.11 Code Working?
Hello, I'm working on a project that involves the USRP2. I've downloaded the lastest version of Gnuradio and the BBN 802.11 code. I've come to realize that the newest release of Gnuradio is not compatible with the BBN code. Is there an earlier version of gnuradio that will work with the USRP2 and the BBN code? Thanks, Miklos Christine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Gnuradio 3.1.3 and BBN 802.11 Code Working?
If I revert to an old version of Gnuradio, would the USRP2 work with that? The Gnuradio code and BBN code that worked on the USRP, would it work on the USRP2? Is it backwards compatible? Thanks, Miklos Christine On Thu, Feb 19, 2009 at 11:26 AM, Eric Blossom e...@comsec.com wrote: On Thu, Feb 19, 2009 at 10:40:42AM -0800, Miklos Christine wrote: Hello, I'm working on a project that involves the USRP2. I've downloaded the lastest version of Gnuradio and the BBN 802.11 code. I've come to realize that the newest release of Gnuradio is not compatible with the BBN code. Is there an earlier version of gnuradio that will work with the USRP2 and the BBN code? Thanks, Miklos Christine The USRP2 is new. No early version of GNU Radio supports it. A bit of googling will find you several discussions about people updating the BBN code to work with the latest GR code. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
