How am I supposed to keep track of the time from the meta data of the received
packets if I do not receive packets? As I said, I sometimes have long times of
not receiving anything when the old data is being processed.
Am 23. April 2019 22:22:52 MESZ schrieb "Marcus D. Leech via USRP-users"
<[email protected]>:
>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
>>
>So, you do know that every single sample buffer from UHD includes a
>time-stamp as seen by the USRP? If you know the sample rate, you know
> exactly when every single sample arrived, and you can use that as a
>"clock keeper".
>
>If you cannot reproduce the behavior in smaller programs, then I would
>humbly suggest that your problems have to do with your
> overall architecture, and some "buried subtleties".
>
>
>>
>> Am 23.04.2019 um 20:29 schrieb Brian Padalino:
>>> On Tue, Apr 23, 2019 at 2:06 PM Fabian Schwartau via USRP-users
>>> <[email protected] <mailto:[email protected]>>
>wrote:
>>>
>>> Hi everyone,
>>>
>>> I just found another strange thing. Can get_time_now() be in any
>
>>> case
>>> blocking? Like long blocking? It takes more than 1 second to
>return!
>>> I am heavily using timed commands, but I tried a
>>> clear_command_time()
>>> before calling get_time_now() with no effect. It would also make
>no
>>> sense at all to be able to set a command time for
>get_time_now().
>>> According to documentation the command just reads the registers
>>> in the
>>> USRPs and returns them - no need to wait for anything.
>>> Any ideas?
>>>
>>>
>>> Reading registers isn't the fastest thing in the world, but you
>>> shouldn't be utilizing get_time_now() heavily for a real time
>>> system. Taking a second sounds like something is wrong, but I'm
>>> still curious why you're constantly asking for the time.
>>>
>>> The idea behind that is to understand the current time the radio
>has,
>>> figure out what you want to do when you first start a stream or do
>>> something, then use sample counting to understand when things are
>>> supposed to be happening.
>>>
>>> So, why do you keep asking for the time? What's the use case you're
>
>>> trying to figure out?
>>>
>>> Brian
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>_______________________________________________
>USRP-users mailing list
>[email protected]
>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
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
