Forum: GNU Radio Timed commands capabilities

Hi all,

Has anyone pushed timed commands to their limits? I have a few 
questions:

1) How many commands fit in the queue?
2) How far in the future can you schedule a timed command?
3) Does the set_command_time() call (and subsequent command call) block? 
Should these take roughly as much time as the RTT over Ethernet to an 
N200?
4) I don't necessarily want to call timed commands from the top level 
GNU Radio flowgraph. I want to delegate that to a custom GNU Radio 
block. Can commands to the USRP be called from a GNU Radio block other 
than uhd_usrp_source/sink? If so, what's the best way to communicate 
between the threads?
5) If I can't do #4 due to GNU Radio's architecture, would it make sense 
to use stream tags to associate a parameter change (like gain or 
frequency) with a sample in the stream and implement the timed command 
calls in gr_uhd_usrp_source/sink blocks acting when it sees the tags?

Thanks,

Sean Nowlan

------------------------------

Sean M. Nowlan
Research Engineer I
ICL/CNSD
Georgia Tech Research Institute
250 14th St NW, Suite 470
Atlanta, GA 30318

404.407.7952
sean.nowlan@gtri.gatech.edu<mailto:sean.nowlan@gtri.gatech.edu>

On 10/21/2012 07:40 PM, Nowlan, Sean wrote:
> Hi all,
>
> Has anyone pushed timed commands to their limits? I have a few
> questions:
>
> 1) How many commands fit in the queue?

16 because its implemented in an SRL16 fifo

(it could be arbitrary, just an FPGA change away)

> 2) How far in the future can you schedule a timed command?

10s which is just some arbitrary large timeout

(any more and the host spits a command not ack'd error)

> 3) Does the set_command_time() call (and subsequent command call)
> block? Should these take roughly as much time as the RTT over
> Ethernet to an N200?

set_command_time() is actually devoid of any communication. Its just
setting a property

subsequent commands will only block (aka wait for an ack) if the command
queue has become full, or a read operation is requested.

> 4) I don't necessarily want to call timed commands from the top level
> GNU Radio flowgraph. I want to delegate that to a custom GNU Radio
> block. Can commands to the USRP be called from a GNU Radio block
> other than uhd_usrp_source/sink? If so, what's the best way to
> communicate between the threads?

We have actually done this in pre-cog using the PMC RPC block from
grextras. A block actually passes a message to the RPC block, which
invokes a method on the usrp source/sink. This could be to set the
command time.

The code works, but might look a little funny. I am working (as we
speak) on making it possible to deal with native python objects, rather
than PMTs when working within python.

> 5) If I can't do #4 due to GNU Radio's architecture, would it make
> sense to use stream tags to associate a parameter change (like gain
> or frequency) with a sample in the stream and implement the timed
> command calls in gr_uhd_usrp_source/sink blocks acting when it sees
> the tags?
>

An alternative to #4, would be to not RPC, but put a control message
input into the UHD source/sink to also send commands.

So, you can do #4 now. #5 is a future endeavor, but probably the right
way to do it.

-josh