Re: [Discuss-gnuradio] implementing state flow

[Jim Hanlon]

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