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

GNU Radio
1

On Wed, Jun 4, 2014 at 4:59 PM, David Halls
[email protected]
wrote:

Hi!

This shouldn’t be the case. But is there any easy way to allow different
rates on the two streams, so I could produce more zeros on stream 1 than
items on stream 0? Or vice versa?

David

Please stay on the list.

To have different rates on different inputs,
[1]
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-05/msg00166.html
[2] http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html

2

Sorry – I meant to hit reply all!

From: Activecat [mailto:[email protected]]
Sent: 04 June 2014 10:51
To: [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 4:59 PM, David Halls
<[email protected]mailto:[email protected]>
wrote:
Hi!

This shouldn’t be the case. But is there any easy way to allow different
rates on the two streams, so I could produce more zeros on stream 1 than
items on stream 0? Or vice versa?

David

Please stay on the list.
To have different rates on different inputs,
[1]
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-05/msg00166.html
[2] http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html

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

3

Hi,

Thank you for those links. Unfortunately the rates for the two ports are
not an exact ratio, so I am not sure how this will work. Also I have

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

I am not quite sure how to change this… Maybe it will help to show
more clearly what I am doing.

Attached is a flow graph that shows how I have managed to achieve what I
want - but clearly it is a real fudge.

I am doing a 2x1 transmission, so in time-domain (TD), I have [ Header 1
(240 samples), Header 2 (240 samples), superimposed Payload Tx1 + Tx2
(1280 samples) ] then this repeats.

Header TD Tx1, Header TD Tx2 and Payload TD Tx1 always have items
available, but Payload TD Tx2 has no items at time=0.

I would like the header data (both Tx1 and Tx2 to always be transmitted,
so that even when Payload TD Tx2 is not available, the protocol/frame
structure does not break down.

Regards,

David

From: Activecat [[email protected]]
Sent: 04 June 2014 10:51
To: [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 4:59 PM, David Halls
<[email protected]mailto:[email protected]>
wrote:
Hi!

This shouldn’t be the case. But is there any easy way to allow different
rates on the two streams, so I could produce more zeros on stream 1 than
items on stream 0? Or vice versa?

David

Please stay on the list.

To have different rates on different inputs,
[1]
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-05/msg00166.html
[2] http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html

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

4

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

5

Please do not top post.
Refer
http://gnuradio.org/redmine/projects/gnuradio/wiki/MailingLists#Guidelines-for-posting

6

On Wed, Jun 4, 2014 at 7:10 PM, David Halls
[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?

7

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]]
Sent: 04 June 2014 13:45
To: [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]>
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/trl

8

On Wed, Jun 4, 2014 at 8:53 PM, David Halls
[email protected]
wrote:

How many USRP are controlled by this flowgraph?
It seems at least three, what is the exact number?

9

From: Activecat [[email protected]]
Sent: 04 June 2014 15:21
To: David Halls
Cc: [email protected]
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 8:53 PM, 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…

How many USRP are controlled by this flowgraph?
It seems at least three, what is the exact number?

Yes, there are 3. The Source Tx, the Relay Tx, and the Relay Rx.

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

10

On Wed, Jun 4, 2014 at 10:25 PM, David Halls
[email protected]
wrote:

Yes, there are 3. The Source Tx, the Relay Tx, and the Relay Rx.

To clarify,
i). the “Source Tx” USRP may or may not receive data at any time
interval.
ii). the “Relay Tx” USRP transmit data only when the “Source Tx” USRP
receive data, and there is a delay due to signal processing
iii). the “Relay Rx” USRP will receive data only when the “Relay Tx”
USRP
transmit it,

is this correct?

11

On Wed, Jun 4, 2014 at 8:53 PM, David Halls
[email protected]
wrote:

Could you send the source code of the missing blocks to me?
I am trying hard to help you out.

12

From: Activecat [[email protected]]
Sent: 04 June 2014 15:39
To: David Halls
Cc: [email protected]
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 10:25 PM, David Halls
<[email protected]mailto:[email protected]>
wrote:
Yes, there are 3. The Source Tx, the Relay Tx, and the Relay Rx.

To clarify,
i). the “Source Tx” USRP may or may not receive data at any time
interval.
ii). the “Relay Tx” USRP transmit data only when the “Source Tx” USRP
receive data, and there is a delay due to signal processing
iii). the “Relay Rx” USRP will receive data only when the “Relay Tx”
USRP transmit it,

is this correct?

Not quite…

i). the “Source Tx” USRP has a constant stream of data, and is
constantly transmitting. If the codewords in the file are exhausted it
repeats.
ii). the “Relay Tx” USRP transmits data only when data has been received
by the “Relay Rx” (I will use tx_time to control when the received burst
is re-transmitted)
iii). the “Relay Rx” USRP will receive data only when the “Source Tx”
USRP transmits (section where Relay Tx’s too will be ignored),

I have changed the block you suggested, to avoid inserting 0’s mid
burst.

void
avoid_block_impl::forecast (int noutput_items, gr_vector_int

&ninput_items_required)
{
ninput_items_required[0] = noutput_items;
ninput_items_required[1] = 0;
}

int
avoid_block_impl::general_work (int noutput_items,
                   gr_vector_int &ninput_items,
                   gr_vector_const_void_star &input_items,
                   gr_vector_void_star &output_items)
{
            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];

            //if(DEBUG) fprintf(stderr, " noutput_items = %d,

ninput_items[0] = %d, ninput_items[1] = %d.\n", noutput_items,
ninput_items[0], ninput_items[1]);

            // For first input, just copy
            for (int i=0; i < noutput_items; i++)
                    out0[i] = in0[i];

            // Count number of output items
            int num_out1 = 0;

            // If items available for second input, copy
            for (int i=0; i < ninput_items[1]; i++)
            {
                    out1[i] = in1[i];
                    if(!d_burst)
                    {
                            if(DEBUG) fprintf(stderr, " Entering

burst…\n");
d_burst = true;
}
// Number of (actual) items tx’d this call
num_out1++;
// Total number of items in burst transmitted so
far
d_items_sent++;
}

            // For the rest of second output, fill with zeros
            if(!d_burst)
            {
                    for (int i=ninput_items[1]; i < noutput_items ;

i++)
{
// Fill zeros
out1[i] = 0.0;
// Number of (zero) items tx’d this call
num_out1++;
}
}

            // Mark end of burst
            if(d_items_sent >= 1280*6) //TODO change to external

burst length parameter
{
if(DEBUG) fprintf(stderr, " Finishing
burst…\n");
d_burst = false;
d_items_sent = 0;
}

            consume( 0, noutput_items);
            consume( 1, ninput_items[1]); // Consume all available

items

            produce( 0, noutput_items);
            produce( 1, num_out1); // Only produce the required

number of items

            return WORK_CALLED_PRODUCE;
}

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

13

On Wed, Jun 4, 2014 at 10:52 PM, David Halls
[email protected]
wrote:

Not quite…

i). the “Source Tx” USRP has a constant stream of data, and is constantly
transmitting. If the codewords in the file are exhausted it repeats.
ii). the “Relay Tx” USRP transmits data only when data has been received
by the “Relay Rx” (I will use tx_time to control when the received burst is
re-transmitted)
iii). the “Relay Rx” USRP will receive data only when the “Source Tx” USRP
transmits (section where Relay Tx’s too will be ignored),

What do you mean by “section where Relay Tx’s too will be ignored” ?

I have changed the block you suggested, to avoid inserting 0’s mid burst.

So does this give better results?

14

On Wed, Jun 4, 2014 at 10:52 PM, David Halls
[email protected]
wrote:

Not quite…

i). the “Source Tx” USRP has a constant stream of data, and is constantly
transmitting. If the codewords in the file are exhausted it repeats.
ii). the “Relay Tx” USRP transmits data only when data has been received
by the “Relay Rx” (I will use tx_time to control when the received burst is
re-transmitted)
iii). the “Relay Rx” USRP will receive data only when the “Source Tx” USRP
transmits (section where Relay Tx’s too will be ignored),

