Understanding flow control

On Sat, Jan 16, 2010 at 2:09 PM, Matt E. [email protected] wrote:

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.

We are using an LFRx and an LFTx.

We would absolutely love to have a version of the USRP2 firmware and
host software that can read both receiver channels, as we can on the
USRP1.

I’ve been trying for weeks (as a low-priority task when I have nothing
else to do) to create a “usrp2_dual_source” block as a first step
before modifying the firmware to read from either channel on the
USRP2, but I haven’t been able to actually get it to work at all, even
as a dummy procedure, on the host side (I am going to post a separate
question about this to the discussion group after I finish this
message - there is some stuff about this development environment that
is baffling me).

I think what we really want to do is implement our algorithm as a
standalone program on the SD card, but I thought that using data from
both receiver channels on the host would be a logical intermediate
step.

Basically when I say it “blows up” it’s a race condition, where our
host processing is unable to calculate the proper correction signal -
it seems clear to us (just from the way the system behaves) that when
RX is ON, our correction signal is getting delayed enough that by the
time our external hardware gets it it’s no longer useful - it’s more
important to us that our output be transmitted asap even if it means
dropping some of it.

Here’s the output of the serial port when the system is working
properly:

Tx dbid: 0xE
Rx dbid: 0xF

TxRx-NEWETH
00:50:C2:85:34:01
ethernet flow control: NONE
Speed set to 1000

eth link changed: speed = 1000
Tx dbid: 0xE
Rx dbid: 0xF
UUUUUEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEUUEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEUUEEEEEEEEEEEEEEEEEEEEEEEEEEEEE