marcus at hostalia.de
Fri Sep 6 07:12:33 EDT 2013
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.
> 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!
> 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>>
> >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 =
> > 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
> (Somebody please correct me if I have any of this wrong!)
> USRP-users mailing list
> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users