usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadstime_now and daughterboard synchronization
Dear all,
I have a synchronization issue when using the method "set_time_now()"
(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a351a2c3081944a0d2caab95e2a2f0926).
The setup is composed of two X310 usrps, one to transmit (T), the other
to receive (R), at 20 MHz. The A Tx/Rx frontend of T is connected to A
and B Rx2 of R with SMA wires (same length) and a splitter. The
transmission is handled by gnuradio and is not recorded. When recording
on R side, I expect that signals recorded at both frontends (A RX2 and B
RX2 of R) are aligned. When using the method "set_time_now()" to set 0.0
time, signals are ~40 samples away. It does not happend with
"set_time_unknown_pps()".
Attached files "rx_multi_samples.cpp" and "run.sh" are codes used to run
the experiment. Switching --sync from "now" to "pps" solves the issue.
Attached files "time_now.svg" and time_unknown_pps.svg" are pictures
showing the behaviour when using "set_time_unknown_pp()" or
"set_time_now()". From "set_time_now()" documentation, I cannot conclude
that it is an expected behaviour, is it?
The uhd version is 3.12.0.0.
Kind regards,
Cédric Hannotier
On 09/04/2019 10:54 AM, Cédric Hannotier via USRP-users wrote:
Dear all,
I have a synchronization issue when using the method "set_time_now()"
(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a351a2c3081944a0d2caab95e2a2f0926).
The setup is composed of two X310 usrps, one to transmit (T), the
other to receive (R), at 20 MHz. The A Tx/Rx frontend of T is
connected to A and B Rx2 of R with SMA wires (same length) and a
splitter. The transmission is handled by gnuradio and is not recorded.
When recording on R side, I expect that signals recorded at both
frontends (A RX2 and B RX2 of R) are aligned. When using the method
"set_time_now()" to set 0.0 time, signals are ~40 samples away. It
does not happend with "set_time_unknown_pps()".
Attached files "rx_multi_samples.cpp" and "run.sh" are codes used to
run the experiment. Switching --sync from "now" to "pps" solves the
issue. Attached files "time_now.svg" and time_unknown_pps.svg" are
pictures showing the behaviour when using "set_time_unknown_pp()" or
"set_time_now()". From "set_time_now()" documentation, I cannot
conclude that it is an expected behaviour, is it?
The uhd version is 3.12.0.0.
Kind regards,
Cédric Hannotier
The "set_time_now()" operation is unsynchronized--it simply transfers
the host time to the device(s) without any hardware synchronization
pulse. Since it necessarily has to send multiple commands across the
host-to-device interface, and the device sets its clock immediately
to whatever value is provided, and the clock continues to run, then
two or more devices will not tightly agree on the time when using
this method.
On 2019-09-04 19:07, Marcus D. Leech via USRP-users wrote:
Le 04.09.2019 19:07, Marcus D. Leech via USRP-users a écrit :
The "set_time_now()" operation is unsynchronized--it simply transfers
the host time to the device(s) without any hardware synchronization
pulse. Since it necessarily has to send multiple commands across
the host-to-device interface, and the device sets its clock
immediately
to whatever value is provided, and the clock continues to run, then
two or more devices will not tightly agree on the time when using
this method.
The issue is that there is only one device. With "set_time_now()", two
daughterboards on the same device (same motherboard) behave as
unsynchronized.
On 09/04/2019 06:44 PM, Cédric Hannotier via USRP-users wrote:
On 2019-09-04 19:07, Marcus D. Leech via USRP-users wrote:
Le 04.09.2019 19:07, Marcus D. Leech via USRP-users a écrit :
The "set_time_now()" operation is unsynchronized--it simply transfers
the host time to the device(s) without any hardware synchronization
pulse. Since it necessarily has to send multiple commands across
the host-to-device interface, and the device sets its clock
immediately
to whatever value is provided, and the clock continues to run, then
two or more devices will not tightly agree on the time when using
this method.
The issue is that there is only one device. With "set_time_now()", two
daughterboards on the same device (same motherboard) behave as
unsynchronized.
That's because, for weird internal reasons, there are actually TWO
time-of-day clocks on X310 and B210--one per "side". I don't remember
whether there are two commands sent from the host side, or a single
command, that is acted-upon serially within the FPGA. With a
1PPS synchronization, the 1PPS causes a parallel load of the desired
time value into the time-of-day clocks on the motherboard.
On 2019-09-05 00:47, Marcus D. Leech via USRP-users wrote:
That's because, for weird internal reasons, there are actually TWO
time-of-day clocks on X310 and B210--one per "side". I don't remember
whether there are two commands sent from the host side, or a single
command, that is acted-upon serially within the FPGA. With a
1PPS synchronization, the 1PPS causes a parallel load of the desired
time value into the time-of-day clocks on the motherboard.
Thanks for the explanation.
Is it specified somewhere in the documentation? Because it is clearly
stated in "set_time_now()" doc. that: "If only one MIMO master is
present in your configuration, set_time_now is safe to use because the
slave's time automatically follows the master's time". I think these
exceptions should be written somewhere in the doc. if that is not
already the case.
On 09/05/2019 03:57 AM, Cédric Hannotier via USRP-users wrote:
On 2019-09-05 00:47, Marcus D. Leech via USRP-users wrote:
That's because, for weird internal reasons, there are actually TWO
time-of-day clocks on X310 and B210--one per "side". I don't remember
whether there are two commands sent from the host side, or a single
command, that is acted-upon serially within the FPGA. With a
1PPS synchronization, the 1PPS causes a parallel load of the desired
time value into the time-of-day clocks on the motherboard.
Thanks for the explanation.
Is it specified somewhere in the documentation? Because it is clearly
stated in "set_time_now()" doc. that: "If only one MIMO master is
present in your configuration, set_time_now is safe to use because the
slave's time automatically follows the master's time". I think these
exceptions should be written somewhere in the doc. if that is not
already the case.
That's only really applicable for N210, which has a special "MIMO cable".