Forum: GNU Radio external clock issue with B100 + WBX

E7e31d69facc938b81acf9c46cc8846f?d=identicon&s=25 Guy Holtzman (Guest)
on 2013-06-02 20:50
(Received via mailing list)
Attachment: simplerx.grc (20 KB)
Attachment: simpletx.grc (10 KB)
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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-06-02 20:56
(Received via mailing list)
On 06/02/2013 02:49 PM, Guy Holtzman 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....

The N2XX notes contained there should apply to the B100 as well.
E7e31d69facc938b81acf9c46cc8846f?d=identicon&s=25 Guy Holtzman (Guest)
on 2013-06-03 13:00
(Received via mailing list)
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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-06-03 14:40
(Received via mailing list)
> 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
E7e31d69facc938b81acf9c46cc8846f?d=identicon&s=25 Guy Holtzman (Guest)
on 2013-06-03 21:12
(Received via mailing list)
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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus Leech (Guest)
on 2013-06-04 14:23
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
E7e31d69facc938b81acf9c46cc8846f?d=identicon&s=25 Guy Holtzman (Guest)
on 2013-06-04 18:53
(Received via mailing list)
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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-06-04 18:57
(Received via mailing list)
> 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 Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
E7e31d69facc938b81acf9c46cc8846f?d=identicon&s=25 Guy Holtzman (Guest)
on 2013-06-04 19:58
(Received via mailing list)
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
E7e31d69facc938b81acf9c46cc8846f?d=identicon&s=25 Guy Holtzman (Guest)
on 2013-06-04 20:20
(Received via mailing list)
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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.