Is it possible to do 11ac on SDR? On Wed, Oct 15, 2014 at 10:07 PM, Bastian Bloessl <[email protected]> wrote: > Hi, > > On 10/10/2014 06:20 PM, Zhang, Jiayi wrote: >> >> Dear Marcus and Bloessl, >> >> Thanks for the reply. I also notice the fully functional gr-ieee802-11 >> package provide by Bloessl. Previously I thought it's only PHY, but as >> Marcus mentioned it also include MAC. It seems to me in the >> gr-ieee802-11-master package, the MAC does not run csma. I also find the >> gr-ieee802-11-csma package, which is smaller than the master package but >> indicate "csma" in name and one of examples. > > > Sorry, I don't get what you mean with smaller. Are you talking about the > file size of the sources? > All branches add / parse the MAC header as defined in the standard. So the > frame format is OK on all branches. The 'csma' branch implements channel > access for broadcast frames. > >> After checking the Readme >> and other pulications from WIME project, I cannot find detail >> description regarding the MAC and CSMA function for the package. > > > It's the one at the top > http://www.ccs-labs.org/bib/bloessl2014timings/ > >> >> 1. Does the csma package should be used with the master package? > > > No. 'csma' is the name of a branch. You would checkout and use that branch. > >> 2. Does the csma package support multiple nodes in an ad-hoc network? > > > The CSMA implementation is for broadcast frames only. So depends on what you > want to do. > >> >> Return to Marcus's advice, do you mean that to realize the MAC (CSMA), >> we still need implement FPGA (not the one in USRP?) to handle it in >> hardware, no matter we use the software lib, e.g. GRU Radio or Click >> Module Router? > > > To support CSMA functionality you will have to change the FPGA otherwise you > will not be able to meet the timing constraints of 802.11. For the broadcast > case you only need some small changes. > If you want to support ACKS and RTS/CTS you need a lot of functionality on > the FPGA. In my opinion this will not happen on a N210, but AFAIK Ettus has > a 802.11 implementation for RFNoC (i.e. for the FPGA) which most likely > meets all timing constraints. > > Best, > Bastian > >> >> Many thanks for your help again! >> >> Best regards, >> Jiayi >> >> >> On Thu, Oct 9, 2014 at 4:05 PM, Marcus Müller <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Jiayi, >> >> :) gr-ieee802-11 is, as far as I know, the most comprehensive, >> functional implementation so far. It *can* talk to consumer cards -- >> but >> of course, that's not because it has a complete MAC implementation. >> Actually, doing a really standards-compliant IEEE802.11agp MAC can't >> really be done in host software alone -- the gigabit ethernet >> interface >> alone just has too much latency, and you'll have to be really fast >> when >> detecting ACK's, calculating checksums and sending out the reply. I >> doubt you can implement a fully working IEEE802.11 MAC in software >> alone >> without touching the FPGA. >> >> Here's the official source code: >> https://github.com/bastibl/gr-ieee802-11 has the source code, btw. >> >> >> Greetings, >> Marcus >> On 09.10.2014 21:47, Zhang, Jiayi wrote: >> > Dear Marcus and all, >> > >> > Many thanks for the advice regarding the Hydra and ORBIT project. >> > >> > Actually I'm looking for the open-source 802.11 PHY&MAC packages >> which are >> > compatible with Recent GNU Radio and USRP N210/X310. >> > >> > I've searched from internet and got some findings listed below: >> > 1) Hydra PHY & MAC from University of Texas at Austin [1] >> > 2) FTW IEEE802.11a/g/p OFDM Frame Encoder [2] >> > 3) UWICORE m-HOP 802.11 MAC for USRP based on the FTW PHY [3] >> > http://www.uwicore.umh.es/mhop-software.html >> > *** All (1-3) only compatible with gnuradio-3.2.2 which was too >> many years >> > ago. >> > >> > 4) WIME IEEE 802.11a/g/p Transceiver for GNU Radio v3.7 [3] >> > http://www.ccs-labs.org/software/gr-ieee802-11/ >> > *** This is a most recent package for gnuradio 3.7, but is PHY >> only. Are >> > there any MAC package which compatible with this WIME PHY? >> > >> > 5) ORBIT Project [5] >> > *** This is a huge project which can be studied. Are there any >> project >> > provide both 802.11 MAC & PHY like Hydrd did before? >> > >> > Best regards, >> > Jiayi >> > >> > [1] K. Mandke, Soon-Hyeok Choi, Gibeom Kim, R. Grant, R. Daniels, >> Wonsoo >> > Kim, R. W. Heath, Jr., and S. Nettles, “Early Results on Hydra: A >> Flexible >> > MAC/PHY Multihop Testbed,” Proc. of IEEE Vehicular Tech. Conf. , >> pp. >> > 1896-1900, Dublin, Ireland, April 23 – 25, 2007. >> > [2] http://www.cgran.org/wiki/ftw80211ofdmtx >> > [3] J.R. Gutierrez-Agullo, B. Coll-Perales and J. Gozalvez, "An >> IEEE 802.11 >> > MAC Software Defined Radio Implementation for Experimental Wireless >> > Communications and Networking Research", Proceedings of the 2010 >> IFIP/IEEE >> > Wireless Days (WD'10), 20-22 October 2010, Venice (Italy). >> > [4] Bastian Bloessl, Michele Segata, Christoph Sommer and Falko >> Dressler, >> > "An IEEE 802.11a/g/p OFDM Receiver for GNU Radio," Proceedings of >> ACM >> > SIGCOMM 2013, 2nd ACM SIGCOMM Workshop of Software Radio >> Implementation >> > Forum (SRIF 2013), Hong Kong, China, August 2013, pp. 9-16. >> > [5] http://www.orbit-lab.org/ >> > >> > >> > On Thu, Oct 9, 2014 at 1:02 PM, Marcus Müller >> <[email protected] <mailto:[email protected]>> >> >> > wrote: >> > >> >> Yes. Nothing in GNU Radio or UHD (the USRP driver framework) is >> >> distribution-specific, so transition from Ubuntu to Fedora >> should not be >> >> a problem >> >> >> >> Good luck with finding a "new version" of Hydra; I didn't find any >> >> publication after 2009 on a quick first glance on google >> scholar[1]. And >> >> I couldn't find the source code anywhere. Honestly: If you don't >> find >> >> anything that proves otherwise, I'd presume that Hydra is kind >> of dead >> >> [2]. Please prove me wrong on this! >> >> >> >> There is the ORBIT lab that has come up with a rather >> comprehensive >> >> infrastructure for wireless testbeds, so you might want to look >> at that[3]. >> >> >> >> Greetings, >> >> Marcus >> >> >> >> [1] >> >> >> >> >> >> http://scholar.google.de/scholar?q=%22Robert+W.+Heath%22+hydra&hl=en&as_sdt=0%2C5&as_ylo=2010&as_yhi= >> >> [2] https://www.youtube.com/watch?v=r0yXqU-w9U0 >> >> [3] http://www.orbit-lab.org/ >> >> On 09.10.2014 16:41, Zhang, Jiayi wrote: >> >>> Hi Marcus, >> >>> >> >>> Another question is that, if we development the software with >> GNU Radio >> >> and >> >>> USRP in Ubuntu, is it easy to transfer to Fedora? >> >> Thanks for your reply. I think the best way to us is to find the >> new >> >> version of Hydra package which is based on the recent GNU Radio >> version >> >> working with current USRP produces. >> >> >> >>> Many thanks! >> >>> >> >>> Regards, >> >>> Jiayi >> >>> >> >>> On Wed, Oct 8, 2014 at 11:11 AM, Marcus Müller >> <[email protected] <mailto:[email protected]> >> >> >>> >> >>> wrote: >> >>> >> >>>> Hello Jiayi, >> >>>> >> >>>> 3.2.2 is *very* ancient. In fact, it's older than my >> involvement with >> >> GNU >> >>>> Radio, and I think it will be very hard to find someone how's >> still >> >> using >> >>>> it, so asking for experience, I'm afraid, is not going to >> yield a lot of >> >>>> responses in 2014. >> >>>> Therefore, it will be nearly impossible to recreate an >> environment with >> >>>> all the GNU Radio dependencies that match the needs of GNU >> Radio 3.2.2. >> >>>> >> >>>> I'm not familiar with Hydra itself; but if it uses GR 3.2.2 >> you won't be >> >>>> able to use it with modern USRPs, you won't have much fun >> developing new >> >>>> applications for it, and in total it might be wise to look if >> you can >> >>>> either find a suitable substitute or port it to a modern GNU >> Radio. >> >>>> >> >>>> However, I'm optimistic that someone else here has used Hydra, >> and maybe >> >>>> he has some more specific hints than I do. >> >>>> >> >>>> Greetings, >> >>>> Marcus >> >>>> >> >>>> >> >>>> On 08.10.2014 16:50, Zhang, Jiayi wrote: >> >>>> >> >>>> Dear all, >> >>>> >> >>>> I'm a beginner of GNURadio but I'm familiar with some basis of >> Linux >> >> when I >> >>>> use C++ & IT++. Currently I'm trying to test the Hydra-0.4 >> package for >> >>>> evaluation under the last ubuntu ver 14.04.1 32bit. During the >> >> installation >> >>>> of gnuradio-3.2.2, there is an error which I cannot find the >> solution on >> >>>> internet. >> >>>> >> >>>> gnuradio-3.2.2$ ./bootstrap && ./configure --prefix=$GR >> >>>> … >> >>>> checking for boost >= 1.35... yes >> >>>> checking whether the boost::thread includes are available... yes >> >>>> configure: error: Could not link against libboost_thread! >> >>>> >> >>>> ‘libboost-all-dev’ has already installed, including >> >> ‘libboost-thread-dev’, >> >>>> I tried both version 1.54 and 1.55 of libboost. I've also >> searched the >> >>>> error message in Google, even after I installed the >> 'build-essential' >> >>>> package, the error remains the same. >> >>>> >> >>>> I will be much appreciated if any of you have such an >> experience and >> >> would >> >>>> feedback some solutions. >> >>>> >> >>>> Regards, >> >>>> Jiayi (Vincent) > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
