Matt,
I solved this problem yesterday and it was my mistake. I measured the
voltage levels of the internal oscillator with intentions of matching
this level with my external clock. What I didn't see was the fact that I
was measuring my levels with the "ac-coupled" setting on the scope. Too
make a long story short, I needed to add a dc offset to my external
clock to prevent the negative swings. Everything works perfectly now. I
have been running the board for more than 24 hours without a problem.
The past two systems I have worked with use an external clock directly
from a frequency synthesizer so I think I was unconsciously making
assumptions (bad news).
Thanks for the reply,
--Ryan
Matt Ettus wrote:
Ryan,
I am looking into this problem. I will let you know if I find anything.
You are using a 3.3V clock signal, right?
Matt
Ryan Seal wrote:
When running both usrp_oscope and usrp_fft, I lose the signal and the
GUI becomes unresponsive after 5 - 30 minutes of operation. I had
previously ran this system for more than 24 hours with an installation
on a laptop back in July. Here is a short summary of my setup:
1. Dual HT Intel 64-bit processors with 32-bit Gentoo distribution.
2. Latest dependencies from the portage tree (using ~x86 flag).
3. I am using an external clock at 64MHz that will sync the USRP with
the rest of my system.
4. I have an official USB 2.0 certified cable.
To get the system back up and running properly, I either cycle power
(unplug the power supply) or run the usrper load_standard_bits
command. I also receiver failures when running the benchmark_usb
program maybe this is beginning to sound like a hardware problem ?
--Ryan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
