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:
I'd suggest you familiarize yourself with the entire documentation tree that's online:
on Jun 03, 2013, Guy Holtzman <hol...@gmail.com> wrote:
Thanks, Guywhat is the uhd.tune_request command and how can I use it when configured to external clock?what can I do to solve the constant shift of 570Hzis this ok?on the Tx, the USRP transmitted with a shift of 10 MHz (minus a few 100s Hertz)when I used the commandanother strange thing happened:the freq is now very stableand this command on the Rx:LED E is always on, even when I disconnect the external sourceI used this command on the Tx:
uhd.tune_request(915000000)
uhd.tune_request(915000000,10e6)
but there is a constant shift of 570 Hz between Rx and Tx
uhd.tune_request(915000000,10e6)
On Mon, Jun 3, 2013 at 3:39 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
You can use "test_pps_input" which is one of the UHD examples.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
Also, LED 'E' tells you whether the clock is locked to the external reference.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio