Re: [Discuss-gnuradio] Physical layer for packet-based communication

[David Young]

Rahul,

Sorry for the delay in responding.  Answering your questions in
reverse order:

On Thu, Feb 10, 2005 at 04:37:12PM -0500, Rahul Dhar wrote:
> Given 802.11's tight timing requirements (discussed
> briefly earlier in this thread), can the CPU schedule and send packets
> fast enough?

I think it depends which MAC you use, how many packets/sec, how much CPU
overhead you can tolerate, etc.  I don't think you can send an 802.11
ACK packet fast enough if the CPU has to get involved---but then again,
maybe your preferred MAC doesn't use ACK packets.

> Do you know how to access those parameters?  As far as I know, most of
> the useful ones are stuck in firmware, and vendors don't want to tell us
> how to play with the firmware.  Otherwise, this sounds like the best
> solution, especially if I can write my own firmware (or edit the
> existing one).

802.11 makers are moving away from microcontrollers.  Real-time MAC
functions are implemented by silicon state machines.  The rest of the
firmware's intelligence has moved into the device driver.  The host
computer is responsible for setting up the modem, synthesizer, and
transceiver.

I believe the best way to find out what parameters you can tweak is
to look at some examples sources.  Take a look at the driver I wrote
for ADMtek 802.11b chips.  You can browse the sources on-line at
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/.  Check out these files:

        dev/ic/atwreg.h         /* MAC register definitions */
        dev/ic/atwvar.h         /* driver data structures */
        dev/ic/atw.c            /* driver logic */
        dev/ic/rf3000reg.h      /* modem register definitions */
        dev/ic/si4136reg.h      /* synthesizer register definitions */

You should be able to discern from rf3000reg.h which registers control
the transmit power and the receiver's AGC loop.  (If not, please tell me
so that I can fix the in-line documentation!)  si4136reg.h defines the
registers for programming the IF/RF synthesizer.  atw.c shows how I write
registers on the synth and baseband---start at the subroutine atw_tune.

For another example, there is the new Realtek driver, which is used with
three or four different transceiver/synthesizer chips.  My driver only
supports two:

        dev/ic/rtw.c
        dev/ic/rtwphy.c         /* PHY control logic */
        dev/ic/rtwphy.h
        dev/ic/rtwphyio.c       /* PHY I/O */
        dev/ic/rtwphyio.h
        dev/ic/rtwreg.h         /* MAC / modem registers */
        dev/ic/rtwvar.h
        dev/ic/sa2400reg.h      /* Philips SA2400A transceiver/synthesizer
                                 * registers
                                 */
        dev/ic/max2820reg.h     /* Maxim MAX2820 transceiver/synthesizer regs */

The Maxim MAX2820 datasheet is available for free download.  I think
you can find the SA2400 datasheet on the web without looking very hard.

> 
> >         3 Use an existing 802.11 PHY, but replace the MAC
> >           with a microcontroller [*].  Design a PHY abstraction.
> >           Implement, in C (say), the PHY abstraction for the PHY of your
> >           choice [**].  Program your MAC in C.
> 
> This is actually what I'd like to do for GNU Radio, but I'm not sure
> where to start, nor am I sure if it's even feasible.  It has been noted
> that PHY's tend to be too diverse to make a meaningful abstraction very
> difficult.

I may not have understand what you mean, but I don't think 802.11 PHYs
are too diverse to abstract.  Look at how I have abstracted the PHY in
the Realtek driver.  It is not a great abstraction, but it is a start.
Essentially, I treat the PHY as an "object" with methods Initialize,
Set Powersaving State, Set Transmit Power, and Set Channel.  I create
the PHY object with callbacks for doing serial I/O (transceivers and
such are usually located on some serial bus) and for activating a MAC
calibration mode.

Dave

-- 
David Young             OJC Technologies
address@hidden      Urbana, IL * (217) 278-3933