[Discuss-gnuradio] daughter board sticks in transmit state

[Ketan Mandke]

After doing some further investigation, I've come to the conclusion
that this bug is being caused by the hardware. After replacing the
USRP & daughter cards everything started working.

The behaviour of the broken board is very perplexing. It works
correctly for a seemingly random amount of time and then gets stuck in
the transmit state. It will sometimes get "unstuck", but I don't
understand why or how this can happen. Since this bug is not easy to
reproduce, I've had some trouble reliably debugging it.

Has anyone else had a similar experience with the Flex2400 daughter
boards, or have any idea why this might be happening?

Hydra: http://hydra.ece.utexas.edu

-- 
Ketan Mandke

On Jan 24, 2008 9:16 PM, Ketan Mandke <address@hidden> wrote:
> Hi,
>
> I'm not sure if my problems are necessarily caused by USRP overflows,
> but I have definitely noticed a correlation. It seems as though after
> a certain number of overflows occurs in my system, the USRP gets stuck
> in the transmit state (i.e. although the receiver thinks it is hearing
> something, the daughter board is actually in transmit mode). I came to
> this conclusion after observing that, although my system no longer
> sees incoming waveforms (i.e. there is only noise on the received
> signal), it is still able to transmit waveforms successfully. I am
> using the auto_tr feature of the USRP to enable this transmit/receive
> switching.
>
> Has anybody else noticed such behavior or something similar while
> using the automatic transmit/receive switching mode of the USRP?
>
> ---------------------------
> Some specifics:
> PC: dual core Intel processor (plenty of RAM)
> OS: linux (latest version of fedora)
> GR version: 3.1.0
> RF: Flex2400 Rev 30
> USRP: version 4.1
> PHY: custom design based on 802.11n
> Interp/Decim rates: 128/64
> --------------------------
>
> Please let me know if you feel more specifics will help you answer my
> question. Thanks.
>
> Hydra: http://hydra.ece.utexas.edu
> --
> Ketan Mandke
>