Re: [USRP-users] USRPs time wrong by factor of two

2019-07-17 Thread Fabian Schwartau via USRP-users
I jost got a response from Ettus. The problem is fixed commit 5f75f73 (release 3.14.1.0). I tested it with my earlier supplied script and it works. Maybe this info will be helpful for someone else. Am 04.06.2019 um 09:54 schrieb Fabian Schwartau via USRP-users: Does anyone know if this problem

Re: [USRP-users] USRPs time wrong by factor of two

2019-06-04 Thread Fabian Schwartau via USRP-users
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 befor

Re: [USRP-users] USRPs time wrong by factor of two

2019-05-13 Thread 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

Re: [USRP-users] USRPs time wrong by factor of two

2019-05-09 Thread Rob Kossler via USRP-users
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 "t

Re: [USRP-users] USRPs time wrong by factor of two

2019-05-09 Thread Fabian Schwartau via USRP-users
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,

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-26 Thread 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 se

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread 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-

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread 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 qu

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread Fabian Schwartau via USRP-users
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 pr

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread 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, ex

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread Fabian Schwartau via USRP-users
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

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread 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

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread Fabian Schwartau via USRP-users
Hi, did error checking, no errors. The sleep also fits quite well with my feeling and in my main program I am working on, I am using QThread::currentThread->sleep(1) and additionally printing the current system time. So I am very confident this is a problem on the USRP side. I switched to an u

Re: [USRP-users] USRPs time wrong by factor of two

2019-04-23 Thread Tillson, Bob (US) via USRP-users
While I would not expect sleep to fail consistently, it *can* return a non zero value when not sleeping for the entire time. Try checking the return value for success. Its not likely this is the cause if it happens every time, but error checking is your friend :) -Original Message- Fro