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

[Nick Foster]

On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote:
> 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.

UHD or gr-usrp? What OS? What version of libusb? Do all USB devices
"freeze" or just the USRP? Does power cycling the USRP un-freeze it?
This is definitely not something I've seen before.

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

If you lose samples somewhere in the chain, which can happen, the TX and
RX paths will change their relative alignment. Have you tried reducing
your sample rate, or the refresh rate on the graphical sink? The various
graphical sinks can be very CPU-intensive. 

It is generally not a great idea to rely on the TX and RX paths staying
aligned with respect to each other all the time. The fact that the USRP1
seems to in your test is a bonus, but I wouldn't rely on that going
forward either.

If you require the TX and RX paths to maintain a fixed relationship, the
USRP2 with UHD will let you use timed samples to achieve this down to
10ns. You could also align your TX and RX paths in your application,
using known TX waveforms to correlate the RX against. This approach
probably fits best into your design flow (don't have to code C++ with
UHD).

--n

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

This is a cool idea, but I'm not sure how it could be implemented in
Gnuradio's scheduler. I'll have to think about that one.

--n
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio