I am trying to use bbn 80211b transmitter code (douggeiger version from
cgran website) with GNU Radio 3.2.2 with USRP1. However, it seems like
the
Tx code has not been modified completely to work with hier_block2 APIs.
I
tried to make changes on my own and ended up with an error that I do not
know how to solve?
I am having a Itemsize mismatch error for message source and
bbn_80211_bb_mod.
I am using Ubuntu 8.04, Gnuradio 3.2.2, Python 2.6 and USRP1s. I looked
up
the mailing list and I found very little information for Tx code as
everybody seems to be working on the receiver code.
Does any one have a working copy of bbn_80211b_tx.py of douggeiger
version
that works with GNURadio 3.2.2 and USRP1.
You probably want to take a look at the usrp2_version branch to see
how to get the transmit code working with the hier_block2 API, and
then modify it to work with the USRP1. Two things: you cannot transmit
the 802.11b waveform through the USRP1 (you don’t have enough
bandwidth - in the original code base I believe they simply skipped
the DSSS step, and transmitted the pulse-shaped DPSK-modulated
signal), also I believe the usrp2_version branch transmit code fixed
some of the bugs in the original transmit code (i.e. using a USRP2,
the transmit code could send a standard-compliant waveform).
Doug
I do have two USRP2s and hence was also working on the usrp2_version
code. I
have both the transmitter and receiver code individually working
correctly
with USRP2. However, the receiver is not able to receive the packets
correctly from the transmitter (i.e in case of USRP2). I always get bad
CRC
message.
I have looked up the forum and everybody seem to stuck with the same
problem. Is there any work around to solve this problem?
From the forum discussion, it seems that one of the issues is the
preamble.
Any idea how to make synchronize the receiver so that it can receive the
packets from USRP2 transmitter using bbn code.
Thanks,
Smith
Douglas G.-2 wrote:
Doug
know how to solve?
that works with GNURadio 3.2.2 and USRP1.
When I was working with the USRP2 version, I was only able to get two
USRP2s
to talk to each other. I can’t remember if I was able to get it to
decode
packets from a chipset, that was a year ago…
I do remember that sometime ago, there was further discussion on getting
the
spreading waveform correct since it was not matching the 802.11 roll off
specs. My first guess is to check the match filter being used (if you
can
capture the chipset’s waveform).
I have looked up the forum and everybody seem to stuck with the same
problem. Is there any work around to solve this problem?
From the forum discussion, it seems that one of the issues is the preamble.
Any idea how to make synchronize the receiver so that it can receive the
packets from USRP2 transmitter using bbn code.
I struggled with this for quite a while. I never understood exactly
where a
standard card was not able to decode it. Large frequency offset maybe?
I
never got a single packet through.
They definitely claim that a standard NIC can decode the packets, but I
never personally got around to trying it. The code seemed pretty clean,
and
I was able to use it to generate proper packet signatures… so the
modulation is definitely correct.
Were you able to communicate between two USRP2s using bbn 80211
usrp2_version code?
I am not able to receive packets using USRP2 receiver even when other
USRP2
is transmitting. Can you please let me know if there are any changes
required to be made in the usrp2_version code or any specific command
line
parameters to make this work (i.e. to receive 80211b packets with USRP2
with
another USRP2 transmitting).
Currently, I can only receive beacons from nearby access points using
USRP2.
Any input on this issue is appreciated.
Thanks,
Smith
Colby B.-2 wrote:
spreading waveform correct since it was not matching the 802.11 roll off
Thanks for the help, Doug.
I struggled with this for quite a while. I never understood exactly
and
I have closely been monitoring cgran website. However, every project
seems
to be focusing on how well one can use USRP1 or USRP2 as 80211b
receiver.
But my goal is to communicate between two USRPs (whether USRP1s or
USRP2s)
using bbn 80211b code.
From the previous discussions on this forum, it seems that quite a few
people were able to communicate and decode packets correctly using two
USRP2s and usrp2_version bbn 80211b code. I am trying to know whether
the
usrp2_version code needs any modification or specific command line
arguments.
They had pretty good luck at receiving 802.11b transmissions on USRP1 by
putting the despreading in the FPGA. No transmit code though from what
I
remember.
I do not remember specifically what I used at the command line to get
the
two USRP2s to talk to each other. I know I had it working for 1 and 2
Mbps.
I think something must be messed up with the spreading sequence. George,
wasn’t there a discussion on that sometime ago? I remember there were
plots
being exchanged on the mail list.
It was on a project I worked on a year ago so its a little foggy.
Sorta random, the guy who wrote a lot of the SPAN code ended up in the
same
lab I’m in now.
USRP2s and usrp2_version bbn 80211b code. I am trying to know whether the
usrp2_version code needs any modification or specific command line
arguments.
No problem! Maybe check the date/time of a post to the board in which
someone reported success and try to grab a version from SVN relevant to
that
timestamp. Maybe something changed in between breaking something. I
have
two USRP2s hooked up, I can try the code out myself tomorrow.
Were you able to test the usrp2_version code with two USRP2s?
Let me know if you were able to successfully transmit 80211b packets from
one USRP2 to another.
were you able to build the usrp2 branch successfully with the newest
version
of GNU Radio and Ubuntu? I am failing with a lot of errors with the
newest
version of git and Ubuntu 10.04
In file included from bbn_tap.h:39,
from bbn.cc:3840:
/usr/local/include/gnuradio/omnithread.h:139:2: error: #error “No
implementation header file”
/usr/local/include/gnuradio/omnithread.h:154:2: error: #error
“Implementation header file incomplete”
In file included from bbn_tap.h:39,
from bbn.cc:3840:
/usr/local/include/gnuradio/omnithread.h:208: error: ISO C++ forbids
declaration of ‘OMNI_MUTEX_IMPLEMENTATION’ with no type
/usr/local/include/gnuradio/omnithread.h:209: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h:209: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h: In member function ‘void
omni_mutex::lock()’:
/usr/local/include/gnuradio/omnithread.h:189: error:
‘OMNI_MUTEX_LOCK_IMPLEMENTATION’ was not declared in this scope
/usr/local/include/gnuradio/omnithread.h:189: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h: In member function ‘void
omni_mutex::unlock()’:
/usr/local/include/gnuradio/omnithread.h:190: error:
‘OMNI_MUTEX_UNLOCK_IMPLEMENTATION’ was not declared in this scope
/usr/local/include/gnuradio/omnithread.h:190: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h: In member function ‘int
omni_mutex::trylock()’:
/usr/local/include/gnuradio/omnithread.h:191: error:
‘OMNI_MUTEX_TRYLOCK_IMPLEMENTATION’ was not declared in this scope
/usr/local/include/gnuradio/omnithread.h:191: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h: At global scope:
/usr/local/include/gnuradio/omnithread.h:288: error: ISO C++ forbids
declaration of ‘OMNI_CONDITION_IMPLEMENTATION’ with no type
/usr/local/include/gnuradio/omnithread.h:289: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h:289: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h:323: error: ISO C++ forbids
declaration of ‘OMNI_SEMAPHORE_IMPLEMENTATION’ with no type
/usr/local/include/gnuradio/omnithread.h:324: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h:324: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h:613: error: ISO C++ forbids
declaration of ‘OMNI_THREAD_IMPLEMENTATION’ with no type
/usr/local/include/gnuradio/omnithread.h:614: error: expected ‘;’ before
‘}’
token
/usr/local/include/gnuradio/omnithread.h:614: error: expected ‘;’ before
‘}’
token
In file included from bbn.cc:3844:
bbn_plcp80211_bb.h:62: warning: ‘typedef’ was ignored in this
declaration
George,
The latest versions of GNUradio no longer use omnithreads - I believe
everything the used them has switched over to using boost threads. I’m
not sure what portions of the BBN code use threads (I suspect there is a
watcher thread checking the message queue from the PLCP for received
packets), but they probably need to be changed to either use
boost::threads directly, or if gruel supplies a wrapper, use that.
Hopefully the required changes are minimal.
If I get a chance next week, I can take a look and see what it takes
to build on my machine.
Doug
I am using Ubuntu 8.04 and GNU Radio version is 3.3git-602-gfcf9efa7. I
do
not know about Ubuntu but a lot of changes were made to git after I
checked
out this version. If you have older versions of git then it may help you
to
build usrp2 bbn code.
gnychis wrote:
implementation header file"
‘}’
/usr/local/include/gnuradio/omnithread.h:190: error:
token
declaration of ‘OMNI_SEMAPHORE_IMPLEMENTATION’ with no type
token
Did you manage to receive with USRP2? I’m kinda stuck with the same
problem
(Tx/Rx with 2 USRP2s). ‘bbn_80211b_rx’ does not receive what I’m
transmitting with ‘bbn_80211b_tx’.
No, I have not been able to receive from USRP2 as a transmitter but I
have
been able to successfully receive packets from a nearby access point.
Thanks,
Smith
Rahman Doost wrote:
to
Were you able to test the usrp2_version code with two USRP2s?
version of git and Ubuntu 10.04
declaration of ‘OMNI_MUTEX_IMPLEMENTATION’ with no type
/usr/local/include/gnuradio/omnithread.h:189: error:
before
/usr/local/include/gnuradio/omnithread.h: At global scope:
/usr/local/include/gnuradio/omnithread.h:323: error: ISO C++ forbids
declaration of ‘OMNI_THREAD_IMPLEMENTATION’ with no type
declaration http://old.nabble.com/BBN-80211b-Transmitter-with-GNURadio-3.2.2-and-USRP1-tp28623863p28639621.html
Discuss-gnuradio mailing list [email protected] Discuss-gnuradio Info Page
I am using the command ./bbn_80211b_rx.py -d 8 -f 2.412G -b to catch
802.11
1 Mbps packets from access points. However, the result is always BAD
CRC. I
know that some people on this list did it successfully.
I am using the bbn_8021/branches/usrp2_version and working with a USRP2.