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 [EMAIL PROTECTED] Urbana, IL * (217) 278-3933 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio