discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Brett L. Trotter
Subject: Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
Date: Thu, 26 May 2011 21:14:15 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110419 Red Hat/3.1.10-1.el6_0 Thunderbird/3.1.10

On 05/26/2011 08:06 PM, Nick Foster wrote:
> 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.
gr-usrp
Ubuntu x86_64 with libusrp /usr/lib/libusb-0.1.so.4.4.4
RHEL-6 x86-64 with libusrp /usr/lib64/libusb-0.1.so.4.4.4
I believe I've also seen it on FC14 and RHEL5

USB devices continue to function, but it will not recognize new
connection events of any device, the USRP will not reinitialize even if
power cycled and reconnected, even to a different port.


>> 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
The alignment I'm talking about wasn't even relative between RX and TX-
it was between branches of the RX path such as the real and imaginary
components of that path when viewed on the scope.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]