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

[Brett L. Trotter]

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.

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.




On a general note- I think there should be two new block sets added:
1) A simple source block that provides samples in the appropriate format
(float, complex, etc depending on the _f / _c etc) which generates as
fast as possible and counts how many it generates in a second which gets
output on a float output.

2) The same thing but a consumer.

The idea being it would help diagnose blocks that end up putting out
more or less data than they take in and whose decimation/interpolation
rates aren't apparent. For instance, I have a decimating filter block
that appears to actually be producing more samples than it takes in,
causing the data to show up almost 30 seconds later on the scope which
is set at the source's data rate. I'd love to put the timed consumer and
timed provider blocks on either side and see how the in/out amounts compare.