[USRP-users] Trying to understand multi_usrp::set_command_time

Carel Combrink carel.combrink at gmail.com
Thu Oct 29 02:20:13 EDT 2015


I am trying to set timed commands using multi_usrp::set_command_time() but
it is not behaving as I am expecting and the documentation is not very
clear around this command.

What I want to achieve:
While transmitting bursts, I want to schedule a GPIO pin to go high and
then low after a small time.
Pseudo code:
set_gpio_attr(pin high)
set_gpio_attr(pin low)

1. This works correctly, but I am wondering how many commands can be queued
like this?
2. Do I need the clear_command_time call between the first set_gpio and the
seconds set_command_time?

Now the part that I do not understand: I added a printout of get_time_now()
before and after the above code and get the following output (code not
given since from the output it should be clear):
Start Time:  1446018188.316676090000000
High      :  1446018193.004600000000000
Low       :  1446018193.004602000000000
End Time  :  1446018193.004602140000000

So it seems like somewhere the software gets blocked and waits for the
command to be executed before it continues.

So after some investigation and tests I added a timer to the code to time
the execution of the different commands with the following output:
Start Time    :  1446018640.315072090000000
T now() 1 (ns):  68523
High          :  1446018645.004600000000000
Low           :  1446018645.004602000000000
T cmds    (ns):  139416
End Time      :  1446018645.004602140000000
T now() 2 (ns):  4689572696

I first time the get_time_now() command, followed by the time for all of
the code described above, then time the call to the last get_time_now().
>From this it seems like the last get_time_now() only returns after the time
elapsed for the last timed command.

Is this expected, is there a bug or is my test logic wrong?

My code works correctly, but I had to remove a few calls to get_time_now().

Device: X310 over GigE
UHD version: UHD_003.009.000-7-g8adefb1d
OS: Ubuntu Linux

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151029/326eaf21/attachment-0002.html>

More information about the USRP-users mailing list