[USRP-users] timed_command

Josh Blum josh at ettus.com
Fri Sep 6 13:34:24 EDT 2013



On 09/06/2013 03:51 AM, Felix W. wrote:
> 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.
> 

The sample streams are actually independent from the command queue from
a driver standpoint. You are free to transmit and receive while the
queue is blocked processing. (The only exception is that issue stream
command for RX uses the same queue)

But because the command queue can fill and block when full, it would be
wise to issue commands that might cause blocking from a different thread
so other threads are free to deal with IQ streaming data.

I hope that helps,
-josh

> 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
>>
>>
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




More information about the USRP-users mailing list