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.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
