Howto transmit idle pattern output when data isn't available

I have what I would suspect is a common dilemma with the gnuradio
architecture. I have a udp socket which is providing me a packets at
than the bitrate being transmitted by the usrp. The datagrams being
received by the udp socket are variable in size and message timing is

If my gnuradio transmitter exhausts the data available on the udp socket
there will be a gap in the modulated output (I would expect the output
of my
usrp to just go CW at this point correct?). This will definitely happen
because the bitrate my modulator expects is higher than the actual
amount of
data available. This causes the receiver to go out of bit lock and it
attempt to relock when modulation starts again.

Is it possible to inject an idle pattern when datagrams are not
available to
keep the receiver in lock? I’m thinking I may need to write my own
which does a non blocking read on the socket, if data isn’t available it
outputs an idle sequence, if data is available it provides that instead.
there an easier way to do this (that doesn’t require me to do additional



On Wed, Feb 23, 2011 at 4:07 PM, Phelps W. [email protected]

data available. This causes the receiver to go out of bit lock and it must


Nope, no easy way that doesn’t require you to do more work :slight_smile: Making
own block to handle this case might be the easiest thing to do right

Eventually, I think the answer to your question is the new stream
interface, probably in the receiver. I would like to make this work for
of our digital modulation blocks, too, which have a number of syncing
that go crazy when there is no signal and then have to resync when the
signal returns. I would like for a block to check the power of the
signal and determine if there is energy or not. When there is no energy,
needs to send a tag downstream that tells all of the recovery loops to
working. When energy is detected again, send a tag to turn back on. The
being that, most likely, in the time between bursts, the channel and
conditions have not changed greatly, so the last stable point of the
loops should still be close.

The difficulty with this method is mostly that we have not written
documentation on the stream tagging interface, nor have we provided many
good examples for how to use it. It is currently only available in the
‘next’ branch.