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
