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

[George Nychis]

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.


> 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.

>   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.

>
>
>   top-block:
>
>
>                           application
>                           control block
>                           GUI, whatever
>                               ^
>                               | cs
>                               |
>                               |
>               samples         |
>                               | cs (control/status port "tune", "interp" ...)
>              out    in        v              out    tx1
>      sig_gen<--------> smart usrp front end <---------> usrp_usb_daemon
>
>
> Also, we may want to compose the "smart usrp front end" and the
> usrp_usb_daemon, and split the control from the data ports.  Let's make
> something work, then we can revisit this when we've got some experience.
>
>> - George
>
> Eric
>