IEEE802.11a/g/p OFDM Encoder for USRP2 released on CGRAN

Hello Everyone,

we are glad to announce that our IEEE802.11a/g/p OFDM frame encoder has
passed the last round of testing and is now finally released on CGRAN
(under
GPLv3):

https://www.cgran.org/wiki/ftw80211ofdmtx

What does the encoder do? In a nutshell: take a MAC payload, slap a
static
header on it and then do ALL the processing steps that it takes to
generate
a standard-compliant IEEE802.11a/g/p OFDM frame. That includes things
like:
CRC32 calculation, generating the bits for the signal-symbol,
scrambling,
convolutional encoding, forcing the tailbits, symbol-mapping,
interleaving,
pilot symbol insertion, remapping the carriers, iFFT, cyclic prefix
insertion, training-sequence insertion, normalization, etc…

The encoder produces the digital complex baseband signal for the frame
and
sends it the USRP2 sink (using the appropriate interpolation factor).
Unfortunately, due to USB2 bandwidth constraints this method cannot be
used
with the USRP Version 1.

The result: the frame is successfully decoded by any ordinary WiFi
chipset
that supports either 11a, 11g or 11p.

!!It is important which USRP2 firmware-version is used - for details see
the
lengthy README included in the trunk!!

In the release included is also the MATLAB encoder we wrote in the
process
of development. It facilitated debugging of the GNURadio encoder as it
can
be used to generate a reference frame. The MATLAB encoder itself has
been
checked to be 100% consistent with the ANNEX G reference frame in
802.11-2007. Funny enough - turned out that the reference frame in the
official STANDARD document STILL (dated 2007) contains a false CRC32 -
so
much about taking things for granted :slight_smile:

Our original motivation to implement an OFDM-encoder in GNURadio was
that
there are no chipsets available for 11p. This standard is not very
well
known as it is still in draft status - but it is likely that this
amendment
will become the industry-standard for vehicular car-to-car and
car-to-infrastructure communication applications in the future. And it
turned out that the 11p physical layer only differs marginally from 11a
and
11g - the OFDM-symbol time is doubled.

This is our first contribution and we would like to say a big Thanks! to
all
the other enthusiasts that supported us by giving helpful hints here on
this
mailing-list. The main credits for this work go to Andrea Costantini, a
young master-thesis student from the University of Salento, Italy. He
spent
countless hours on this project an was supported by Paul Fuxjaeger,
Danilo
Valerio, Paolo Castiglione and last but not least Giammarco Zacheo (the
only
one with decent coding skillz in our group :wink:

Originally, this release was planned as a small Christmas present to the
GNURadio community for December 2009 but last-minute bug-fixes delayed
the
process.

We would like to collaborate with other groups that are interested in
WiFi
standards and their implementation using SDR tools. Currently, we are
concentrating on the receiver counterpart, the main problems seem to be
automatic gain control and carrier sensing. Also of special interest for
us
is the subject of low-latency implementation - to finally implement to a
fully fledged WiFi OFDM transceiver in GNURadio…


Cheers!
The SDR-team at FTW

PS: In case of questions regarding the code please get in contact with
either Paul ([email protected]), Danilo ([email protected]) or Paolo
([email protected]) as Andrea has left our team after he completed his
thesis (good luck down there!)

On Mon, Jan 18, 2010 at 02:23, Paul Fuxjäger [email protected] wrote:

we are glad to announce that our IEEE802.11a/g/p OFDM frame encoder has
passed the last round of testing and is now finally released on CGRAN (under
GPLv3):

https://www.cgran.org/wiki/ftw80211ofdmtx

Excellent work, thanks for contributing this effort!

Johnathan C.
Corgan Enterprises LLC

Congratulations!! Thanks a lot for your contribute!

Recently I’m also interested in 802.11p. I’v very glad to see this. :slight_smile:

Lin

2010/1/18 Paul Fuxjäger [email protected]

Am 25.01.10 04:20 schrieb “Yanjun Wu” unter [email protected]:

Do you use any daughterboard sold by Ettus?
I’m also interested in 802.11p, but I’m not sure whether USRP2 plug XCVR2450
are appropriate for 802.11p 5.9GHz test.

Yes, we are using the XCVR2450 in the 5.9GHz band, so far without any
big
problems. We do seem to have a little issue, that was discovered just
yesterday:

Using a second USRP2 to record the received baseband signal we see that
each
sent frame is directly followed by a delayed and attenuated (around
25dB)
copy of it. This “artifact” is definitely not contained in the digital
baseband data that we generate on the transmitter-side, so it must be
introduced by the USRP2/Daughterboard system. Also these copies are not
seen
when looking at the signals from another source - so they are not
measurement artifacts either. I currently busy trying to find out
more…

Cheers
paul

Do you use any daughterboard sold by Ettus?
I’m also interested in 802.11p, but I’m not sure whether USRP2 plug
XCVR2450
are appropriate for 802.11p 5.9GHz test.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs