Re: Flow graph blocking when doing 2x1 transmission

GNU Radio
1

Hi Marcus,

I’m not sure if understand correctly then, how would you suggest it is
possible to implement your suggestion

‘a block that (rate limitedly) produces zero-samples, unless data comes
in on a message port?’

…My new block is connected to the UHD sink - so this should consume
the output buffer of the block at a constant rate, and so my setup
should work?

Many thanks,

David

-------- Original message --------
From: Marcus Müller
Date:02/06/2014 19:56 (GMT+00:00)
To: David Halls ,[email protected]
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1
transmission

Hi David,

you’re right, the scheduler will only call your block when out- or input
buffer situation have changed, and there’s no elegant way to coerce
that.
However, given a sink that consumes with a constant continous rate, that
will never be a problem for a longer time.

Greetings,
Marcus

On 02.06.2014 18:55, David Halls wrote:

int
                    out[idx] = 0;

Regards,
“easiest” way to achieve coherence on both USRP would be a MIMO cable,

}

| sample source a |------------>| USRP |—> [USRP1]
Alternatively, what about having a block that (rate limitedly) produces

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

2

Hi David,

I think you got that right.
Using msg_port_register_in(…) you could set up a message port, define a
message handler, in which you set a class member (eg. d_datatosend) to
the message’d content, and in your work check whether d_datatosend is
empty or not, and in the latter case, emit that.

That’s only one way to solve your non-constant streaming issue, and it’s
one of the most computationally intensive, so I don’t really know if my
advice was good…

Greetings,
Marcus