Hello Jason: Thanks for all the detailed feedback! No worries about not having a stand-alone reproducing program at the moment. Could you please try using the head of the "UHD-3.14" branch? We just tagged v3.14.1.1-rc1 with some bug fixes, which we think should address the issue. Please let me know your results running with that, and we'll go from there.
--Neel Pandeya On Mon, 19 Aug 2019 at 13:34, Jason Roehm via USRP-users < usrp-users@lists.ettus.com> wrote: > > On 8/19/19 12:34 PM, Neel Pandeya wrote: > > Hello Jason: > > I also would have expected UHD 3.14.1.0 to have resolved this issue. > > Would you be able to send me a stand-alone program that I can use to > reproduce this problem? > > Also, I'm curious, do you have a GPSDO installed in your X300? > > --Neel Pandeya > > Neel, > > Also, if it helps, I had traced the problem down a bit further when I was > originally debugging it last week. I found that the code in > super_recv_packet_handler.hpp, which translates the packets from the device > into samples and metadata that are passed to the UHD client, thought that > the tick rate was 100 MHz (recv_packet_handler::_tick_rate was equal to > 100e6). However, the X300 with a TwinRX installed must always use a master > clock rate of 200 MHz per the documentation. So the effect was that the > timestamps received in the packets from the X300 were ticking up at a rate > of 200 MHz, but the code in recv_packet_handler believed that the tick rate > was 100 MHz instead; hence the 2x real-time rate. I was not able to find > out how that tick rate was actually getting to the recv_packet_handler, > however. > > Jason > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
