Re: [Discuss-gnuradio] Timed commands capabilities

[Josh Blum]

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