W dniu 26.02.2018 o 19:44, Marcus D. Leech via USRP-users pisze: > On 02/26/2018 01:36 PM, Piotr Krysik via USRP-users wrote: >> >> It's hard for me to understand why only one of the devices changes the >> master clock rate at that moment. This seems a bit arbitrary. It would >> be best that after creation of usrp_source the master clock rate >> wouldn't be changed (unless user requests it). > It's NOT arbitrary on the B2xx series--the sample-rate interface in > UHD tries to provide maximum flexibility by changing the > master clock rate to achieve the desired sample-rate, UNLESS the > user has specified an explicit master-clock rate. > > Since sample-rate can be changed after a USRP block is instantiated, I > don't see any way to achieve both goal simultaneously. What I call arbitrary is that: 1. in this situation it happens for one USRP only, 2. no amount of waiting before calling time synchronization function can change that.
Why one USRP might be waiting for a moment after calling set_time_next_pps(...) to change the value of master clock rate is mystery for me. Why not to do that earlier during call to set_samp_rate(...) function. Great that user can avoid that issue by calling set_clock_rate(..) explicitly :). _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
