Overflow/Underflow streaming problem (due to rate & type conversions?)

Hi all,

In my attempt to create a simple real-time telemetry link I’ve got stuck
in a peculiar and stubborn streaming problem that I hope someone can
help me to resolve. I am using two USRP’s with GnuRadio 3.3.0 and GRC
(since I am still quite new to GnuRadio).

Before going into the details (which unfortunately is necessary in order
to explain this issue, therefore I am really sorry for the length of
this mail!), let me suggest that the problem seem to be related to
stream conversions (rate and type) combined with simultaneous
transmission and reception. This results in overflow/underflow problems
that I cannot get rid of. Note that it is NOT computer congestion
related (> 99% sure…)

So first, let me briefly explain my telemetry link, which I put together
in five parts, and then afterwards let me explain and pinpoint the
actual problem:

  1. At transmitter side I first sample an incoming baseband signal via
    the LFRX daughterboard at 1 MSa/s into the computer. My test input
    signal is currently a square pulse (up to some 50 kHz), with a low 200mV
    amplitude, coming from a tone generator.
    First part works well!

  2. Now, since this sampled signal has too high data rate (for my over
    the air link, in part 3) I reduce its bit rate by slicing the amplitude
    (thus obtaining 1 bit/sample, now the stream flow at 1Mbit/s). The
    slicing is okay because the telemetry-source is a NRZ-type signal and
    therefore I am only interested in its sign. To avoid redundant dummy
    bits after the binary slicing (which produces bytes with “1 significant
    bit per byte”) I pack these “unpacked” bits into fully packed bytes
    containing all significant bits by using the “Unpacked to Packed” block.
    I also decimate the stream by a factor two (simply by throwing away
    every 2nd sample) to obtain a 500 kbit/s bitstream. This digital
    data-stream which represents the original NRZ signal I want to transmit
    over-the-air reconstruct it at the receiver side.
    Second part works well !

  3. The over the air interface is a simple GMSK transmission link, 500
    kbit/s (1MHz bandwidth, 2 samples/symbol). I am currently using the
    RFX2400 board at some 2.45 GHz. GMSK transceiver is used with Packet
    Encoder & Decoder at Tx and Rx side, respectively. Quite straightforward
    and nothing fancy.
    Third part works well!

  4. At the receiver side after the GMSK demodulation I “reconstruct” the
    original NRZ-signal by interpolate (“sample repeat”) by a factor 2
    (after the GMSK demodulation). “Unpack K bits” with (K=8) and use
    “Chunks to Symbols” with “-1.0, 1.0” alphabet. At this point I have
    reconstructed the original NRZ signal at the Rx side. This
    reconstruction of the NRZ signal work fine (although the original
    pulse-timing accuracy is reduced due to the necessary
    decimation/interpolation process to adapt data rate for air link).
    Fourth part works well!

  5. The just reconstructed NRZ signal is transmitted via the LFTX
    daughterboard with 1 MSa/s out to an oscilloscope (to verify the
    complete telemetry-link).
    Fifth part works well !

All of the above parts works very good, but unfortunately not when
running the whole chain 1) to 5) all together. That is, for example
using 1) together with 5) works excellent, as do 2) with 4) and the
air-to-air link 3) by its own, etc.

However, when connecting the whole link 1)-5) I run in to
overflow/underflow problems (uU and oU) at the transmitter and receiver
sides, which results in a non-continous square waveform coming out at
the oscilloscope. Using “real time scheduling” does not improve or
change the situation.

Now, the first legitimate suspicion is that the computers are
overwhelmed and cannot keep up with all this. But that is NOT the case I
am more than 99% convinced (I have made some quite extensive testing).
For example, the processors are only running at about 20% of full
capacity when running the full chain. Furthermore when I replace 1) and
5) with “Signal Source” and “Scope Sink” (that is, by using an
artificial source and sink) together with 2)-3)-4) it also works fine,
and even though I simultaneously use the original 1) and 5) parts but
don’t use them (e.g. connect them to null sinks). So the computers do
keep the pace.

Instead the problem seems to be related to my necessary conversion of
the signal streams, data rate and type, combined with receiving and
transmitting simultaneously with the USRP source and sink blocks. Any
ideas or clocks ringing from experienced users?

So, one of my thoughts was that perhaps the stream between the “USRP
source” and “USRP sink” do not become perfectly synched when they are
both used in tandem, although their rates are perfectly adapted to each
other (like to my 500 kbit/s) ?!

For example, if I use a complex “Signal Source” with 1 MSa/s instead of
the “original” sampled signal in step 1), I can make the overflow
problem at the TX side go away. Correspondingly at the Rx side. That is,
anytime I de-connect the USRP source from the USRP sink (still using the
explained stream conversion processes in between) or replace the actual
USRP source with an artificial “Signal Source” with the same sample
rate, the overflow/underflow problem go away.

I thought also that perhaps some stringent timing issues combined with
the stream conversion processes lead to the overflow and underflow
problems that I experience. Like a “takt time” synch issue on a conveyor
belt. Therefore, in an attempt to possibly alleviate such a problem I
tried to use “Sample and Hold” circuits between any “USRP source” and
“USRP sink” pair, like at the transmitter in between step 1) and 2),
respectively. This however didn’t improve or change the situation.

So, is there anyone out there who have some qualified guess or hint how
to overcome this peculiar overflow/underflow problem? I would be
relieved!

Thanks,
Rickard

Hi list,

So, I give this another try:

  • Can anyone explain why the USRP source start to cause overruns
    (uOuOuO…) after about 1 min when connected to a USRP sink for my real
    time signal-streaming application?

In my transmission chain some necessary rate and type conversions are
performed on the stream in between the USRP Source and the USRP Sink,
see it depicted in the attached GRC figure (difficult to describe the
issue accurately without it).

When the corresponding Signal Source (which is disabled, “grayed out”,
in the figure) with the same sample rate (=1 MSa/s) is used in place of
the USRP Source there are NO problems, which is quite illogical.

Please note that the USRP Source overruns occur although the total
processor load is quite low, in the range of about 10 to 30 %. I have
tested this on different platforms running Linux (Ubuntu 10.04) and Mac
OS X (10.6) with the following processors: Core 2 duo @ 2.8 GHz, Core i3
@ 2.27 GHz, Core i5 @ 2.66 GHz. Overruns occur each time on all
platforms, no difference, and the processor load is quite low (< 30%)
each time. Real time scheduling does not change this behavior either.
Hence, processor overload seems to be a very unlikely reason.

I have a very similar issue on on the receiver side (not shown, but
essentially with reverse operations) which outputs the signal via a LFTX
daughterboard after receiving it over-the-air (via the RFX2400
daughterboard). At the receiver side I get instead underruns (uUuUuU…)
reported from the USRP Sink which feeds out the DC-signal at the
receiving end (via LFTX).

The attached figure depicts a baseband (DC) signal acquisition and
radio-transmitter for my simple real time NRZ-signal streaming link. The
USPR Source uses the LFRX daughterboard (to acquire the source signal)
and a USRP Sink with the RFX2400 to transmit the rate reduced source
signal over-the-air (bottom right in the stream).

  • Any ideas what is causing these overruns (and underruns with probably
    the same root cause) and suggestions how to fix them?

/ Rickard

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs