[Top][All Lists]
[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