On Sat, Jan 16, 2010 at 2:09 PM, Matt Ettus wrote:
> What daughterboards are you using? If it is the BasicRX or LFRX and BasicTX
> or LFTX, the you are probably better off doing this all in the same USRP2.
> It would take some relatively small modifications to the FPGA.
>
We are using an LFRx
On 01/16/2010 09:03 AM, Tom Gross wrote:
Hi Matt,
I'll try hooking up my ttl line on Monday (I have done that but not
with our current configuration, so far only when I was playing around
with building custom firmware).
Here's the official description of what we are doing (I hope this helps!):
Hi Matt,
I'll try hooking up my ttl line on Monday (I have done that but not
with our current configuration, so far only when I was playing around
with building custom firmware).
Here's the official description of what we are doing (I hope this helps!):
We have two USRP2s sharing common clocks v
Tom-
> Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
>
> We greatly appreciate the information and need to think about stuff on
> our end. I've been deliberately vague about our application (not that
> I could really explain it even if I felt authorized discuss it). The
>
On 01/15/2010 03:53 PM, Tom Gross wrote:
Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
We greatly appreciate the information and need to think about stuff on
our end. I've been deliberately vague about our application (not that
I could really explain it even if I felt auth
Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
We greatly appreciate the information and need to think about stuff on
our end. I've been deliberately vague about our application (not that
I could really explain it even if I felt authorized discuss it). The
thing to remember
On 01/15/2010 03:08 PM, Tom Gross wrote:
yes of course we have two separate gig-e cards. if the usrp2 is
sending us "pause" commands then it seems evident the usrp2 is having
trouble keeping up, not the computer.
First off, the USRP2 will only send pause frames when you are
transmitting, not
On 01/15/2010 03:14 PM, Tom Gross wrote:
Matt,
What is the maximum data rate that the USRP2 transmitter can accept
from the host without firing pause signals back to the host?
See my other message. The USRP2 will ALWAYS put out pause frames. In
fact, when the data rate is low it will actuall
On Fri, Jan 15, 2010 at 15:08, Tom Gross wrote:
> yes of course we have two separate gig-e cards. if the usrp2 is
> sending us "pause" commands then it seems evident the usrp2 is having
> trouble keeping up, not the computer.
The host software, when creating a data stream to be sent to the USR
Matt,
What is the maximum data rate that the USRP2 transmitter can accept
from the host without firing pause signals back to the host?
-Tom
On Fri, Jan 15, 2010 at 6:04 PM, Matt Ettus wrote:
>
>> Incidentally my System Engineer/Project Lead points out that if the
>> USRP2 is actually telling th
yes of course we have two separate gig-e cards. if the usrp2 is
sending us "pause" commands then it seems evident the usrp2 is having
trouble keeping up, not the computer.
On Fri, Jan 15, 2010 at 6:04 PM, Matt Ettus wrote:
>
>> Incidentally my System Engineer/Project Lead points out that if the
Incidentally my System Engineer/Project Lead points out that if the
USRP2 is actually telling the host to stop sending (which certainly
appears to be the case) then we are only able to get overall
throughput with two USRP2s over two gig-e connections comparable to
what we were getting with a sin
On Fri, Jan 15, 2010 at 2:07 PM, Eric Blossom wrote:
>
> Actually, PAUSE handling is all handled in the FPGA. When the FIFO is
> getting full, a PAUSE frame is sent on the wire telling the host to
> stop sending for a while.
>
Incidentally my System Engineer/Project Lead points out that if the
Thanks Eric, that's exactly what I thought. I think in our
application it's probably better to drop data, or at least that's why
things are more stable for us when RX is OFF. Or maybe we should just
slow down a bit. Something to think about.
On Fri, Jan 15, 2010 at 2:07 PM, Eric Blossom wrote
On Fri, Jan 15, 2010 at 01:54:24PM -0500, Tom Gross wrote:
>
> I guess I could study the firmware source (if it's in the C code where
> this happens) to figure out what happens if RX is OFF. My assumption
> is that somewhere in the USRP2 code there is some recognition that it
> can't keep up with
We've tried it with and without a switch - definitely better without the switch.
Thinking about our setup the behavior actually makes sense to me,
although I'm waiting to discuss it with my signal processing guru.
two usrp2s, connected with a mimo cable. the slave is just getting
its clock from
On Thu, Jan 14, 2010 at 10:11:38PM -0500, Tom Gross wrote:
> Following up on my previous email, thinking about this some more:
>
> I'm guessing that we are sending the USRP2 more data than it can
> handle, it is sending pause packets back, which when RX is ON, the
> ethernet card recognizes and sl
Following up on my previous email, thinking about this some more:
I'm guessing that we are sending the USRP2 more data than it can
handle, it is sending pause packets back, which when RX is ON, the
ethernet card recognizes and slows down its output (not knowing
anything about gig-e control flow bu
That's very interesting... just this morning we were playing with
turning rx OFF with ethtool
and convincing ourselves that it seemed to stabilize our system.
If we turn off RX pause (ethtool -A eth0 rx off), does the USRP2 stop
sending pause frames?
We are running two USRP2s connected with a MIM
On Thu, Jan 14, 2010 at 02:13:01PM -0500, Charles Irick wrote:
> Hello,
> I'm trying to understand the flow control between the USRP2 and host
> machine. I assume that it needs to be worked out where the USRP2 will
> always have a constant stream of uninterrupted radio data when sending
> and recei
Hello,
I'm trying to understand the flow control between the USRP2 and host
machine. I assume that it needs to be worked out where the USRP2 will
always have a constant stream of uninterrupted radio data when sending
and receiving (unless a more complex radio is in place which allows
the signal to
21 matches
Mail list logo
