Does anyone know if this problem is fixed in the current master?
Am 13.05.2019 um 12:41 schrieb Fabian Schwartau via USRP-users:
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
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
