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
