Re: [Discuss-gnuradio] USRP control thread in GR block - how do I pass a USRP sptr?

[Nowlan, Sean]

>> In case anyone is interested, I got this to work with code similar to 
>> the following. Note that ?usrp_alias? must be fetched from an already 
>> constructed usrp_sink object, for instance using ?self.usrp.alias()?
>> in a Python-based flowgraph.

> Sean,

> Ah, interesting.

> I wrote a "uhd_nmea" block for combined USRP and host clock discipline a few 
> years ago, and
> ended up using libuhd directly.  I didn't have to worry about which block got 
> instantiated first 
> and could just use GRC without editing the generated Python script.  I did 
> have to take care that 
> it was the only block performing uhd control of device settings:
> http://files.ettus.com/manual/page_general.html#general_threading_safety

> -Andy

Thanks, Andy. I haven't yet encountered any issues from initializing USRP 
settings (freq/gain/antenna/etc.) from "main" thread and polling PPS from 
another thread, since the polling thread doesn't actually start until the main 
thread calls "start" on my OOT block until after it's finished configuring the 
USRP at startup.

Regarding the order of instantiation, I should update what I said about the 
USRP block alias: Under the USRP Sink config settings in GRC, the user can set 
the block alias under the Advanced tab. I set this to the same value as what I 
pass to my OOT block:

// gr-my-oot/include/my-oot/clock_manager.h
class MY_OOT_API clock_manager : virtual public gr::block
{
…
public:
    static sptr make(const std::string &usrp_alias);
…
}