[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
From: |
Marcus D. Leech |
Subject: |
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion |
Date: |
Thu, 26 May 2011 22:21:05 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 |
>
> USRP1:
> - When we have a very simple flowgraph with a USRP1 sink connected to a
> signal source and a USRP1 source connected to a WX scope- trying to shut
> down the app using the close box causes the USB on the host system to
> freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
> this problem. This problem exists on many flowgraphs, both GRC generated
> and not- as far as I know it is limited to flowgraphs with both USRP1
> source and sink. This is a serious problem that has hit us on multiple
> platforms and machines and causes unnecessary reboots. It is honestly an
> unacceptable bug.
>
>
My intuition here is that the "close" box doesn't cause the flow-graph
to do the
usual "finish the flow-graph" thing. Which means that the USRP1 is
still streaming, and
nobody is listening. For the 'power off' case, the USRP1 resets
itself, and stops streaming
data, and for ctrl-C, there's built-in logic that causes the
flow-graph to shutdown
"politely", and send a "please stop streaming" command to the USRP1.
My suspicion about
USB freeze-up is that the problem is due to the USB drivers in the
kernel not doing the
right thing with a deluge of data still arriving when nobody is
actually listening. Which makes it a
not-strictly-GnuRadio thing, and more of a USB drivers thing. Also,
USB is inherently half-duplex,
which may (somehow) play into scenarios like this--some kind of weird
deadlock problem in the
kernel USB drivers?
> USRP2 / UHD:
> - With a similar flowgraph to the one above, changing the secs/div
> causes the various traces to change phase relative to one another but
> this doesn't happen when a USRP1 source is substituted. However, I
> believe this is indicative of a deeper problem. We also see with the
> same flowgraph and a slider that controls both the TX and RX frequencies
> simultaneously, the flowgraph gets into a place where it seems to be
> getting data but it no longer represents the state of what's coming in
> and we also see the phase slippage. Long story short, create a flowgraph
> with a UHD (USRP2) sink and source with a siggen at a fixed
> frequency/amplitude, a wx scope, and a slider that sets the TX+RX
> frequencies to the slider value. Direct connect the TX to the RX with an
> SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX
> this seems to give various results. Do the same thing with a USRP1 for
> comparison. To me it seems like UHD is losing data or the various paths
> in the flowgraph get out of whack with eachother. There were no O's or
> U's printed.
>
> We were trying to do a simple VNA in UHD and it just doesn't work as
> expected, but switching it all over to a USRP1 its fine and dandy.
>
>
>
There's a tremendous amount of buffering inside a Gnu Radio flow-graph,
which can
easily cause *seconds* of latency. The buffer-sizing algorithm is
complicated, and the
buffering at any point in the graph is calculated by whatever is
downstream, including
decimators.
I've long opined that the buffer-sizing (with its inherent latency)
isn't actually correct all the time,
but I admit to not having offered any meaningful solutions. I don't
know whether UHD exacerbates
this problem or not.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion, Brett L. Trotter, 2011/05/26
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion,
Marcus D. Leech <=