Re: [Discuss-gnuradio] Extending UHD USRP Sink in out-of-tree module

[Josh Blum]

> So that is to say I'd use the standard gr_uhd_usrp_sink block for the
> data pipe and I'd create a separate USRP session from my own custom
> block to handle just the control logic (timed gain and DUC retuning
> commands, etc.)?
> 

Yup. Basically when you open a device with some address arguments, if
its already open in that process you get the same underlying device
session. So its totally ok to do this.

> It looks like you're working on exactly the types of things I'd like to do:
> 
> https://github.com/guruofquality/grextras/blob/next/lib/uhd_control_port.cpp
> 

:-)

> 
> I was thinking, since there's a limited command buffer in the USRP,
> would it make sense to add a message queue and encode timestamps and
> commands into the message? Is there a way to test the FPGA command
> buffer for fullness or some other way to prevent overflow?

The way the commands work is that they backpressure if there isnt space
in the fpga. The call to set gain for example will block the caller
until there is space in the FPGA for the command.

So, overflow I wouldnt worry about. Now blocking in the caller's context
may be undesirable. Now you probably want to minimize how much stuff is
queued up to be handled as a command in the future. But a queue and
another thread may be the way to go.

Now where should said queue and thread go? Well the user could do in the
the control logic, a block like the control one above could handle it,
or you could argue that UHD itself should do this enqueuing itself so
write only commands would never block the caller. Now that I am thinking
it out-loud, the latter actually seems like it could be in general a
helpful edition for UHD.

-josh