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
