Re: [Discuss-gnuradio] Overflow/Underflow streaming problem (due to rate & type conversions?)

[Rickard Nilsson]

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

On 6 okt 2010, at 21.17, Rickard Nilsson wrote:

> 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
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio