USRP2 UART use

We’re exploring the possibility of monitoring the overrun/underrun
status via the USRP2 UART.

I’m curious to learn what approaches people have taken to do this (e.g.,
connect the UART to a logic analyzer, use a level shifter -> RS232 ->
host serial/USB port, etc.).

I’d also like to know what other information is available via this port
and any other information people can share about there experience using
the UART port.

I’ve found some level shifter cables that seem ideal and aren’t too
expensive (<$30), but I’d like to hear what (if anything) other folks
are doing.

Thanks,

–Bob

P.S. I attempted to send this out several hours ago, but for some reason
it didn’t make it. If the original does resurface, I apologize in
advance for the duplicate posting.

On Tue, Oct 19, 2010 at 8:14 PM, [email protected] wrote:

We’re exploring the possibility of monitoring the overrun/underrun status via
the USRP2 UART.

I’m curious to learn what approaches people have taken to do this (e.g., connect
the UART to a logic analyzer, use a level shifter -> RS232 -> host serial/USB
port, etc.).

I’d also like to know what other information is available via this port and any
other information people can share about there experience using the UART port.

I’ve found some level shifter cables that seem ideal and aren’t too expensive
(<$30), but I’d like to hear what (if anything) other folks are doing.

We use a UART-to-USB converter board from Sparkfun for accessing the
UART on the USRP2, typically plugged into minicom:

http://www.sparkfun.com/commerce/product_info.php?products_id=10009

Cheap, simple, and the FTDI Linux drivers work fine at 230.4 Kbps (the
rate of the UART on the USRP2).

We’ve instrumented the USRP2 firmware at different times with debug
messages to understand what is going on, but that is about it. It can
be very helpful for the right situation.


John O.
CEO/System Architect
Epiq Solutions
www.epiq-solutions.com

On 10/19/2010 06:14 PM, [email protected] 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.

-Josh

On 06/14/2011 07:10 AM, David S. wrote:

changed some for the UHD_003.001.000 code?
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

On Tue, Oct 19, 2010 at 9:39 PM, Josh B. [email protected] wrote:

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.

David

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs