[USRP-users] timed_command

Felix W. wunsch.felix at googlemail.com
Fri Sep 6 06:51:46 EDT 2013


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>

>   ------------------------------
> *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>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
> 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/b3cb46c1/attachment-0002.html>


More information about the USRP-users mailing list