Re: [Discuss-gnuradio] Understanding flow control

[Tom Gross]

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

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.

-Tom

On Fri, Jan 15, 2010 at 9:21 PM, Matt Ettus <address@hidden> wrote:
> On 01/15/2010 03:53 PM, Tom Gross wrote:
>>
>> Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
>>
>> We greatly appreciate the information and need to think about stuff on
>> our end.  I've been deliberately vague about our application (not that
>> I could really explain it even if I felt authorized discuss it).   The
>> thing to remember is that we believe (maybe we are fooling ourselves)
>> that we see easily reproducible problems when RX is ON but not when RX
>> is OFF.
>
> It is very hard to help when we don't have information about what you are
> trying to do.  The important piece of information is that you are
> transmitting and receiving at the same time when you see this problem. This
> indicates that there may be flow control tuning issues.
>
> Is the RX stream ok and the TX has a problem?  Or is it that the TX is ok
> and the RX has a problem?  Or is it both?
>
> Do you have a TTL serial port hooked up to J305?  Do you see characters
> there?  Do you see "S" characters on the receive application window?
>
> Are you trying to use 2 separate programs (1 tx, 1 rx) to talk the the
> USRP2, or are they in the same app?
>
>> One more question was just sent to me to pass on, while I was
>> composing this email:
>>
>> crazy idea: is there any way to "clock" the host, i.e. keep track of a
>> time stamp in the host and gate/trigger the host outputs at a constant
>> sample rate that is consistent with the sample rate of the USRP2?
>
> No, for 2 reasons:
> - Even if the host had a clock, clocks drift relative to each other
> - The USRP2 might need to hold off on sending for some reason.
>
> This is a system that requires feedback and there is no way around it. On
> the USRP1 the feedback is done by the flow control built into the USB
> protocol.  On the USRP2 the feedback is done by the flow control built into
> ethernet.  You could imagine doing a different feedback mechanism using your
> own protocol, but it would still involve the device telling the computer
> when to go and when to stop.
>
> Actually there is one way around it -- have infinitely large buffers in the
> USRP2, but that would add to the cost :)
>
> Matt
>