Mblocks

Dear all,

I am currently developping a cognitive radio demonstration system under
the GNU Radio Platform and I am particularly interested in the mblocks
extension proposed by the ADROIT Project. Reading the available
documentation and looking to the source code, I realized that the
extension is still a work in progress and I would like to know if
mblocks are already available as a base class for deriving my own signal
processing blocks. Inspecting the mblock directory, I’ve noticed that
there are no .i files nor .py so the extension seems unavailable as a
Python module. Consequently, I would like to ask you some questions:

  • Is the current mblock directory exploitable and bug proof?
  • May I use it as a base class for deriving my own signal processing
    blocks?
  • If I create an interface file for the mblock extension and if I
    generate all other files (.so, .py, .o …), will I be able to interface
    my own module with Python?

For your information, this project is part of a PhD thesis at France
Telecom R&D (French telecommunications company) focusing on integrating
cognitive mechanisms into radios.

Thank you in advance for your answer (and for the work done with this
extension, particularly attractive for cognitive applications).

Best regards,

Nicolas Colson
R&D Engineer, PhD Student
France Telecom R&D/TECH/IDEA/IROC
[email protected]


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Thanks for the answer.
Would it be possible to have a look at the status report on what’s done
and what’s left to be done for m-blocks. We may consider contributing to
the code.
We are particularly interested in:

  • the metadata exchange for sending reconfiguration orders
  • the interface with gr-blocks for using previously build modules
  • an effective scheduler capable of assuring on the fly reconfiguration
    withouth data interruption

Nicolas Colson

-----Message d’origine-----
De : [email protected]main.invalid
[mailto:[email protected]main.invalid]
De la part de Greg T.
Envoyé : vendredi 23 mars 2007 14:17
À : EVENNOU Frederic RD-TECH-GRE
Cc : [email protected]
Objet : Re: [Discuss-gnuradio] Mblocks

“EVENNOU Frederic RD-TECH-GRE” [email protected]
writes:

I am currently developping a cognitive radio demonstration system
under the GNU Radio Platform and I am particularly interested in the
mblocks extension proposed by the ADROIT Project. Reading the
available documentation and looking to the source code, I realized
that the extension is still a work in progress and I would like to
know if mblocks are already available as a base class for deriving my
own signal processing blocks.

The code that is there is there and you’re welcome to start hacking, but
you’d be the first user - there aren’t examples already in the tree,
which is a sign that this won’t (yet) be that easy.

Inspecting the mblock directory, I’ve noticed that there are no .i
files nor .py so the extension seems unavailable as a Python module.
Consequently, I would like to ask you some questions:

  • Is the current mblock directory exploitable and bug proof?

Certainly not - and probably the rest of the code isn’t. I’m not sure
what you’re really getting at. Most of GNU Radio seems to run pretty
reliably, but your using ‘proof’ makes me wonder about your
requirements.

  • May I use it as a base class for deriving my own signal processing
    blocks?

You may, but you will surely have to dig in and really understand what’s
going on, and supply some missing pieces.

  • If I create an interface file for the mblock extension and if I
    generate all other files (.so, .py, .o …), will I be able to
    interface my own module with Python?

Yes, but be warned that this is likely considerable work.

Sorry if I’m sounding like I’m just telling you that you need to read
and understand all the code that’s already present, and that sure you
can do all of it but it’s a lot of work, but that’s how I see it.
Contributions of code are always welcome (FSF assignment required as for
all GNU projects).

For your information, this project is part of a PhD thesis at France
Telecom R&D (French telecommunications company) focusing on
integrating cognitive mechanisms into radios.

Thank you in advance for your answer (and for the work done with this
extension, particularly attractive for cognitive applications).

Perhaps Eric can give a status report on what’s done and what’s left to
be done for m-blocks.

Greg T. <[email protected]>

On Tue, Mar 27, 2007 at 12:29:13PM +0200, COLSON Nicolas RD-TECH-GRE
wrote:

Thanks for the answer.

Would it be possible to have a look at the status report on what’s
done and what’s left to be done for m-blocks. We may consider
contributing to the code.

Thanks! See below.

We are particularly interested in:

  • the metadata exchange for sending reconfiguration orders

This should fall out naturally. Each message contains a data and a
metadata attribute. The interpretation of the data and metadata is up
to you. You are also free to create, delete, connect and disconnect
mblocks at runtime.

  • the interface with gr-blocks for using previously build modules

See my message from yesterday. There will be a subclass of mblock
that knows how to embedded a flowgraph within an mblock, and will
provide a means for sending and receiving data between the mblock and
the flow graph.

  • an effective scheduler capable of assuring on the fly
    reconfiguration withouth data interruption

With regard to mblocks, this won’t be a problem. Johnathan C. is
currently working on this feature for classic GNU Radio blocks. He
and I are scheduled to talk about this later today. Most of the work
is already done.

Here’s what’s left to do with mblocks (first pass):

(1) Implement a “thread per mblock” scheduler. This allows mblocks to
fully exploit SMP/SMT machines, and allows mblocks to block for i/o
while handling messages (it also simplifies the implementation.)
I expect to have this finished by the end of this week.

(2) Locking on traversal and modification of the internal data
structure that describes the mblock interconnections. I expect to
have this finished by the end of this week.

When (1) and (2) are complete the foundation of the system is basically
working.

(3) Define interface for supporting timer messages, and implement the
mechanism. That is, provide a way for mblocks to have one-time or
periodic Timeout messages sent to them.

(4) Create a tool (script) that compiles protocol class definitions
into C++ code.

(5) Cache the resolution of connections between mblocks. The code
will work without this, but caching the location of the ultimate
recipient of a message allows us to remove lots of runtime overhead
from the “send” primitive.

(6) syntactic sugar for connect / disconnect. Allow the connection to
be expressed as a single string, e.g. connect(“self:control to
transmitter:cs”)

(7) Implement serialize and deserialize (marshalling) for pmt objects.
This will allow them to be passed across process or machine boundaries.

(8) Write a couple of example applications.

(9) Create a subclass of mblock that knows how to embed a flow graph.
Create the associated sinks and sources. Write an example that uses
these.

(10) Document the differences between what’s implemented and the BBN
paper.

In addition to the mblock basics these things remain:

  • inband signaling for USRP (design currently in progress)

  • Consider revising the mblock composition API such that it is more
    declarative than functional. This could facilitate configuring
    and running a system of mblocks across a cluster or other h/w that
    lacks shared memory between processing elements.

  • Consider implementing pmt data types in a shared memory segment
    with appropriate thread-safe reference counting. This would allow
    very fast exchange of (large) messages on SMP/SMT machines.

I’m sure I’ve left things out…

Eric