Thanks for that. IT is quite interesting, that it also does not work with their own example. I would expect that all examples would be run on different test beds before releasing "stable" software versions... However, please keep us up to date, if you get any new information.
Best regards, Fabian Am 09.05.19 um 19:33 schrieb Rob Kossler: > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
