[USRP-users] timed_command

Marcus Müller marcus at hostalia.de
Fri Sep 6 07:12:33 EDT 2013


Hi Felix,

Since all commands (that fall under the timed command category, I really 
don't know which don't, could someone comment on that?) can't be issued 
out-of-order, you must take care of correct timing yourself.
I'm afraid the only way to do this is have your own command queue -- use 
a priority queue based on command time, check it periodically or have 
your own timers that issue your timed commands as late as necessary.

Greetings,
Marcus


> Hi list,
>
> as I need similar functionality and this thread is not too old, I will 
> pose my question right here:
>
> Is there a way to re-tune the USRP at a specific time without blocking 
> until then?
>
> Background: My application gets IQ samples and control information (-> 
> tuning commands) asynchronously from a higher layer. So it can happen 
> that I know when to change the center frequency but I don't have all 
> the samples to be sent until then (and maybe there won't even be a 
> continous sample stream). Of course this can be handled with some 
> logic, but maybe there is an easier way? The ideal solution for me 
> would be to be able to handle tuning information and IQ streams as 
> independently as possible.
>
> I'm thankful for any thoughts on this!
>
> Greetings,
> Felix
>
>
>
> 2013/9/4 Nowlan, Sean <Sean.Nowlan at gtri.gatech.edu 
> <mailto:Sean.Nowlan at gtri.gatech.edu>>
>
>     ------------------------------------------------------------------------
>     *From:* Sam mite [mite.engr11 at gmail.com
>     <mailto:mite.engr11 at gmail.com>]
>     *Sent:* Wednesday, September 04, 2013 5:37 AM
>     *To:* Nowlan, Sean
>     *Cc:* usrp-users at lists.ettus.com
>     <mailto:usrp-users at lists.ettus.com>; josh at ettus.com
>     <mailto: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.set_command_time(t1+0.02)
>         >usrp.set_center_freq(uhd.tune_request(f1,LO))
>         >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.set_command_time(5.0+3.0)
>         >usrp.set_center_freq(uhd.tune_request(f1,LO))
>         >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
>     >^C
>     >
>     >
>     >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!)
>
>         --sean
>
>
>     --
>     Sam
>
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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


More information about the USRP-users mailing list