@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. On Fri, Nov 12, 2010 at 9:24 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 11/12/2010 07:14 PM, Josh Blum wrote: > > 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 > http://www.sbrac.org > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
