George- >> What I got from your paper is that the matched filter approach for >> fast packet detection would not work in an OFDM setting. What about >> fast ACK generation? Would it require an IFFT implementation on the >> USRP? Would it help much? > > It's a good question, and something I haven't explored, and I'm not much of > a DSP guy. So, I'll punt the question to everyone else who has more DSP > experience than me. Both are all about signal detection, both the > fast-packet detection and fast ACK generation. So what you want to do is > first detect the preamble in the USRP without decoding (because it's complex > and takes long). So, we propose using a matched filter on the USRP to > detect the packet preamble. In 802.11ab, the preamble was done with BPSK > (even if the data is sent using OFDM in 802.11a). With 802.11g, it can be a > full OFDM preamble. So, with a full OFDM preamble, you can still detect it > with a matched filter, but I'm a little unclear about how to generate the > coefficients. You essentially are detecting in the time domain with the > matched filter. It might require an IFFT on the USRP... anyone? Dan? :) > >> >> > This all said... I really think we need a better interface to reduce >> > latency. Some platforms take the: run on the board approach, such as >> WARP >> > which puts the MAC on a core on the board. Good luck conjuring up >> $10-15k >> > just for a single WARP board plus frontends though :P >> >> Is there anything that would prevent GNUradio developers to push the >> MAC layer functionality on the USRP? >> > The USRP and USRP2, from what I understand, are both tight for space in the > FPGA. I'm pretty confident you can't fit an OFDM implementation on the > USRP. There are free multipliers and space on the USRP2, but I think it > would also be tight, leaving you with not much room for the MAC. Then, > you'd be building the MAC in verilog which sucks. Most people who want to > do MAC development have CS backgrounds, not EE backgrounds, form which > Verilog is black magic ;)
To cover a wide range of MAC layer standards at fast RF data rates, some type of processing element is required in the front-end data flow; i.e. before the x86 server. One way is an embedded processor core in the FPGA that runs C code and has a library of useful stuff (matched filtering, iFFT, etc) that look like basic function calls, but are implemented as parallel structures in FPGA logic, outside the processing core. C/C++ code calls the function, waits some number of clock ticks or gets a callback, and it's done (well, more or less). This approach both abstracts the FPGA logic to the C/C++ programmer and gives the FPGA more flexibility (i.e. reduces the number of applications where people need to reprogram the FPGA). I would guess that between Matt and NI guys they're planning (if not already started) on developing a more powerful version of the USRP2, with larger FPGA. My understanding is that Matt originally chose Spartan-3 because it was Xilinx's highest performance FPGA (with reasonable chip cost) that would still allow developers to use WebPACK. Evidently he had to move to S-3 2000 for more capacity, although WebPACK only supports up to S-3 1500. That means that GNU radio users who want to modify the FPGA already need the "paid for" Xilinx ISE tools... and I can tell you from experience that Xilinx holds its tools in high regard and charges accordingly. For these reasons -- not to mention competition from people like Lyrtech and Sora, maybe something NI guys pay more attention to than Matt -- a USRP2 with Virtex 5 or 6 starts to make sense. -Jeff _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio