Forum: GNU Radio 8-channel receiver

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

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.

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

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 ?

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

On 09/28/2012 02:46 PM, Anisha Gorur 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/transp...

> 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....

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

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

On 09/29/2012 09:46 AM, Anisha Gorur 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

Thank you very much again!