Re: [Discuss-gnuradio] Howto transmit idle pattern output when data isn't available

[Tom Rondeau]

On Wed, Feb 23, 2011 at 4:07 PM, Phelps Williams <address@hidden> wrote:

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 less than the bitrate being transmitted by the usrp.  The datagrams being received by the udp socket are variable in size and message timing is not regular.

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 must 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 source 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.  Is there an easier way to do this (that doesn't require me to do additional work)?

Thanks!

-Phelps

Nope, no easy way that doesn't require you to do more work :) Making your own block to handle this case might be the easiest thing to do right now.

Eventually, I think the answer to your question is the new stream tagging interface, probably in the receiver. I would like to make this work for all of our digital modulation blocks, too, which have a number of syncing loops 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 incoming signal and determine if there is energy or not. When there is no energy, it needs to send a tag downstream that tells all of the recovery loops to stop working. When energy is detected again, send a tag to turn back on. The idea being that, most likely, in the time between bursts, the channel and conditions have not changed greatly, so the last stable point of the sync 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.

Tom