discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] external clock issue with B100 + WBX


From: Marcus Leech
Subject: Re: [Discuss-gnuradio] external clock issue with B100 + WBX
Date: Mon, 3 Jun 2013 19:19:40 +0000 (UTC)

Tune request is independant of external clocking--that's an orthogonal property of an instantiated device object.

On TX the LO will be tuned to whatever you've set as the LO offset, so any LO leakage will appear there, but your signal will be where it's supposed to be.
 
570hz/915e6Hz is a residual frequency error of 0.6PPM.
 
What are you using for your external reference?  The B100 clock itself is good to about +/- 2.5PPM, so 0.6PPM sounds like it's locking to an external reference, or you're just "lucky".
 
uhd.tune_request() is used to request a tuning with more-complete control over the RF and DSP tuning aspects:
 
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
 
I'd suggest you familiarize yourself with the entire documentation tree that's online:
 
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki

 
 
 
on Jun 03, 2013, Guy Holtzman <address@hidden> wrote:
LED E is always on, even when I disconnect the external source

I used this command on the Tx:
uhd.tune_request(915000000)

and this command on the Rx:
uhd.tune_request(915000000,10e6)

the freq is now very stable
but there is a constant shift of 570 Hz between Rx and Tx

another strange thing happened:
when I used the command
uhd.tune_request(915000000,10e6)
on the Tx, the USRP transmitted with a shift of 10 MHz (minus a few 100s Hertz)

is this ok?

what can I do to solve the constant shift of 570Hz
what is the uhd.tune_request command and how can I use it when configured to external clock?
Thanks, Guy


On Mon, Jun 3, 2013 at 3:39 PM, Marcus D. Leech <address@hidden> wrote:
I Checked the levels with the clock connected to the USRP ( and without)
The levels are fine ( about 600 mV rms on the scope)
additionally, I disconnected it from the load (USRP) to see if the level changed. and they did (proving the cables are connected to a load).

the problem remains,
is there a command that could check if the USRP is locked to the external clock?
what is the best way to debug this and to find the root cause?

Thanks for your help,
Guy

You can use "test_pps_input"  which is one of the UHD examples.

Also, LED 'E' tells you whether the clock is locked to the external reference.





--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

reply via email to

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