discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] inband packet encoding/decoding daemon
Date: Wed, 28 Mar 2007 20:54:30 -0700
User-agent: Mutt/1.5.9i

On Wed, Mar 28, 2007 at 07:37:43PM -0400, George Nychis wrote:
> 
> 
> Eric Blossom wrote:
> >The basic idea is that there is a small piece of code that knows about
> >both abstractions and how to bridge between them.
> That seems like the best approach.
> 
> >Yes.  One daemon.
> *clicks the check box*
> 
> So this daemon will be allocating the USB channels with the different ports 
> connected to it?  Basically what we talked about on the phone earlier... 
> the methods described in:
> http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb-host

Yes.

Assume for sake of discussion that there's a mblock called
"usrp_usb_daemon" with 8 externally visible ports:

  rx0
  rx1 
  rx2
  rx3

  tx0
  tx1
  tx2
  tx3

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



> Writing an m-block, I do not want to worry about this, I am kicking my 
> packets off to the daemon, who will decide what channels to allocate and 
> such?

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.   In that case, the dumb signal
generator would just send packets containing sample to be transmitted.


  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]