Fundamentals of block-connections, message queue etc

GNU Radio
1

Hi everyone,
I’m trying to get a grip of how the software code works in gnuradio. At
the moment I’m looking at the bbn 802.11b rx implementation.

I would like to understand how the data stream is transported from the
usrp source block and further to the rest of the processing blocks that
are connected together. There is a message queue involved, but how and
where is the data added to the queue? Is there another way of putting
data in the message queue than using the inset_tail function?

I have read the general documentation on how the gnuradio code is built
by David Shen, and I have also been reading the gr code, but I still
can’t seem to figure it all out. Can someone please point me in the
right direction on where to look for this kind of documentation?

Thanks!
/Ulrika

2

Within the BBN RX side, all the processing blocks are stuck together so
that
data “streams” from each block to the next. In the final block, when a
packet is successfully decoded it is loaded in a message queue. The
loading
into the message queue is done within the C++ code, not the python.

There is another thread running that will sleep on an empty queue and
will
not wake up until something is inserted into the queue. When a message
enters the queue, the thread wakes up, takes out the message and then
prints
it out via a call back function.

Check the source code for the message queue to see if there is another
function to add a message.

Thanks,
Colby

3

Hi Colby,

Based on what you said, is that means, at Tx side, the encoded data
stream
from encoder should also be loaded into gr.msg_queue() and applies
delete_head() funtion?

Thank you,

Milo

4

Thank you very much for your explenation Colby! I now understand how the
message queue is used in the rx code.

However, I would still like to know more about how the data is
transported between for example the usrp block and the next block (in
the 802.11b rx case this would be the resampling block). If I understand
it right, the usrp sends frames of data including a header, timestamp
and a number of data samples. When connecting the blocks in the python
code, where does the transformation from frames into a stream happen?
I’ve tried to read the code and documentation about the connection and
starting of flow graphs, but I could still use some hints…

Tnx,
/Ulrika

Från: Colby B. [mailto:[email protected]]
Skickat: den 26 augusti 2009 05:09
Till: Ulrika U.
Kopia: GNU Radio D.ion
Ämne: Re: [Discuss-gnuradio] fundamentals of block-connections, message
queue etc.

Within the BBN RX side, all the processing blocks are stuck together so
that data “streams” from each block to the next. In the final block,
when a packet is successfully decoded it is loaded in a message queue.
The loading into the message queue is done within the C++ code, not the
python.

There is another thread running that will sleep on an empty queue and
will not wake up until something is inserted into the queue. When a
message enters the queue, the thread wakes up, takes out the message and
then prints it out via a call back function.

Check the source code for the message queue to see if there is another
function to add a message.

Thanks,
Colby

5

Hi Milo,
As I understand (if we’re still are talking about the 802.11b code), the
tx side uses multiple message queues “in between” the processing blocks
to handle the different data rates. I’m not sure I understand your
question, but yes the detete_head() function is used to extract messages
from the queue. Take a look in the bbn_80211b_pkt.py and I think you
will see how the message queues are used there.

/Ulrika

Från: Milo W. [mailto:[email protected]]
Skickat: den 26 augusti 2009 06:47
Till: Colby B.
Kopia: Ulrika U.; GNU Radio D.ion
Ämne: Re: [Discuss-gnuradio] fundamentals of block-connections, message
queue etc.

Hi Colby,

Based on what you said, is that means, at Tx side, the encoded data
stream from encoder should also be loaded into gr.msg_queue() and
applies delete_head() funtion?

Thank you,

Milo

On Tue, Aug 25, 2009 at 8:08 PM, Colby B. [email protected]
wrote:

Within the BBN RX side, all the processing blocks are stuck together
so that data “streams” from each block to the next. In the final block,
when a packet is successfully decoded it is loaded in a message queue.
The loading into the message queue is done within the C++ code, not the
python.

There is another thread running that will sleep on an empty queue and
will not wake up until something is inserted into the queue. When a
message enters the queue, the thread wakes up, takes out the message and
then prints it out via a call back function.

Check the source code for the message queue to see if there is another
function to add a message.

Thanks,
Colby

On Tue, Aug 25, 2009 at 8:08 AM, Ulrika U. [email protected]
wrote:

Hi everyone,
I'm trying to get a grip of how the software code works in gnuradio.

