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
On Wed, Feb 23, 2011 at 4:07 PM, Phelps W. [email protected]
wrote:
data available. This causes the receiver to go out of bit lock and it must
-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