On 2022-05-13 10:38, Marcin Puchlik wrote:
But you know what I observed and what is weird? When I ask for an
external source and I intentionally turn off the external generator
providing a 10 MHz signal, USRP behaves as if it was still seeing a 10
MHz reference signal at its input. Doesn't matter if the generator is
switched on or off - USRP behaves the same way. Because of that I am
not sure if USRP is being clocked from an internal or external clock
source. Is it the bug in the GNU radio or UHD or am I doing something
wrong? How can I get the feedback from the USRP hardware that it was
locked to the external clock? Is it even possible?
The external clock is simply used to "discipline" or "steer" the main
system clock. If that "steering" signal goes away, the clock PLL simply
"holds" are where it
was last and the system clock will do what it would do "naturally" if
not getting any steering signal. Unless you have some way of measuring
precise phase and
frequency offsets in your overall system, you won't notice any
high-level functional change.
śr., 11 maj 2022 o 16:14 Marcus D. Leech <patchvonbr...@gmail.com>
napisał(a):
On 2022-05-11 09:51, Marcin Puchlik wrote:
Will it be enough to clock USRP from the external 10 MHz signal
generator? When I run the flowgraph I cannot see the information
that is using the external clock. Here is the output from GNU Radio:
[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Detected Device: B200
[INFO] [B200] Operating over USB 2.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [B200] Asking for clock rate 51.200000 MHz...
[INFO] [B200] Actually got clock rate 51.200000 MHz.
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [B200] Asking for clock rate 51.200000 MHz...
[INFO] [B200] OK
[INFO] [B200] Asking for clock rate 51.200000 MHz...
[INFO] [B200] OK
[WARNING] [AD936X] Selected Tx sample rate (0.2 MHz) is less than
analog frontend filter bandwidth (0.2 MHz).
image.png
Yeah, I don't think it puts out an "i'm locked to the external
reference" message.
But you've asked for "external" clock source, so you should be
good to go, assuming your external generator meets the requirements.
śr., 11 maj 2022 o 15:24 Marcus D. Leech
<patchvonbr...@gmail.com> napisał(a):
On 2022-05-11 09:18, Marcin Puchlik wrote:
Marcus,
Thank you very much for the answer. Does it mean that 1 PPS
signal is optional? Can I only provide an external 10 MHz
clock without 1 PPS?
*Z poważaniem *
*Marcin Puchlik*
*Yes, absolutely. If timestamp synchronization is not
important to you, then you can just provide a 10MHz reference
when you want better
frequency accuracy and drift characteristics than are
offered by the on-board clock and/or you want some type of
phase-synchronization
but don't care much about mutual phase offsets....
*
śr., 11 maj 2022 o 14:24 Marcus D. Leech
<patchvonbr...@gmail.com> napisał(a):
On 2022-05-11 06:17, Marcin Puchlik wrote:
Hello Community,
Like in the topic, I know that a stable 10 MHz source
is needed as a clock signal but why do we need 1 PPS
signal? How is it used by the USRP hardware? Can
someone explain that to me?
Thanks
Marcin
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
1PPS is used to provide timestamp-clock synchronization
across multiple devices, typically. This is important
when your application requires this, such as in MIMO or
multi-receiver TDOA schemes, etc.
Basically, when you have multiple devices you use
set_time_unknown_pps() or set_time_next_pps() to signal
to all devices in your multi_usrp object that at the next
1PPS, to set the timestamp clock to the value given in
the the API call.
This turns out to be useful even in single devices that
are "bicameral", such as B210 and X310, where there are
(for historic and architectural reasons)
TWO timestamp clocks. Use the 1PPS synchronization
primitives causes the internal timestamp clocks to
become synchronized.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to
usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
