Fabian,
It probably helps to try to understand the hardware a little, and then the way
that timed commands operate will be a little bit more intuitive.
Only certain parts of the actual USRP have access to accurate time (Those parts
running on the so called “Radio clock” which is an integer mult
Hi,
thanks for clarification.
It would be great if there would be a more detailed description of the
timed command behaviour on the wiki. For example a list clarifying which
commands are affected by set_command_time and which are not. The fact
that switching sample rates using timed commands s
On 04/24/2019 04:16 AM, Fabian Schwartau via USRP-users wrote:
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
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
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"
:
>On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:
>
I have only one thread sending commands and another one receiving the data. So
there should be no issue.
Am 23. April 2019 22:38:01 MESZ schrieb "Marcus D. Leech via USRP-users"
:
>On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:
>> Hi,
>>
>> well, ...
>> I am recording small slot
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, s
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"
:
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, s
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
a
On Tue, Apr 23, 2019 at 2:06 PM Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> 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,
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
sens
12 matches
Mail list logo