To clarify, is it true that both the “Source TX” USRP and “Relay Tx”
USRP
are controlled by the same UHD Sink in the flowgraph?

15

From: Activecat [[email protected]]
Sent: 04 June 2014 16:02
To: David Halls
Cc: [email protected]
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 10:52 PM, David Halls
<[email protected]mailto:[email protected]>
wrote:
Not quite…

i). the “Source Tx” USRP has a constant stream of data, and is
constantly transmitting. If the codewords in the file are exhausted it
repeats.
ii). the “Relay Tx” USRP transmits data only when data has been received
by the “Relay Rx” (I will use tx_time to control when the received burst
is re-transmitted)
iii). the “Relay Rx” USRP will receive data only when the “Source Tx”
USRP transmits (section where Relay Tx’s too will be ignored),

What do you mean by “section where Relay Tx’s too will be ignored” ?

I have changed the block you suggested, to avoid inserting 0’s mid
burst.

So does this give better results?

  1. this is to avoid loop interference, the Relay Rx will ignore the
    received signal during the time that the Relay Tx is transmitting.
  2. Yes avoiding adding 0’s gives me pretty much the performance I
    require, I need to work on some other parts of the implementation to be
    sure. (it is definitely not the neatest way yet!!)

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

16

On Wed, Jun 4, 2014 at 7:10 PM, David Halls
[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,

Basically my idea to solve the problem may involve an overhaul of your
existing flowgraph, as below:

1). You must understand that the output of UHD source is at constant
rate.
In particular I am referring to the “Relay Rx” USRP.
Even when the USRP does not receive any RF signal, it keeps
sending
out zeros (plus noise) as its output, at constant rate.

  Try to make all your blocks behave in this way. I am referring to

the
blocks between the “Relay Rx” and “Relay Tx”.
The idea is: keep transmitting, don’t produce no output at any
time.
If nothing need to be produced, then output zeros at constant rate.
In this case all your custom blocks are either sync block,
decimation
or interpolation blocks. You don’t need any general block.

2). With above condition fulfilled, we could ensure that the data fed
into
the “Relay Tx” USRP is at constant rate, and we could then determine
this
rate by simple calculations.
The data stream into the “Relay Tx” USRP will not stop at any
instance. It is ‘consistent’.

3). You want the “Relay Rx” USRP ignores the received signal during the
time that the “Relay Tx” USRP is transmitting, that is fine.
But just try to make the downstream block of “Relay Rx” USRP keep
transmitting zeros rather than stop transmitting during this period.

4). With these, you will have both “Relay Tx” USRP and “Source” USRP
transmitting at constant data rate and nonstop.
They could be transmitting at different rates, that is ok, and
this
is not difficult to handle.

With this, you avoid the initial problem (problem of occasionally there
is
no items at one of the inputs) mentioned in this thread, which is the
root
cause of your problem.
Then your problem is solved !

17

From: Activecat [[email protected]]
Sent: 04 June 2014 16:13
To: David Halls
Cc: [email protected]
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 10:52 PM, David Halls
<[email protected]mailto:[email protected]>
wrote:
Not quite…

i). the “Source Tx” USRP has a constant stream of data, and is
constantly transmitting. If the codewords in the file are exhausted it
repeats.
ii). the “Relay Tx” USRP transmits data only when data has been received
by the “Relay Rx” (I will use tx_time to control when the received burst
is re-transmitted)
iii). the “Relay Rx” USRP will receive data only when the “Source Tx”
USRP transmits (section where Relay Tx’s too will be ignored),

To clarify, is it true that both the “Source TX” USRP and “Relay Tx”
USRP are controlled by the same UHD Sink in the flowgraph?

Yes, they are both controlled by the same UHD sink. This ensures, in a
simple fashion, that the Source Tx and Relay Tx transmissions have
sample-level synchronicity - a must for my Quantize Map and Forward
scheme.

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