8-channel receiver

GNU Radio
1

I have a quick theoretical question. Is there any way to construct an
8-channel receiver using 4 USRPS without data going through the host
computer? Basically some kind of way to daisy chain mimo cables (though
I
know this is not possible), or at least get the same benefits you would
receive from daisy chaining mimo cables, without using a switch or
network
connections.

Thank you,
Anisha

2

Clarification: This would be using USRP N210, not USRP1, where I know it
is
possible to have an 8 channel receive or transmit only using a mimo
cable.

3

You can use a gigabit ethernet switch and put all the USRPs on there.
You should be able to make USRPs send data to each other. You will of
course need to do work to get your algorithms into the FPGA.

Matt

4

Thanks Matt!
Do you have any idea for what kind of latency we would expect? Also
would
the data be routed through the host? My Radio, We only have a couple
months
to do this, but we have tried to synchronize USRPs before, so we are
aware
of some of the problems.
Thanks,
Anisha

5

One should remember the extremes involved in syncing all USRP’S which
will
lead to developing a new driver for USRP2.

What about the your APP development time?. Are you interested in
developing
new driver or app ?

6

On 09/28/2012 02:46 PM, Anisha G. wrote:

Thanks Matt!
Do you have any idea for what kind of latency we would expect? Also would

The dominating factor in latency here is the gigabit ethernet, this
tends to be around 100us. Here are a few notes about that:

http://files.ettus.com/uhd_docs/manual/html/transport.html#latency-optimization

the data be routed through the host? My Radio, We only have a couple months

Normally the samples would all go to the host computer that configured
the USRP. It is possible to configure the USRP with one machine but send
the samples to an arbitrary network location:

http://files.ettus.com/uhd_docs/manual/html/usrp2.html#alternative-stream-destination

For that matter, there is nothing wrong with splitting up the USRP
configuration among several computers. It all depends how you plan on
using the data.

to do this, but we have tried to synchronize USRPs before, so we are aware
of some of the problems.

Anything in particular that I could help to clarify?

-josh

7

On 09/29/2012 09:46 AM, Anisha G. wrote:

-Anisha

The reason that shrinking the receive frame size reduces latency is that
the RX DSP chain produces samples at a fixed rate. Therefore, the device
cannot release a packet until samples_per_packet / sample_rate. The
first sample is a packet is delayed by the time it takes to produce the
last sample.

However, in the case of transmission/send there is no such issue.
Essentially your application is the pacer and producer of samples. So
you have total control.

-Josh

8

Thank you very much again!

9

Thanks Josh, that helps quite a bit! Our sampling frequency is not
particularly fast, it will only be around 5 MS/S. Right now the send and
receive frame size are still the defaults, 1472 for receive and 1444 for
send. In the notes, it says “to improve receive latency, configure the
transport for a smaller frame size”, will this work for send latency as
well? Also is there an equation I can use to determine what the best
frame
sizes would be, or should I just go with trial and error and use
latency_test.cpp to determine if it has shifted? If you change the frame
size, how much improvement in latency do you usually see?
Again, thank you so much.
-Anisha