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
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
