[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD buffer error

From: Anton Blad
Subject: Re: [Discuss-gnuradio] UHD buffer error
Date: Thu, 20 Dec 2012 10:28:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 2012-12-19 19:30, Josh Blum wrote:

On 12/19/2012 06:04 AM, Anton Blad wrote:
Hi list,

I am using a USRP1 with UHD directly in C++, and several times I got the
following error within a few seconds after starting my application:

UHD Error:
     The receive packet handler caught an exception.
     recv buffer smaller than vrt packet offset

I haven't seen this error before, and after rebooting the USRP it went
away. Still, I would like to know what the problem was.

Essentially, my USRP code looks like this:

complex<float> buffer[SIZE];
int nread = 0;

while(nread < SIZE)
     nread += streamer->recv(rx_streamer::buffs_type(buffer+nread),
SIZE-nread, rx_meta);

Hi Josh, and thanks for your answer,

Whats happening here? Is it getting stuck in the while loop?

It's not getting stuck. The reason I wrote it like this is that I've seen recv 
return fewer bytes than requested, and I want to process buffers of a fixed 
size. The program received data for a few seconds, and then segfaulted after 
printing the message, and this happened consistently several times until I 
rebooted the USRP. Unfortunately, this was during a presentation, so I did not 
have time to run with gdb.

Looking at the UHD code, as far as I can tell, the recv buffer mentioned in the 
error message is the receive buffer from the transport layer, and not the one 
from the application.

Here is an example use case of recv in gr-uhd source block:

I don't see any big differences. The only thing I can think about is that the 
scheduler potentially could guarantee a minimum value of noutput_items so that 
recv always is called with a large enough buffer. On the other hand, if the 
problem is with the transport layer buffer I don't see why the size of the 
application buffer would matter. Anyway, I'd like to know if there is a 
potential problem with my code. If not, I guess the only thing to do is to see 
if it happens again and be ready with gdb..


I tried with SIZE=4096 and SIZE=65536 before rebooting the USRP. Could
there be a problem with this implementation, for example if recv returns
a value close to SIZE so that the next call is made with a small buffer

Basically, the rx streamer will always try to write everything it can
from internal buffers into your buffer. If there is not room, partial
buffers are saved for the next call.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]