Re: [Discuss-gnuradio] Constant output message source

[Igor Almeida]

On Sun, Feb 27, 2011 at 6:22 PM, Tom Rondeau <address@hidden> wrote:
> On Sat, Feb 19, 2011 at 4:52 AM, ichigo.san <address@hidden> wrote:
>>
>> 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.
>
> 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

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 Almeida