External clock issue with B100 + WBX

GNU Radio
#1

I have two USRP B100 and I am trying to sync them
for that I have connected them both to reference and 1pps from the same
source
the source is a rubidium standard source reference
it has a 10MHZ 1Vrms 50 ohm sine and 1pps outputs. I have tested it with
a
scope to see if its stable.
for my test I transmit from one USRP B100, and receive from the other
USRP.
I configured both devices for:
clock source: external
time source: external
sync: unknown 1pps

tested the output with WX GUI FFT Sink on the Rx side
whenever I set the clock source to external on the receiver side,
instead
of getting a carrier, I get a distorted signal: the I and Q are not
constant envelope, as they should be.
whenever I set the clock source for default, I get a carrier, but it is
shifted a few 100s of hertz from the wanted signal and it changes every
a
few 100s of hertz (it is not constant)
I am using the latest version of GNU Radio
I didn’t see any warning or error message when disconnecting the 10MHz
clock ref.
I did see an error message when I disconnected the 1pps ref.
is this a known problem? is this expected? if not, what am I doing
wrong?
I am adding the grc files
here is the log (it seems fine, and look identical for Tx and Rx):
Generating: “/home/guy/Documents/top_block.py”

Executing: “/home/guy/Documents/top_block.py”

linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b

– USRP-B100 clock control: 10
– r_counter: 2
– a_counter: 0
– b_counter: 20
– prescaler: 8
– vco_divider: 5
– chan_divider: 5
– vco_rate: 1600.000000MHz
– chan_rate: 320.000000MHz
– out_rate: 64.000000MHz

– 1) catch time transition at pps edge
– 2) set times next pps (synchronously)

Regards, Guy

#2

On 06/02/2013 02:49 PM, Guy H. wrote:

time source: external
I didn’t see any warning or error message when disconnecting the 10MHz

–
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Look at the 1PPS and 10MHz signals on the scope with them connected to
the B100 – are the levels still in range for the input spec?:

http://files.ettus.com/uhd_docs/manual/html/usrp2.html#ref-clock-10mhz

The N2XX notes contained there should apply to the B100 as well.

#3

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

#4

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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

#5

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

#6

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

#7

Hi,
I am using the same clock reference to both b100 devices.
the clock reference is XL microwave model 500, it is rubidium based, and
it
has multiple outputs.
since I am connecting it to both B100s (the actual same clock reference)
I
was expecting that the Rx and Tx frequencies will be exactly the same.
but
I still got 570Hz difference.
when I did not invoke the tune request command, the Rx was distorted
(the
Tx was fine, I tested it with a spectrum analyzer)

Regards, Guy

#8

Regards, Guy
Define “exactly the same”. Even a Rb reference oscillator has some
imprecision in it, although not usually as high as 600ppb, unless the
vapour
tube is nearing the end of its life.

How did you measure the frequency offset? The measuring device has to
have a precision much better than the thing you’re trying to measure,
or your results will just be nonsense.

If you don’t use offset tuning (using tune_request with an LO offset),
then the DC anomaly will be right in the center of your passband. If
you’re using
a narrowband carrier for testing, that DC offset will interfere with
your measurements.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

#9

OK, I discovered what was the problem.
it turns out I did not generate a carrier, but a just constant 0
(instead
of constant 0.7)
when generating a carrier, the Rx and Tx are perfectly synced
sorry for all the trouble, and thanks for the help

Guy

#10

on the Rx side, I use uhd.tune_request(915000000,10e6)
then I down-sample and display a FFT
the amount of down-sampling is enough that I can see how much frequency
offset I get.
I am testing it with a carrier generated from a second B100, using
uhd.tune_request(915000000)
even if the reference had an accuracy problem. deriving the clock would
produce the same error for all devices connected to it, given the
reference
signal is within spec
under the scope, the reference signal seems to be a perfect sine with an
rms within spec.
currently, for now, I will have to understand more what the tuning does,
and why.
since the freq offset I see is constant, I can live with it, for now.
Regards, Guy