Constant output message source

GNU Radio
1

Hi,

I was wondering if there is a method to have a source block constantly
sending out “0” and once it recieves a message from python, e.g a
packet, it
will then stream the message and switch back to sending “0” when done.

I’ve tried:
Message Source ----------------------------> (Add, 0)
Constant Source/Vector Source with 0 -----> (Add, 1) —> output

However, the add block (and all blocks in gnuradio) waits for stream
items
from both inputs to be ready (i.e no interpolation) before making a
output
stream item. This effectively nullifies the const source in the above
example.

I was wondering if there is any possible way to solve this problem?

The reason I am asking this is I am using a dual TX setup on a single
USRP
which interleaves output signals. I have I output signal that is
constantly
sending (beacon) and one that is only sending sometimes, however the
interleaving of output signals means that both streams needs to be
constantly sending.

View this message in context:
http://old.nabble.com/Constant-output-message-source-tp30964604p30964604.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On Sat, Feb 19, 2011 at 4:52 AM, ichigo.san [email protected]
wrote:

Constant Source/Vector Source with 0 -----> (Add, 1) —> output
sending (beacon) and one that is only sending sometimes, however the
interleaving of output signals means that both streams needs to be
constantly sending.

Right, the add block needs to see items from both streams so that it can
add
them together. If there is no data on one stream, there is nothing to
add
and it does not assume zeros.

My advice is to make a new block. The easiest would probably to make a
new
add block that inherits from gr_block instead of gr_sync_block. In this
block, you tests the length of both inputs and add which items together
that
you want, substituting zeros when there is no more data on the incoming
message stream. It will be pretty specific to your needs, and be careful
with your consume() and return item numbers to account for what you’ve
done
with both streams.

Tom

3

Cool thanks for the reply.

The reason I am doing this is because I am trying to transmit signals at
different times… and testing shows the interleave block acts like the
sync
type blocks you mention. I am guessing the same idea can be applied and
make
a new interleave block and inherits from the gr_block.

Though I am just wondering that this has to be a common problem with the
dual usrp TX usage, I was wondering if anyone else has done similar work
already or has an more “standard” solution using the tools already built
into GNU radio. As I am not too familiar with the build toolchain and
the
C++ backbones behind the python, however I will be reading up on it now.

Tom R. wrote:

message stream. It will be pretty specific to your needs, and be careful

–
View this message in context:
http://old.nabble.com/Constant-output-message-source-tp30964604p31029150.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

On Sun, Feb 27, 2011 at 6:22 PM, Tom R. [email protected]
wrote:

Message Source ----------------------------> (Add, 0)
which interleaves output signals. I have I output signal that is
block, you tests the length of both inputs and add which items together that
you want, substituting zeros when there is no more data on the incoming
message stream. It will be pretty specific to your needs, and be careful
with your consume() and return item numbers to account for what you’ve done
with both streams.
Tom

I tried to implement this. Instead of obeying noutput_items, my
general_work function takes the maximum in ninput_items[] and produces
that quantity instead:

------8<---------
//declare in_f_xxx from input_items[xxx]

int num_out = std::max(ninput_items[0], ninput_items[1]);
for (int i = 0; i < num_out; i++) {
float acc = 0;
if (ninput_items[0] > i) acc += in_f_0[i];
if (ninput_items[1] > i) acc += in_f_1[i];
*optr++ = (float) acc;
}

consume(0, std::min(ninput_items[0], num_out));
consume(1, std::min(ninput_items[1], num_out)); //probably
consume(1,num_out), but if port1 is constant 0 it shouldnt matter
produce(0, num_out);

return WORK_CALLED_PRODUCE;
------8<---------

I also implemented forecast() requiring only the second input to have
samples:
ninput_items_required[1] = noutput_items;

However, the logic still seems incorrect and I couldn’t write a
meaningful test code with a small number of samples and a
gr_message_source block. There seems to be some kind of race condition
on the thread running this which allows it to write a bunch of zeroes
even when there are samples in the first input port.

My interest in this is in writing a PHY simulator. I have a channel
whose impulse response includes the propagation time and my
understanding so far is that the convolution tail of the FIR filter
was being “cut off” since there were no more incoming samples from the
message stream. Because of that, the last symbol was always
incomplete, so I figured this non-blocking adder would help me get the
tail out of the channel memory.

If anyone has suggestions for this I would be happy to read.

–
Igor A.