Re: [Discuss-gnuradio] Understanding flow control

[Matt Ettus]

On 01/16/2010 09:03 AM, Tom Gross wrote:
> Hi Matt,
>
> I'll try hooking up my ttl line on Monday (I have done that but not
> with our current configuration, so far only when I was playing around
> with building custom firmware).
>
> Here's the official description of what we are doing (I hope this helps!):
>
> We have two USRP2s sharing common clocks via the MIMO cable. The first
> USRP2 receives a 20MHz input signal and outputs an amplitude and phase
> shifted copy of this same signal. Analog subtraction is performed
> between the input and output signals of the first USRP2.  The result
> of this subtraction is an error signal that is used as an input to the
> second USRP2. The host implements a signal processing algorithm that
> adaptively estimates the amplitude and phase shift to apply to the
> 20MHz signal such that the resulting error signal at the input to the
> second USPR2 is driven to zero. This processing forms the foundation
> of a real-time adaptive closed-loop control system that has a myriad
> of diverse applications.

What daughterboards are you using?  If it is the BasicRX or LFRX and 
BasicTX or LFTX, the you are probably better off doing this all in the 
same USRP2.  It would take some relatively small modifications to the FPGA.


The system described above appears to work
> well for relatively low throughput bandwidths (i.e. for USRP2 sample
> rates below about 3.1MHz, decim = 32). In addition,  because of
> apparent latencies between the time at which the host updates its
> calculations and the time at which these calculations are reflected in
> the output of the first USRP2, we must use additional decimation in
> the host by a significant number of samples (something like 512 is
> typical). So the effective closed-loop throughput bandwidth is
> approximately 100MHz divided by decim * 512 or only about 6kHz. We
> would, of course, like to run this system with as much throughput
> bandwidth as possible and we are not sure at this point where the
> biggest bottleneck is coming from.

You need to be careful here -- increasing decimation will increase your 
latency.  This is fundamental to all signal processing systems.

What you really want is to reduce buffer sizes.


> I would only add that what is referred to as the "first" USPR2 above
> does input and output through eth0 (the controller on the motherboard
> - this is on a quad-core Lenovo running the latest 64-bit Ubuntu).
> The second USRP2 (the slave, set up to get its clock through the MIMO
> cable from the first USRP2) is receiving date through eth1.  My code
> (the signal processing algorithm that drives the error signal to zero)
> seems to "blow up" after about 30 seconds unless I set RX to OFF on
> eth0.


Can you be more specific about what "blow up" means?

Matt