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
