Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Marcus D. Leech]

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