[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: George Nychis
Subject: Re: [Discuss-gnuradio] inband packet encoding/decoding daemon
Date: Thu, 29 Mar 2007 01:45:28 -0400
User-agent: Thunderbird 2.0b2 (X11/20070306)

Eric Blossom wrote:
> This is probably overkill, but hey, it's only a data structure...

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]