On Sun, May 22, 2011 at 11:37 PM, Brett L. Trotter <[email protected]> wrote: > Follow up to self here- can anyone confirm whether I'm understanding > this right? > > Looks like gr_edge_vector_t is a shared/static vector with all the edges > > Say I take this guy from gr_hier_block2_detail and modify it: > > gr_edge_vector_t edges, tmp = d_fg->edges(); > gr_edge_vector_t::iterator p; > for (p = tmp.begin(); p != tmp.end(); p++) { > if ((*p).src().block() == block || (*p).dst().block() == block) { > edges.push_back(*p); > > if (GR_HIER_BLOCK2_DETAIL_DEBUG) > std::cout << "disconnect: block found in edge " << (*p) << > std::endl; > } > } > > > so that it tests to see if the block is an instance of a usrp/usrp2 > block? Would that do? Ultimately I can assume there'll only be one usrp > connected in my application, and through the one (be it source or sink) > i can get to the dboard iface for either card (rx or tx) and manipulate io? > > Assuming the above is sound, is there any potential for harm in messing > with things this way? > > And taking my original goal a step further for the sake of discussion, > what if instead of an AGC I just wanted a block that gives a handle to > the gain controls. Does GnuRadio have any facility for blocks that > aren't really part of the flowgraph in terms of moving data, but just > provide an instance of some sort of control? >
Hi Brett, Maybe I misunderstand what you are trying to do, but if you wish to access the public methods of a USRP source block from within the work method of another block that you write yourself, you can make the constructor of your custom block so that it takes a reference to the USRP object as a parameter and stores it internally, no? Alex _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
