UHD buffer error

GNU Radio
1

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 buffer[SIZE];
int nread = 0;

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

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
size? The UHD version is UHD_003.004.003-276-unstable.

Thanks in advance for any help,
Anton Blad

2

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

away. Still, I would like to know what the problem was.
}

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

Here is an example use case of recv in gr-uhd source block:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr_uhd_usrp_source.cc#n331

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.

-josh

3

On 2012-12-19 19:30, Josh B. wrote:

 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:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr_uhd_usrp_source.cc#n331

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…

Regards,
Anton