Timed commands capabilities

GNU Radio
1

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
[email protected]mailto:[email protected]

2

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)

  1. 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)

  1. 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.

  1. 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.

  1. 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