Dear Josh,
Thanks for the info provided and the help.
I
have 4 USRP2 boards, 2 separate function generators and 2 splitters to
supply PPS and REF clock with specs as in the FAQ page. For testing
only, I used a VRT version of the firmware that my colleague modified
to send the REF clock to the debug pins, and I was able to see that the
ref clocks are synchronized.
I tried to work with 2 channels, 3 channels and 4 channels and wasn't lucky
enough to get something working.
I am also interested to know if anybody has tried the MIMO block and got it
working/not working.
Best regards,
zohair
> Date: Fri, 9 Jul 2010 09:18:24 -0700
> From: j...@joshknows.com
> To: zohair...@hotmail.com
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
>
>
> > 3) set times next pps (synchronously)
> > gr_block_executor: source <gr_block uhd mimo source (1)> produced no
> > output. We're marking it DONE.
> >
>
> This tells me that the alignment buffer is not finding a common
> timestamp among the 4 channels or one or more channels is not streaming
> (perhaps a timestamp/setup issue). What does your setup look like, is
> there a common pps and common reference split 4X to each usrp2? I forgot
> to add it to the notes but each device should have a common ref and pps
> attached to its front panel. Also, can you try to run with just two
> usrp2 to simplify the problem, does it work with 2 but not 3, 3 but not
> 4...?
>
> >
> > Sometimes I also receive these errors that disappear when I power cycle
> > the USRP2's:
> >
> > Error (usrp2 recv pirate loop): bad vrt header or unsupported packet type
> > Error (usrp2 recv pirate loop): assertion failed: if_packet_info.has_tsi
> > and if_packet_info.has_tsf
> > in void
> > usrp2_impl::io_impl::recv_pirate_loop(boost::shared_ptr<uhd::transport::zero_copy_if>,
> > boost::shared_ptr<usrp2_mboard_impl>, size_t)
> > at /home/dave/uhd/host/lib/usrp/usrp2/io_impl.cpp:97
> >
>
> Because the previous run did not exit cleanly and stop streaming, the
> recv loop is catching the middle of a packet from the previous run. This
> is safe to ignore.
>
> -Josh
_________________________________________________________________
http://clk.atdmt.com/UKM/go/197222280/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
