Underrun and sampling rate problem

GNU Radio
1

Hi all,

I’m trying to employ basic On-off keying (OOK) modulation to transmit
video
stream. The way I’m doing it is by using UDP streaming from VLC player
and
collecting that data by a UDP source in GRC. Since this is OOK, I assume
the flowgraph should be somewhat similar to FSK, and hence my flowgraph
is
as follows:

UDP source (output: byte) => Packed to Unpacked (bits/chunk: 1,
Endianness:
MSB, output: byte) => Convert to complex => UHD Sink

The problem is, when I start the program, the output contains
UUUUUUU…
which means there is an underrun problem, which means I have to lower my
sample rate. Now, suppose the bitrate of my video is 1Mbps. If I set the
sampling rate to 1Mbps, the problem goes away. So, do I have to set the
sampling rate as exactly to the bitrate of my video? Of course, if I set
my
sampling rate lower than the video bitrate, the problem doesn’t occur,
but
doesn’t that mean the USRP is missing bits in that case?

Maybe for transmitting correctly, I have to repeat each sample from the
UDP
source (after the Packed-to-Unpacked block) 8 times (say). Then I have
to
use the sampling rate at the UHD sink to be 8Mbps to avoid the underrun
problem (assuming video bitrate is 1Mbps). If I set it higher, underrun
occurs; if I set it lower, underrun will not occur, but the USRP should
be
missing samples then.

Are the above suppositions correct? Is there a better way to set sample
rate which does not have to be hardcoded based on the bitrate of video?
Maybe somehow set a high sample rate and be done with it?

Thanks.

– Sakib

2

Are the above suppositions correct? Is there a better way to set sample
rate which does not have to be hardcoded based on the bitrate of video?
Maybe somehow set a high sample rate and be done with it?

Basically, you want to have a lower data rate of UDP frames vs the
sample rate on the USRP; otherwise packets are going to be lost in the
socket buffer. OK, so now, if that is the case, there has to be some
idle time. Are you going to let the USRP transmit chain go silent, or
will you fill in the missing gaps with something?

Suppose that you want to send finite bursts into the USRP sink (transmit
becomes silent). Its important to mark an EOB tag when you know that
there is a break in sample continuity. See this as an example:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++/

Had you seen the pre-cog announcement today? Basically, its a pretty
neat example of doing a MAC layer in gnuradio, and it makes proper use
of end of burst tags and things like this. Also, you could just plug in
a VLC stream into the socket to blob blocks and just send it into the
mac block. We actually did this earlier as part of the demo :slight_smile:
https://github.com/buoyboy/pre-cog/wiki

On the other hand, suppose that you want to fill in the gaps with
samples generated in the host. You would say, well my UDP socket doesnt
have data, and my work function called me with outputs to fill, ok, here
is my idle data… Now there some delay issues when you do that. For
example, you might shrink the output buffers on the downstream blocks,
or use some concept of time to throttle your data source.

Hope that gives you a few ideas!

-josh