Ofdm phy (802.11)?

Hi all,

Is the OFDM implementation (see below) compliant to that of 802.11 ?

http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm2/gnuradio-examples/python/ofdm

I am looking for source code which implements 802.11a scrambler,
convolution encoder etc … I couldn’t find it in the above link. Can
you please point me to the code if the above implementation has it ?
In general, is there any open source implementation of the 802.11 OFDM
PHY ?

Thank you,

Shravan

Shravan Rayanchu wrote:

Is the OFDM implementation (see below) compliant to that of 802.11 ?

http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm2/gnuradio-examples/python/ofdm

No. This is a work in progress implementation of a generic,
parameterized OFDM modulator/demodulator. You’d need to wrap it (once
it is finished) in a number of other blocks to implement an 802.11 PHY.

Shravan

Shravan,

The OFDM code we’re working on here is not specific to any standard. It
is a
general modulator and demodulator for people to work with (later, once
we
get some things worked out) and implement their own specific needs.

And just to point it out again, you’re going to have a very difficult
time
doing 802.11g in the current state with the bandwidth limitations. If
you
are just looking to implement the way 802.11g is done, but not for use
with
an actual commercial system, then great; hopefully, this OFDM code will
give
you a good place to start.

Tom

On an semi-related note, which of the RF front end cards will work
with the OFDM waveform? From my understanding, it has a pretty high
peak-to-average ratio which might cause some problems with some
transmitters.

How are the floating point numbers calculated on the PC going to be
normalized into proper scale fixed-point numbers the FPGA works with?

This is very interesting to me, so I guess I am just a little curious
how this is going to be done.

Thanks,
Brian

transmitters.
An excellent question (which is academic speak for ‘I don’t have an
answer’).

Hopefully we will know next week. You are right in the high
peak-to-average
power, but we have to work a few more issues out before we will know how
it
works over the air and through different daughterboards.

How are the floating point numbers calculated on the PC going to be
normalized into proper scale fixed-point numbers the FPGA works with?

Our biggest concern will probably be getting the signal to work on the
RFX
boards, which (I think) all have the same output amplifier stage. What
we do
with all of the modulators is scale it from +1 to -1 (even my QAM
modulators
are normalized amplitudes), then digitally amplify it to ±16384. When
you
look at the output power of the transmitter, at full power it only
starts to
go non-linear and you can start to see the third-order product (Matt’s
done
a really good job with these guys). At around ±15000, I don’t really
see
anything, so that’s about the arbitrary max I use.

With the OFDM work, we still send modulate the maximum value to be 1
(for
example, we send a “known symbol” at the start of a frame of all 1’s),
then
we will digitally amplify it, so there shouldn’t be a difference, and we
shouldn’t see any problems with the high peak-to-average ratio. I say
shouldn’t because I’m an experimentalist and don’t like to make concrete
claims until I see it.

Is that what you’re looking for?

Tom

On 2/16/07, Tom R. [email protected] wrote:

Our biggest concern will probably be getting the signal to work on the RFX
boards, which (I think) all have the same output amplifier stage. What we do
with all of the modulators is scale it from +1 to -1 (even my QAM modulators
are normalized amplitudes), then digitally amplify it to ±16384. When you
look at the output power of the transmitter, at full power it only starts to
go non-linear and you can start to see the third-order product (Matt’s done
a really good job with these guys). At around ±15000, I don’t really see
anything, so that’s about the arbitrary max I use.

Ah, so you really want to go full scale with this - neat. I am
worried about what type of transients you could see if you do some big
impulse signal with the interpolation that happens when transmitting.
I suppose your 1.0 normalized signal would really be the number of
active frequency bins since you could possibly hit a peak at each one
of those frequencies? Does that sound right?

On the scale values - a complex signal going down to the USRP is
8-bits real / 8-bits imaginary if I remember correctly. That should
give +/-127 for those values.

Assuming a real-only signal, the AD9862 has a dual 14-bit DAC which
gives +/-8191 values. This probably doesn’t mean anything since it
goes through interpolation, but the whole normalization of this stuff
would seem to get quite hairy after a while.

For a fixed-point model, maybe it would be worth while to choose a Q12
or Q15 number to be the standard normalized value - therefore any
bit-slicing done in the FPGA can be reliably done without the fear of
a loss of data?

With the OFDM work, we still send modulate the maximum value to be 1 (for
example, we send a “known symbol” at the start of a frame of all 1’s), then
we will digitally amplify it, so there shouldn’t be a difference, and we
shouldn’t see any problems with the high peak-to-average ratio. I say
shouldn’t because I’m an experimentalist and don’t like to make concrete
claims until I see it.

You just use the one symbol for a preamble of sorts? Is that reliable
enough to not false acquire enough to get data through?

Is that what you’re looking for?

Very much so. Thank you very much!

Brian

On Fri, Feb 16, 2007 at 09:56:39AM -0500, Brian P. wrote:

a really good job with these guys). At around ±15000, I don’t really see
8-bits real / 8-bits imaginary if I remember correctly. That should
give +/-127 for those values.

We almost always use 16-bit I & Q across the USB.

For a fixed-point model, maybe it would be worth while to choose a Q12
or Q15 number to be the standard normalized value - therefore any
bit-slicing done in the FPGA can be reliably done without the fear of
a loss of data?

Of course you can build an arbitrary width data path in the FPGA…

Eric