[USRP-users] timed_command

Nowlan, Sean Sean.Nowlan at gtri.gatech.edu
Wed Sep 4 09:33:52 EDT 2013

From: Sam mite [mite.engr11 at gmail.com]
Sent: Wednesday, September 04, 2013 5:37 AM
To: Nowlan, Sean
Cc: usrp-users at lists.ettus.com; josh at ettus.com
Subject: Re: [USRP-users] timed_command

On Tue, Sep 3, 2013 at 6:39 PM, Nowlan, Sean <Sean.Nowlan at gtri.gatech.edu<mailto:Sean.Nowlan at gtri.gatech.edu>> wrote:
>When I use set_command_time(), flow graph or USRPN210 seems to hang up. For example,
>while 1:
>t1 = usrp.get_time_now().get_real_secs()
>usrp.clear command_time()
>flow graph/USRP doesn't run smoothly. What could be the issue? How many commands could be in a queue at a time?

My understanding is that there are only on the order of 16 slots in the command queue implemented on the USRP. Also, the commands will time out after something like 10 seconds, so you have to make your control thread sleep an appropriate amount of time so you stay within that timeout window on every command.

>Hi thanks for your response. I am issuing commands that would be executed within 10 seconds i.e usrp.set_command_time(current_time+6.0) at maximum so I think timeout would not b a problem.

That might be true unless your while loop is going too quickly. Either you're filling up the command FIFO faster than the commands are being executed, or you're violating the 10 second timeout, or something else I haven't thought of. Can you confirm that you don't see an error like, "RuntimeError: RuntimeError: fifo ctrl timed out looking for acks"? If you see that error, it indicates that you sent a command >10s before its command time.

>One more question. Lets say current USRP time is 5.0 seconds. I give the following commands to USRP
>usrp.clear command_time()
>print usrp.get_time_now().get_real_secs()
>what would be print 5.0+something or 8.0+something? What I get from the UHD documentation is that if there is already a timed >command waiting in queue, new commands will be executed after the waiting timed command has been executed. Is that right?

I think that none of those calls block, so the time should be 5.0 + some small delay. Also I think get_time_now is independent of the timed commands and command queue.

>When I run following code, tb is the flow-graph generated by the files that comes with gnruadio gr-uhd/examples/grc/uhd_dpsk_mod.grc
>    tb.start()
>    while 1:
>        current_t = tb.uhd_usrp_sink_0.get_time_now().get_real_secs()
>        print "Current time is %0.5f" % current_t
>        tb.uhd_usrp_sink_0.set_command_time(uhd.time_spec(current_t+5))
>        tb.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(2.45e9+2e6,5e6))
>        tb.uhd_usrp_sink_0.clear_command_time()
>        current_t1 = tb.uhd_usrp_sink_0.get_time_now().get_real_secs()
>        print "Time after cmd exec is %0.5f" % current_t
>        time.sleep(1)
>I get this output:
>Current time is 453.252037410
>Time after cmd exec is 458.252461970
>Current time is 459.254496020
>Time after cmd exec is 464.254934280
>Current time is 465.256998630
>That means their is some blocking call. Or there is something I am doing wrong. I don't want this behavior. Any further comments from somebody whats happening here ?

On second thought, sending a command packet (with a command call like set_center_freq) /does/ block waiting for an ACK from the USRP. I believe set_command_time and clear_command_time just change a timestamp in the command metadata before the command is sent out. If no command time is used (i.e., it's cleared/zero) the command packet should be ACKed after some small delta. However if you set a command time of N seconds into the future, the ACK won't come until N+delta seconds later, after the command is actually executed (like changing freq). But the function that waits for an ACK is designed to timeout after 10 seconds, so if N+delta > 10s, it throws an error. Take a look at uhd/host/lib/usrp/common/fifo_ctrl_excelsior.cpp to see how this works.

(Somebody please correct me if I have any of this wrong!)


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

More information about the USRP-users mailing list