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
on 2012-09-26 18:39
on 2012-09-26 18:56
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.
on 2012-09-26 20:35
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
on 2012-09-27 15:16
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 ?
on 2012-09-28 23:47
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 2012-09-29 00:58
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
on 2012-09-29 18:47
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 2012-10-01 00:22
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
on 2012-10-01 22:44
Thank you very much again!