Re: [Discuss-gnuradio] inband packet encoding/decoding daemon

[Eric Blossom]

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