At the moment I’m looking at the bbn 802.11b rx implementation.

I would like to understand how the data stream is transported from

the usrp source block and further to the rest of the processing blocks
that are connected together. There is a message queue involved, but how
and where is the data added to the queue? Is there another way of
putting data in the message queue than using the inset_tail function?

I have read the general documentation on how the gnuradio code is

built by David Shen, and I have also been reading the gr code, but I
still can’t seem to figure it all out. Can someone please point me in
the right direction on where to look for this kind of documentation?

Thanks!
/Ulrika

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

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

6

As far as the usrp->gnuradio block goes - the frame to stream
‘conversion’ happens in the usrp (or usrp2) source block (and on the
tx side that similarly gets hidden by the sink block). You can look in
the gr-usrp (or gr-usrp2) directories to see how that happens. But in
general, you don’t have to worry about what format the samples get
to/from the usrp in, that’s taken care of by the gr-usrp blocks.

For learning about some of the basics of GNURadio, I’d recommend
looking at some of the simpler examples (802.11 is not the simplest
standard to deal with) in the gnuradio-examples directories (the
digital-bert example for example).

On Wed, Aug 26, 2009 at 7:23 AM, Ulrika U.[email protected]
wrote:

Thank you very much for your explenation Colby! I now understand how the message queue is used in the rx code.

However, I would still like to know more about how the data is transported between for example the usrp block and the next block (in the 802.11b rx case this would be the resampling block). If I understand it right, the usrp sends frames of data including a header, timestamp and a number of data samples. When connecting the blocks in the python code, where does the transformation from frames into a stream happen? I’ve tried to read the code and documentation about the connection and starting of flow graphs, but I could still use some hints…

Tnx,
/Ulrika

–
Doug G.
[email protected]

7

I haven’t looked into how the samples come from the USRP to the PC.
Perhaps
the usrp2 source block will tell more?

8

Thank you both very much for your responses Doug and Colby. I have now
gone through the code in gr-usrp2 and usrp2/host thoroughly and I can
see how the data is handled before sent on to the processing blocks.

I can also see that the metadata is discarded at a point, and I found
some post in the archive about that this will be changed in later
releases. I’m curious if anyone knows if this is something anyone is
working on at the moment?

/Ulrika

-----Ursprungligt meddelande-----
Från: Douglas G. [mailto:[email protected]]
Skickat: den 26 augusti 2009 19:33
Till: Ulrika U.
Kopia: GNU Radio D.ion
Ämne: Re: [Discuss-gnuradio] fundamentals of block-connections, message
queue etc.

As far as the usrp->gnuradio block goes - the frame to stream
‘conversion’ happens in the usrp (or usrp2) source block (and on the tx
side that similarly gets hidden by the sink block). You can look in the
gr-usrp (or gr-usrp2) directories to see how that happens. But in
general, you don’t have to worry about what format the samples get
to/from the usrp in, that’s taken care of by the gr-usrp blocks.

For learning about some of the basics of GNURadio, I’d recommend looking
at some of the simpler examples (802.11 is not the simplest standard to
deal with) in the gnuradio-examples directories (the digital-bert
example for example).

–
Doug G.
[email protected]

9

On Thu, Aug 27, 2009 at 11:00 AM, Ulrika U.[email protected]
wrote:

Thank you both very much for your responses Doug and Colby. I have now gone through the code in gr-usrp2 and usrp2/host thoroughly and I can see how the data is handled before sent on to the processing blocks.

I can also see that the metadata is discarded at a point, and I found some post in the archive about that this will be changed in later releases. I’m curious if anyone knows if this is something anyone is working on at the moment?

/Ulrika

As I understand it that is currently waiting on the message-passing
functionality (which is putting the main functionality of mblocks into
the standard gnuradio block API). I would imagine it will actually
show up with/after the switch to the VRT format (vs. the current raw
ethernet frames + thin custom header).

In the meantime, if you need the information you could create a custom
usrp2 source block which saved the metadata somewhere. Not for the
faint of heart perhaps, but certainly doable. Then the real question
becomes what you want to do with the metadata (e.g. do you just want
to use it in the source block, or do you want to pass it along to the
subsequent block(s)).

Doug

–
Doug G.
[email protected]