M-block integration status

Hi Folks,

Now when the VRT implementation seems to be almost finished, what is the
status of the integration of m-block capabilities into the gnu-radio?
The functionalities described here
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00319.html
are just what we are looking for. However, if we don’t want to wait too
long, can this be achieved with m-blocks at the moment? What
functionality is missing in the m-blocks? Or has anyone solved this in
another way?

Regards,

Patrik E.

Thank you Eric!

We are glad that this is on your ‘short list’, we look forward to see
the results and try it out (assume the changes will happen in your
branch?).

We are especially interested in synchronized message passing and the
ability to tweak parameters at runtime, perhaps even alter block
connections?

On Mon, Jan 04, 2010 at 03:49:38PM +0100, Patrik E. wrote:

Hi Folks,

Now when the VRT implementation seems to be almost finished,

We’re getting there!

what is the status of the integration of m-block capabilities into
the gnu-radio? The functionalities described here
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00319.html
are just what we are looking for. However, if we don’t want to wait
too long, can this be achieved with m-blocks at the moment? What
functionality is missing in the m-blocks? Or has anyone solved this
in another way?

m-blocks are deprecated, and no further development will be done on
them.

We have a two pronged approach to achieving similar (or related)
functionality. In no particular order they are:

(1) Designing and implementing a mechanism whereby blocks can embed
isochronous metadata in a data stream, tied to specific sample
indicies. The idea is that blocks can check or set key/value pairs
over a range of sample indices. We expect the metadata for streams
that originate from a VRT source to contain the VRT Timestamp at the
appropriate sample index. The GR runtime will be extended such that
existing blocks, which are naive about this feature, will
transparently forward metadata from their inputs to their outputs.

(2) Implement per-block message queues to asynchronously receive
messages containing arbitrarily-typed payloads from other blocks, and
process them. (The first phase of this is complete, but we haven’t
advertised the feature since we’re lacking support in hier_blocks, a
high-level way to wire everything together, and are missing
documentation and examples). As part of this, GR block “work” methods
can send asynchronous messages. When a block receives a message, its
handle_msg(pmt::pmt_t msg) method is called. The runtime ensures
that handle_msg is never called while the block is in “work” and
vice-versa. That is, the runtime handles everything related to
ensuring that this feature works reliably in a multi-threaded
environment.

Both of these are on my “short-list” of work to get done. I expect
that both will be complete by the end of February.

I want to make a couple of additional observations about async message
passing (2). Async message passing allows for the creation of
blocks which:

  • Have only streaming input and/or outputs (like today)
  • Have only async message passing (no streaming i/o)
  • Have both streaming input and/or outputs and have async message
    passing

This gives us the possibility of easily bridging between the dataflow
and message passing enviroments. We expect that many “MAC-like”
features will be implemented using async message passing, while some
PHY layer stuff will continue to be implemented using the data flow
paradigm.

Adding a msg_handler to existing blocks allows block parameters to be
tweaked at runtime without fear of thread safety problems. We’ve been
kicking around some ideas for a “middle layer” that supports getting
and setting arbitrary attributes, in such a way that adding them to a
block is as simple as filling in a small table.

Regards,
Patrik E.

Thanks for your question, and if you’ve got more, please ask away!

Eric

On 01/15/2010 10:46 AM, Ben G. wrote:

it purely for the Rx side of things?

The vrt timing data is also used on the tx side. If you set the vrt time
field bits and specify a time stamp in ticks and seconds you are
essentially doing a “send_at” for usrp2 tx. -Josh

Hi Eric,

Great to have an update on how the new features are progressing.
m-blocks and the replacement features have been mentioned a few times
on this mailing list in relation to building TDMA MACs. Having VRT
metadata available in gr blocks is going to give access to timestamps
for Rx samples; will we be able to specify tight timings for Tx using
the VRT headers in the same manner? In the git VRT code I’ve noticed
that the VRT header that is passed with the Tx data to the USRP
contains timing info. Is this used by the USRP at the moment, or is
it purely for the Rx side of things?

Many thanks,

Ben

Dear List,

We are heading to the end of February, what is the status of the message
passing functionality between blocks? I’ve been looking around in the
developers branches but haven’t found anything yet…

Can someone update me, please?

Best regards,
Patrik E.

On Fri, Jan 15, 2010 at 06:46:47PM +0000, Ben G. wrote:

it purely for the Rx side of things?
The VRT frames transmitted to the USRP2 contain either no timestamp
info, or they contain both the integer and fractional seconds
timestamps. If they do not contain a timestamp, the frame is
transmitted “now” in a FIFO manner. If a frame contains a timestamp
and the “start of burst” flag is set, the frame is transmitted at that
time. If a frame contains a timestamp, and the “start of burst”
flag is not set, and we haven’t “underrun” in the middle of the burst,
the frame is enqueued into the FIFO. If a frame is late, it’s
dropped. The timestamps in the packets must be monotonically
increasing. No in-FPGA rearrangement is done.

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs