I think I have configured my USRP2 correctly and according to “UHD-USRP2
Application Notes”. Im at the point where I can command line ping each
usrp2. I see the link activity leds flash and recieve responses from the
USRP2. It appears that it does this for each card and each corresponding
USRP2 connected to that card. That is I have 2 usrp2s each one is
connected
to its own gigabit ethernet card.
My problem now is that when I start GRC and try to use the usrp2s I have
a
problem with the USRP2 on eth1. the one on eth0 works fine. For the eth1
I
get “usrp2 no control response” What do I do next?
In GRC, I see the single usrp2 block and the multi-usrp2 block. my
understanding is the multi block is for soft-mimo. Do I have to use one
or
the other or can I use either or? That is a single usrp2 tx/rx block for
each usrp2 tx or usrp2 rx node. So if I want one tx and two rx I would
have
3 single usrp2 blocks, 2 recieve or source blocks, and 1 transmit or
sink
block.
Or is it that because I have two USRP2 connected to one pc running GRC I
MUST use the multi-usrp2 block.
Please help, Im starting to learn this new version of GRC so I may be
making
a newbie mistake or be plain confused. I have searched on the error and
it
seems that people are discussing a python version of it but that was in
september. So I don’t know if thats relvant to me. I do eventually plan
on
having one USRP2 as a transciever. And it sounds relevant to that but is
that an old and hopefully dead bug?
The no control response might mean the pause frames are messing up the
control packets. Does this happen in a receive only application?
One way to alleviate this would be to run the flow control branch and
images. See the flow control branch on the UHD repo. and images are
here: http://www.ettus.com/downloads/uhd_images/
The purpose of the multi source block is to handle channel alignment. If
you dont require this, multiple single source blocks will work as well.
-Josh
The other possibility is that the routing/addressing isn’t setup
correctly on his host, and thus
packets for the 2nd USRP2 are heading out the wrong interface.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
@Josh:I only tried the single blocks on recieve. I hadn’t gotten far
enough
to try other blocks. I ll try transmit on monday. It seems to track the
2nd
usrp2. As far as the build goes I didn’t build it myself. A friend did
it
for me Ill have to ask him which he built. I know theres flow control.
But
theres flow control with pause frames and flow control in what was
termed a
host side solution. What is the latest available? I think it was built
last
week so he probably grabbed what was latest and greatest then. Same with
the
images.
@Marcus: I ll admit im still a hack when it comes to computers. Im
running
Ubuntu. I was able to ping the usrp2s. Is there something higher up that
they should respond to? I know windows has tracert. I think ubuntu does.
But
I m not sure what other testing I can do between ping and using them in
GRC.
Suggestion are welcome and much appreciated.
@all:Thanks very much for the help!
I do need channel alignment. I understand that the pps sets a zero time
and
the 10MHz sets the time spacing. So if Im concearned about phase between
the
two channels then I only need the 10mhz. Since if I understand it
correctly
the channels start with a random relative zero but it stays consistent
as
long as the devices are powered on.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.