Sorry for this question but the problem is found: that was a cable from the 1PPS source which was broken... To answer your question: it is a self made 1PPS/10MHz source with 10ns accuracy.
regards, olivier Le 24/03/2020 à 18:08, Marcus D. Leech via USRP-users a écrit : > On 03/24/2020 12:49 PM, Olivier Ravard via USRP-users wrote: >> Hi, >> >> In order to synchronize several devices, We used to use an external PPS and >> 10MHz >> reference and call set_next_time_pps. >> >> This works fine since many years using UHD 3.9 and N210. We recently use >> X300 + TwinRx >> using UHD 3.10.3 and it seems >> that it does not work. >> >> It seems that set_time_next_pps has no effect because the metadata.time_spec >> of the >> received streamed data always >> corresponds to the delay from the usrp object creation. >> Example: >> >> - during the synchro procedure: >> usrp.set_time_next_pps(time_spec_t(1585067798, 0.0)) >> - during receiving data: >> rx_stream->recv(&buff_sc16.front(), buff_sc16.size(), md, 1.0); >> cout << "received date :" << md.time_spec.get_full_secs() << " >> " << >> md.time_spec.get_frac_secs() << endl; >> // this line prints "received date :74 0.778126" if the usrp >> object was >> created since around 74 secs >> >> Does this function change its behavior ? >> >> thanks >> >> olivier >> >> > What type of 1PPS source are you using? > > > > _______________________________________________ > USRP-users mailing list > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
