Fabian, My colleague also encountered this "factor of 2" bug and determined that it is present starting in 3.14. It's related to the tick/sample rates in the TwinRx Radio, and does affect timed commands as you suggest. In fact, the issue can actually be demonstrated using Ettus's example program "test_timed_commands", which does not run successfully for a TwinRx in 3.14 and later. He actually just submitted this issue to supp...@ettus.com a few days ago and is currently waiting on a response from them. Rob
On Thu, May 9, 2019 at 9:06 AM Fabian Schwartau via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > is there any update regarding this issue? > > Am 26.04.2019 um 11:27 schrieb Fabian Schwartau via USRP-users: > > Hi, > > > > is it to be expected that this will be fixed soon? Is someone at Ettus > > working on this? > > > > Best regards, > > Fabian > > > > Am 23.04.2019 um 19:34 schrieb Fabian Schwartau via USRP-users: > >> OK, I just reverted the system to the old version and that works > >> perfectly. The USRP time is incremented in full seconds like expected. > >> So something changed somewhere in the lib/fpga image. > >> The version I am using now is: > >> linux; GNU C++ version 5.4.0 20160609; Boost_105800; > >> UHD_003.010.002.HEAD-0-gbd6e21dc > >> Hope that helps. > >> > >> Am 23.04.2019 um 19:12 schrieb Marcus D. Leech via USRP-users: > >>> On 04/23/2019 01:10 PM, Fabian Schwartau via USRP-users wrote: > >>>> Will the fpga image downloader from the old version also download > >>>> the old fpga images? Or where can I get them? > >>>> I don't know if I will do it. I am afraid of breaking my system > >>>> and/or investing a lot of time with this as I am under quite a lot > >>>> of time preasure and I am basically working on the production system > >>>> which has to bo rolled out in a few days. If I brick it, I will get > >>>> in trouble ;) > >>> The uhd_images_downloader tool will always download the images that > >>> match the library version. > >>> > >>> > >>>> > >>>> Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users: > >>>>> On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users wrote: > >>>>>> Hi, > >>>>>> its the same. I found the bug because the timed commands took much > >>>>>> longer than expected, so the USRP clock is actually running at a > >>>>>> lower rate. However, the spectra looked ok and everything else > >>>>>> seems to be working as usual, except there is a larger delay > >>>>>> between the commands. So the USRP is not running at a wrong clock > >>>>>> or something like that. That would probably cause much larger > issues. > >>>>>> > >>>>>> Best regards, > >>>>>> Fabian > >>>>> If you revert to a previous release, does the problem go away? > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users: > >>>>>>> On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote: > >>>>>>>> Hi everyone, > >>>>>>>> > >>>>>>>> I just found a very strage bug and would like to confirm that > >>>>>>>> this is a bug and if someone can explain/fix this. > >>>>>>>> I read the time from the USRP using get_time_now() and do a lot > >>>>>>>> of stuff with it. Mainly to time commands like frequency hopping > >>>>>>>> and starting of streams. I noticed that the time in the USRP > >>>>>>>> seemed to run slower than expected, actually by a factor of two. > >>>>>>>> Please find a program attached that demonstrates this effect. It > >>>>>>>> prints the internal USRP time roughly every second (using sleep) > >>>>>>>> but the USRP time increments only by 0.5 seconds in each step. > >>>>>>>> What is going on? > >>>>>>>> > >>>>>>>> The program can be compiled using: > >>>>>>>> g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main > >>>>>>>> > >>>>>>>> I am using a single (or multiple - does not have an effect) X310 > >>>>>>>> with two TwinRX. UHD is "linux; GNU C++ version 5.5.0 20171010; > >>>>>>>> Boost_105800; UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA > >>>>>>>> image is also from yesterday using the download script - where > >>>>>>>> can I find the version number? I am running an up-to-date Ubuntu > >>>>>>>> 16.04. > >>>>>>> Could you try the print as a get_frac_secs() and get_full_secs() > >>>>>>> instead? To disambiguate whether this is an actual hardware > >>>>>>> clock management > >>>>>>> issue or just a formatting issue. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > > 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
