Re: [Discuss-gnuradio] Passing a USRP pointer

[Dan CaJacob]

Hey Tom,

The block worked fine with the right symblic name passed!  The amp is getting PTTed now in 3.7  Thanks for your help with this!

It still seems weird that the USRP Sink symbolic name was formatted differently, though.

Also, would it be possible to automatically register symbolic name aliases that are based on the block names created in GRC/python?  That would make the lookup a little more obvious.

Thanks!

Very Respectfully,

Dan CaJacob

On Fri, Jan 10, 2014 at 3:28 PM, Dan CaJacob <address@hidden> wrote:

Hey Tom,

We've been working on this, but we ran into a snag.  We couldn't seem to look up the usrp sink block's key.  Other blocks could be looked up with the keys we expected, just not the uhd sink.  I just un-commented a print statement in block_registry.cc so that we could see how each block actually gets registered, built it and ran a simple flowgraph.

The flowgraph is just a signal source -> throttle -> uhd sink.  Here's the output:

register_symbolic_name: top_block0
register_symbolic_name: gr uhd usrp sink0 
register_symbolic_name: throttle0
register_symbolic_name: sig_source_c0 

The UHD sink block gets an unexpected "gr" pre-pended and the underscores are replaced with spaces.

We are going to attempt our OOT blocks with this in mind, but I thought I'd give you a heads up on this behavior.

Thanks!

Very Respectfully,

Dan CaJacob

On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau <address@hidden> wrote:

On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob <address@hidden> wrote:
> Hey Tom,
>
> Here's some more detail into our problem.
>
> When running the flowgraph, we get the following error:
>
> File "/usr/local/lib/python2.7/dist-packages/sq/sq_swig.py", line 679, in
> make
>     return _sq_swig.usrp_pa_control_make(*args, **kwargs)
> TypeError: in method 'usrp_pa_control_make', argument 1 of type
> 'gr::uhd::usrp_sink::sptr'
>
> When setting up a FG, the pa-control block accepts a reference to the
> downstream UHD sink.
>
> I have attached the specific block source.
>
> Thanks!
>
> Very Respectfully,
>
> Dan CaJacob

It's probably the difference between a gr::uhd::usrp_sink and a
gr::uhd::usrp_sink_impl.

A safer way to handle this might be to use the new(ish) block_registry
that we implemented to handle the message passing infrastructure. You
can get a basic_block_sptr from global_block_registry.block_lookup;
you should then be able to cast this to a usrp_sink_sptr. You'll pass
it a PMT symbol containing the alias name of the UHD sink itself.

Take a look at basic_block.cc for a look at how the
global_block_registry is used. I've not done exactly this before, so
it might not go completely smoothly, and I'd be interested in your
experience.

In general, this sounds like something more appropriately implemented
as a message, though, but that would mean changing the gr-uhd code.
Having a message handler for the GPIO stuff would probably be useful
if done generically enough.

Tom

> On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob <address@hidden> wrote:
>>
>> Thanks Tom,
>>
>> No problem.  I hope you and the rest of the community had relaxing
>> holidays!  I hope to have some better info for you by tomorrow, if not
>> before.
>>
>> Another way to look at this is: does it make sense to keep doing things
>> this way?  Is there a better way to reference the downstream USRP and toggle
>> the IO?  I could imagine an async message stream or specific stream-tags,
>> but both would probably require changes to the actual UHD sinks.  I'm not
>> sure our use case is generic enough to warrant that.
>>
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>>
>> On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau <address@hidden> wrote:
>>>
>>> On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob <address@hidden>
>>> wrote:
>>> > We are upgrading some of our custom blocks for 3.7 and have run into a
>>> > snag.
>>> > Our 3.6 era blocks included one that PTTed an external amplifier based
>>> > on
>>> > stream tags.  The IO was generated from the extra GPIO available on the
>>> > WBX.
>>> > One of the inputs to the block was a reference to the USRP sink
>>> > downstream
>>> > in the FG.  The block then calls the necessary methods to enable and
>>> > disable
>>> > the GPIO.  Everything worked nicely, but when we ported our blocks to
>>> > 3.87,
>>> > there seemed to be a problem with this.  I did not personally do the
>>> > testing, so I don't have the exact error, but I can probably re-create
>>> > it
>>> > given some time.
>>> >
>>> > I started the porting of the blocks myself and did notice that getting
>>> > the
>>> > pointer to a USRP object had changed.  But the blocks built without
>>> > error
>>> > when updated appropriately.
>>> >
>>> > Is there anything in principle that would prevent this from working in
>>> > 3.7?
>>> > Or, is there a better approach to controlling the WBX GPIO based on
>>> > stream
>>> > tags that we should consider?
>>> >
>>> > I apologize for the vagueness on the actual error.  I'll try to
>>> > reproduce it
>>> > myself in the meantime.
>>> >
>>> > I can probably post the code for the PTT-controlling block if that
>>> > would be
>>> > any help.
>>> >
>>> > Very Respectfully,
>>> >
>>> > Dan CaJacob
>>>
>>>
>>> Hi Dan,
>>>
>>> Sorry for the silence. Partly due to the holidays, partly due to me
>>> not having a good answer for you. Most likely, your problem is related
>>> in some way to the public/private implementations that we are
>>> enforcing in 3.7 now. If you have more information or have figured
>>> this out, let us know and we can see where we need to go from here.
>>>
>>> Tom
>>
>>
>