On Thu, Mar 29, 2007 at 01:45:28AM -0400, George Nychis wrote: > > > Eric Blossom wrote: > > This is probably overkill, but hey, it's only a data structure... > :D > > > For now, ignore the fact that the daemon will be running in another > > address space. We'll sort that out later. Assume that you've got a > > application (top level mblock) that contains an mblock based > > output generator with a single output port which is connected to the > usrp_usb_daemon port "tx2" (which of the tx ports it's attached > > to is arbitrary. If we ever implement "replicated ports", there will > > two ports, rx and tx, each of which are replicated). > > > > top-block (contains these two blocks): > > > > "out" "tx2" > > output generator <------------------> usrp_usb_daemon > Simple and straight forward, understand this now.
Good. > > > In real life there's probably another block or two in front of the > > usrp_usb_daemon that handles this kind of stuff. This would include > > the "tuning/control interface" etc. > I like the idea of this. OK. > > In that case, the dumb signal > > generator would just send packets containing sample to be transmitted. > This "dumb signal generator" would be implemented as an m-block though, > correct? the smart usrp front end is only dealing with m-block packets as > its input, where you've marked 'samples' you mean the m-block packet > payload contains samples, yes/no? Just want to make sure. Yes. Everything is mblocks and messages. Some of the messages contain vectors of samples. Once this is sorted out, embedding a flow graph in an mblock shouldn't be a big deal. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
