discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP2 UART use


From: Josh Blum
Subject: Re: [Discuss-gnuradio] USRP2 UART use
Date: Tue, 14 Jun 2011 12:33:17 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10


On 06/14/2011 07:10 AM, David Scaperoth wrote:
> On Tue, Oct 19, 2010 at 9:39 PM, Josh Blum <address@hidden> wrote:
> 
>>
>>
>> On 10/19/2010 06:14 PM, address@hidden wrote:
>>
>>>
>>> We're exploring the possibility of monitoring the overrun/underrun
>>> status via the USRP2 UART.
>>>
>>>
>> FYI, the USRP2 under UHD reports underflows as async messages to the host
>> that can be accessed through the API. There are no true overflows since the
>> implementation drops packets on the ground when the host buffers fill. But
>> you can observe packet loss by inspecting the timestamps on a packet. This
>> is done in the benchmark rx example application.
>>
>>
> I'm a little confused by the 'no true overflows' comment.  Isn't dropping
> packets on the ground still an overflow?  Perhaps you mean that the host
> doesn't report to main when there are certain types of overflows?  Has this
> changed some for the UHD_003.001.000 code?
> 
> From what I can tell, the host code appears to handle overruns in two
> specific places (printed in io_impl.cpp).  One appears to be checking
> sequence numbers (indicates that the kernel is dropping packets) and one
> appears to be getting a message which translates into an error code.  In
> metadata.cpp it refers to the error as overrun of 'internal' receive buffer
> (translating that as the FPGA internal buffer).
> 
> AFAIK, if the USRP2 hardware detects an overrun, streaming stops (I've been
> using STREAM_MODE_CONTINUOUS), and in the host code, the stream command is
> automatically resent in UHD to start streaming again.
> 
> I actually attempted to recreate a scenario where I could distinguish
> between the two, so I changed one of the printouts to an 'X' (hardware error
> message) instead of an 'O' and what I found was that the if I loaded down
> the CPU with lots of non-uhd related tasks and then ran
> benchmark_rx_rate.cpp, then I could see only O's (sequence error message
> from the kernel).  In the second case, I just upped the sampling rate until
> my PC couldn't take any more and I received X's and O's equally.
> 

I have written some docs for the underflow/overflow conditions. I have
not uploaded them yet, because I am waiting to merge some work that will
generate inline message packets for USRP2/N-Series overflow:

This should make some more sense of things:
http://pastebin.com/Vh7mq3TN

-Josh



reply via email to

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