Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

Dear All,

Had anyone tried to implementing a gnuradio block that will output zeros
if there are no items at the input, and will simply copy the input to
output otherwise?

I find that if there are no items at the input, the block never gets
scheduled.

I want this block to feed zeros to my USRP until actual data is ready to
be passed to it.

Regards,

David

On 06/03/2014 03:30 PM, David Halls wrote:

be passed to it.
Hey David,

any reason you can’t use eob/sob?

Also, did you set forecast accordingly?

Note that this can go wrong easily: If this blocks produces a bajillion
zeros very quickly, nothing will happen until the USRP has consumed them
all.

M

Hey Martin,

Good to hear from you as always. Gnuradio scheduling baffles me more
than anything else on this planet. The day I get my head around it will
be a happy day indeed. :0

The problem with using ‘sob’, ‘eob’ is because I have two inputs to the
USRP UHD sink. One is constantly transmitting and has items coming in
from time=0, but the other has no input items from time=0, they only
arrive later on. As a result the sink seems to block waiting for items
on both inputs before it will transmit anything. I don’t want the USRP
to have to wait for the second stream to be populated before it
transmits anything…

I thought ‘forecast’ may help me out, but wasn’t sure what to put in the
function to make it schedule even when there are no input items?

David

On 06/03/2014 03:59 PM, David Halls wrote:

Hey Martin,

Good to hear from you as always. Gnuradio scheduling baffles me more
than anything else on this planet. The day I get my head around it will
be a happy day indeed. :0

Some things aren’t meant for us mere mortals :slight_smile:

The problem with using ‘sob’, ‘eob’ is because I have two inputs to the
USRP UHD sink. One is constantly transmitting and has items coming in
from time=0, but the other has no input items from time=0, they only
arrive later on. As a result the sink seems to block waiting for items
on both inputs before it will transmit anything. I don’t want the USRP
to have to wait for the second stream to be populated before it
transmits anything…

Hm, this is an interesting use case I think we might want to address at
some point. But this doesn’t help you right now.

I thought ‘forecast’ may help me out, but wasn’t sure what to put in the
function to make it schedule even when there are no input items?

Haven’t tried this, but maybe you can just tell it that
ninput_items_required = 0 for some values of noutput_items.

Again, this might produce too many zeros. Maybe you need something more
sophisticated.

Cheers,
Martin

On Tue, Jun 3, 2014 at 9:59 PM, David Halls
[email protected]
wrote:

The problem with using ‘sob’, ‘eob’ is because I have two inputs to the
USRP UHD sink. One is constantly transmitting and has items coming in from
time=0, but the other has no input items from time=0, they only arrive
later on. As a result the sink seems to block waiting for items on both
inputs before it will transmit anything. I don’t want the USRP to have to
wait for the second stream to be populated before it transmits anything…

David,

Just one consideration:
Says, “in0” is the port getting constant input, whereas “in1” is getting
the non-consistent input.
Will this happen where “in1” is getting more input than “in0” ?
When this happen do you want to fill “in0” instead with zeros?

On Tue, Jun 3, 2014 at 9:59 PM, David Halls
[email protected]
wrote:

The problem with using ‘sob’, ‘eob’ is because I have two inputs to the
USRP UHD sink. One is constantly transmitting and has items coming in from
time=0, but the other has no input items from time=0, they only arrive
later on. As a result the sink seems to block waiting for items on both
inputs before it will transmit anything. I don’t want the USRP to have to
wait for the second stream to be populated before it transmits anything…

Create a general block with two inputs and two outputs.
The two outputs connect to the USRP UHD sink. The first input connects
to
the constantly transmitting source while the second input connects to
the
non-consistent source.

In your forecast function:

ninput_items_required[0] = noutput_items;
ninput_items_required[1] = 0;

Then in your general_work function:

const gr_complex in0 = (const gr_complex) input_items[0];
const gr_complex in1 = (const gr_complex) input_items[1];
gr_complex out0 = (gr_complex) output_items[0];
gr_complex out1 = (gr_complex) output_items[1];

for (int i=0; i < noutput_items; i++)
out0[i] = in0[i];

for (int i=0; i < ninput_items[1]; i++)
out1[i] = in1[i]

for (int i=ninput_items[1]; i < noutput_items; i++)
out1[i] = 0.0; // here you fill in the zeros, but won’t
over-filled.

consume( 0, noutput_items);
consume( 1, ninput_items[1]);

return noutput_items;

Hope this helps !

On Tue, Jun 3, 2014 at 11:08 PM, Activecat [email protected] wrote:

return noutput_items;

I’ve tested out above idea, it works.
Its implementation source file is at

To test it out, just run the flowgraph of

From: xianda [mailto:[email protected]]
Sent: 05 June 2014 09:50
To: David Halls
Subject: Re:Re: [Discuss-gnuradio] Scheduling a block even with no input
items RE: Flow graph blocking when doing 2x1 transmission

Hi David:
Thank you in advance.
I want to ask a question about “Payload TD Tx 1 is
derived from input codewords that are generated in MATLAB and stored in
a file, then loaded into the flow graph.” as you said.I want to ask how
to gnerated a dat document which is in MATLAB.What command you use in
MATLAB?
Thanks very much.
Best regards,
xianda

Hi Xianda,
Please find the zip file attached with files to read and write (to/from
MATLAB) both complex, and byte types.
Syntax is
input = read_complex_binary(‘filename.dat’)
input = read_char_binary(‘filename.dat’)
write_complex_binary(data,‘filename.dat’)
write_char_binary(data,‘filename.dat’)
Regards,
David

At 2014-06-04 08:53:31, “David Halls”
<[email protected]mailto:[email protected]>
wrote:

Hi Activecat,

I have disconnected the rest of the flow graph because it is extremely
complex.

In the system I have a Source, a Relay (1 rx USRP, 1 tx USRP), a
Destination. S —> R_rx/R_tx → D

The two transmitters that you see on that flow graph snippet I sent you
are the the Source Tx and the Relay Tx.

Payload TD Tx 1 is derived from input codewords that are generated in
MATLAB and stored in a file, then loaded into the flow graph. The
payload is created in a similar fashion to Martin’s original OFDM_tx.
This is then transmitted from Source Tx.

Until this point, no packets are received by Relay Rx but once the
source transmits, these packets are then received by Relay Rx, and then
there is a decode-and-forward chain of blocks, and this then creates
Payload TD Tx 2.

The full flow graph is attached, but may be missing many blocks for
you…

David


From: Activecat [[email protected]mailto:[email protected]]
Sent: 04 June 2014 13:45
To: [email protected]mailto:[email protected]
Cc: David Halls
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input
items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 7:10 PM, David Halls
<[email protected]mailto:[email protected]<mailto:[email protected]mailto:[email protected]>>
wrote:
Activecat,

In fact my horrible hack doesn’t work properly. Once items start
arriving at Payload TD Tx 2, they still don’t arrive as ‘consistently’
(for want of a better word), as those from the Noise Source block, and
thus zeros are inserted when they are not required!

David

David,

Could you please explain in details, what is this Payload TD Tx 2?
How does it generate data, is it getting data from a hardware or
console, why it sometime idle but sometime transmitting?

This is a virtual source. Where is it associated virtual sink?


NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web:
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl


This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com



NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl