On Tue, Jan 14, 2014 at 9:09 PM, Dan CaJacob <dan.caja...@gmail.com> wrote: > 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!
Great! > It still seems weird that the USRP Sink symbolic name was formatted > differently, though. Hm, yes, that is odd. Would you open a ticket about it? Low priority and a change in behavior that might have to wait for 3.8. > 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. Which names, exactly? Are you talking about the variable name itself? For that, there's no way for the block to know that information. On the other hand, you can actually set the block alias yourself so you don't have to ask/guess/know what it is in advance using the set_block_alias(string) function. Tom > 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
