[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:
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
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.