usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Re: [USRP-users] can N200 or N210 support realtime 802.11

AP
Andre Puschmann
Mon, Oct 3, 2011 4:00 PM

Hi,

On 10/03/2011 04:57 PM, Kai Zeng wrote:

Thank you for the reply. The new N200 series use Gigabit Ethernet
cable to connect the board and the host, so will it decrease the delay
to satisfy the precision in tens of microsecond? I have taken a look
at the paper. It seems the delay between the GNU radio in the
userspace and FPGA is large. Does it mean, even with the Gigabit
Ethernet port, the MAC delay is hardly to satisfy?

Unfortuntely, yes. In terms of host<->RF front end delay, the USRP2 is
not really an improvement over the USRP1. The E100 should perform better
but the GPP performance is very bad. Exploiting the DSP and/or FPGA
and/or the vector extensions of the ARM could help here. But I am not
aware of any actual implementation though. Anybody else?

Regards,
Andre

Hi, On 10/03/2011 04:57 PM, Kai Zeng wrote: > Thank you for the reply. The new N200 series use Gigabit Ethernet > cable to connect the board and the host, so will it decrease the delay > to satisfy the precision in tens of microsecond? I have taken a look > at the paper. It seems the delay between the GNU radio in the > userspace and FPGA is large. Does it mean, even with the Gigabit > Ethernet port, the MAC delay is hardly to satisfy? Unfortuntely, yes. In terms of host<->RF front end delay, the USRP2 is not really an improvement over the USRP1. The E100 should perform better but the GPP performance is very bad. Exploiting the DSP and/or FPGA and/or the vector extensions of the ARM could help here. But I am not aware of any actual implementation though. Anybody else? Regards, Andre
K
kfleming@csail.mit.edu
Mon, Oct 3, 2011 4:15 PM

We use the 8b/10b serdes port to do 80211.g on another FPGA (not the
small FPGA on the USRP) using the USRP as a frontend.

Documentation here:

airblue.csail.mit.edu

Doing 80211.g in software is quite difficult.  The SORA project
managed to do it, but it took some serious hacking and building custom
hardware.

-Elliott

Quoting "Andre Puschmann" andre.puschmann@tu-ilmenau.de:

Hi,

On 10/03/2011 04:57 PM, Kai Zeng wrote:

Thank you for the reply. The new N200 series use Gigabit Ethernet
cable to connect the board and the host, so will it decrease the delay
to satisfy the precision in tens of microsecond? I have taken a look
at the paper. It seems the delay between the GNU radio in the
userspace and FPGA is large. Does it mean, even with the Gigabit
Ethernet port, the MAC delay is hardly to satisfy?

Unfortuntely, yes. In terms of host<->RF front end delay, the USRP2
is not really an improvement over the USRP1. The E100 should perform
better but the GPP performance is very bad. Exploiting the DSP
and/or FPGA and/or the vector extensions of the ARM could help here.
But I am not aware of any actual implementation though. Anybody else?

Regards,
Andre


USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

We use the 8b/10b serdes port to do 80211.g on another FPGA (not the small FPGA on the USRP) using the USRP as a frontend. Documentation here: airblue.csail.mit.edu Doing 80211.g in software is quite difficult. The SORA project managed to do it, but it took some serious hacking and building custom hardware. -Elliott Quoting "Andre Puschmann" <andre.puschmann@tu-ilmenau.de>: > Hi, > > On 10/03/2011 04:57 PM, Kai Zeng wrote: >> Thank you for the reply. The new N200 series use Gigabit Ethernet >> cable to connect the board and the host, so will it decrease the delay >> to satisfy the precision in tens of microsecond? I have taken a look >> at the paper. It seems the delay between the GNU radio in the >> userspace and FPGA is large. Does it mean, even with the Gigabit >> Ethernet port, the MAC delay is hardly to satisfy? > > Unfortuntely, yes. In terms of host<->RF front end delay, the USRP2 > is not really an improvement over the USRP1. The E100 should perform > better but the GPP performance is very bad. Exploiting the DSP > and/or FPGA and/or the vector extensions of the ARM could help here. > But I am not aware of any actual implementation though. Anybody else? > > Regards, > Andre > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >