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
