To answer my own question: Yes, it does.
Even when calling clear_command_time(), the get_time_now() will be
executed (and thus return) after the last commited command was executed,
no matter what command it was. Additionally if the last command is too
far in the future, get_time_now() will fail and throw an exception,
saying that the USRP did not respond.
Am 23.04.2019 um 22:54 schrieb Fabian Schwartau via USRP-users:
Hmm does this also mean that get_time_now will block if there are other
commands issued before that with a later execution? That might explain
my issues.
Am 23. April 2019 22:38:01 MESZ schrieb "Marcus D. Leech via USRP-users"
<usrp-users@lists.ettus.com>:
On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:
Hi,
well, ...
I am recording small slots (up to 2 seconds) of data at different
frequencies, gain, sample rates, etc. I have written a manager
for the
USRP where other classes can ask for a certain slot (frequency,
sample
count, sample rate, ...). The manager does not know when someone
will
ask for data. So it happens that there is nothing to do. In that
case
the manager looses track of the current time and does not know
when to
start the next command once someone asks for a new slot. In this
case
he gets the current time, adds a few hundred ms to be on the
safe side
and continues. Even if I would be able to plan that far ahead, I
found
out that the USRP is not able to plan commands that are quite
far in
the future (it was like 10 seconds or so). Starnge things happen
and I
also loose track of the time.
One more reason is that the USRP is not capable of timed sample
rate
switches (was discusses here a few month back) which means that the
manager has to wait until all pending commands are done and the
data
is received, then switch the sample rate, get the current time
(as the
processing/download of the data in the other thread may take some
time), again add a few hundred ms and continue.
Actually I am currently quite pissed as I run into one bug after
another and cannot continue my actual work. I found like another
three
critical bugs, but I cannot reporoduce them in smaller programs
and I
do not have the time to debug the full UHD library. So I write one
workaround after another.
Best regards,
Fabian
Also, get_time_now() is controlled by set_command_time(). So, for
example, if you have two threads issuing control commands, and one thread
issues a set_command_time(), and then another thread issues a
get_time_now() while there's a set_command_time() window pending, it will
be controlled by the set_command_time(). The USRP device has zero
concept of threading, per se, so it's up to the application to keep track
of stuff like this.
------------------------------------------------------------------------
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
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
