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 <dan.caja...@gmail.com> 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 <t...@trondeau.com> wrote:
>
>> On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob <dan.caja...@gmail.com>
>> 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 <dan.caja...@gmail.com>
>> 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 <t...@trondeau.com> wrote:
>> >>>
>> >>> On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob <dan.caja...@gmail.com>
>> >>> 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
>> >>
>> >>
>> >
>>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to