I think the issue of programming MAC layer interaction comes down to one of timing. I am still investigating gnuradio-to-USRP timings, but I am looking at simple integer writes to the daughterboard, driven from a python program loop, and seeing 1 to 5 per millisecond on the logic analyzer. Now, my controller machine is a bit slow, and I regularly see USB underruns and overruns during tx and rx tests. But say a fast CPU could effectively service the USB link (the presumed bottleneck). What then? 10 integers per mS? 20? And how would these simple integer writes translate to service times for successive MAC data units?
I am most interested at the moment in 802.11, which has quite a complex MAC layer, particularly in its "permission-to-send" logic, the Distributed Coordination Function. Interframe timings are multiples of SIFS and slot times (10 and 20uS, respectively). Just on the basis of back-of-the-envelop calculations, combined with my baseline measurements, a Python implementation of 802.11 MAC seems unlikely. Even given a more modern CPU, one that could run MAC logic effectively, I would still be concerned with the stability and repeatability of MAC-associated timing. USB link servicing, turnaround times, etc., would add still more variation. Would a USRP PCIe bus connection improve the situation? Probably, but such a thing does not yet exist. A natural question arises: Could the FPGA on the USRP perform 802.11 MAC logic in a timely and repeatable manner? This is an intriguing possibility. Current program space on the Cyclone chip is limited, but the USRP II could conceivably provide more room to maneuver. Another factor to consider is that the economics of mass production affects the wisdom of using general purpose tools for specific purposes. If a mass-market wireless interface card or router maker were to make their system "open" in some sense, it would behoove one to get in the $20-$50 part and go to town programming it. The actions of Linksys and its WRT54GS router are instructive in this regard: there's quite a lot of activity reprogramming the firmware of this product (see sveasoft.com forums, search on "long fat pipes" for altering SIFS intervals). Jim Hanlon _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
