Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

[Josh Blum]

The errors below confirm my suspicion that the sync at next pps is not 
activated. The "Set time with unknown pps edge" routine will write time 
zero into your devices. However, the times all read 102.xxx seconds 
after the sync. I assume your powered them up at nearly the same time 
(on a power switch) approximately 102 seconds prior to running the code 
below. :-)

1.5 volts is too low for the pps. You need 5v cmos ideally. It may be 
possible that the load on the pps is too high. What is the pps level 
before the splitter? I recommend an active splitter that gives you 5v 
cmos out.

Since we have narrowed the problem down you can test this with a single 
usrp2.To debug this, take one usrp2, attach pps and ref with no 
splitter, modify the examples/rx_timed_example to set the clock config, 
and set the time at next pps, sleep(1). Readback the time and see if it 
is expected.

Thank you,
-Josh

On 07/21/2010 04:54 AM, Zohair wrote:
> Dear Josh,
> I have used another set of 4 USRP2's to test my program. Unlike the error I
> see when using my old set I receive this output.
>
> Current recv sock buff size: 50000000 bytes
> Current send sock buff size: 50000000 bytes
> Current recv sock buff size: 50000000 bytes
> Current send sock buff size: 50000000 bytes
> Current recv sock buff size: 50000000 bytes
> Current send sock buff size: 50000000 bytes
> Current recv sock buff size: 50000000 bytes
> Current send sock buff size: 50000000 bytes
> Using: Flex 2400 MIMO B RX (0x0027)
> Using: Flex 2400 MIMO B TX (0x002b)
> Using: Flex 2400 MIMO B RX (0x0027)
> Using: Flex 2400 MIMO B TX (0x002b)
> Using: Flex 2400 MIMO B RX (0x0027)
> Using: Flex 2400 MIMO B TX (0x002b)
> Using: Flex 2400 MIMO B RX (0x0027)
> Using: Flex 2400 MIMO B TX (0x002b)
> RX samples per packet: 362
> TX samples per packet: 363
> Recv pirate num frames: 33967
> Set time with unknown pps edge:
>      1) set times next pps (race condition)
>      2) catch seconds rollover at pps edge
>      3) set times next pps (synchronously)
> Error: time deviation between board 1 and board 0.
>      Board 0 time is 102.881714 seconds.
>      Board 1 time is 102.838705 seconds.
>
> Error: time deviation between board 2 and board 0.
>      Board 0 time is 102.883991 seconds.
>      Board 2 time is 102.798313 seconds.
>
> Error: time deviation between board 3 and board 0.
>      Board 0 time is 102.889212 seconds.
>      Board 3 time is 102.832728 seconds.
>
>
> > > > Done
>
> The differnce here is that the program keeps running and I dont receive the
> "gr_block_executor: source<gr_block uhd mimo source (6)>  produced no
> output.  We're marking it DONE."
>
> Also, attached are the photos of the clock and the pps signal at the output
> of the splitters at the input of the USRPs.
>
> Any help with this please? I also want to know if my old set of USRPs has a
> problem.
>
> Best regards,
>
> Zohair
>
> Josh Blum-2 wrote:
> > I pushed some changes to the uhd master that will check the deviation on
> > the times between boards. This should help you to debug your setup. If
> > you see an error message like the following, then you may have an issue
> > with the configuration. In the following example, I disconnected the PPS
> > on one of the boards. This is the result:
> >
> > Set time with unknown pps edge:
> >       1) set times next pps (race condition)
> >       2) catch seconds rollover at pps edge
> >       3) set times next pps (synchronously)
> > Error: time deviation between board 1 and board 0.
> >       Board 0 time is 0.008782 seconds.
> >       Board 1 time is 65.009945 seconds.
> >
> > gr_block_executor: source<gr_block uhd mimo source (3)>  produced no
> > output.  We're marking it DONE.
> >
> > -Josh
> >
> > On 07/12/2010 07:14 AM, Zohair M. Abu Shaban wrote:
> > > 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: address@hidden
> > > > To: address@hidden
> > > > CC: address@hidden
> > > > 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
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> http://old.nabble.com/file/p29224741/20100720119.JPG 20100720119.JPG
> http://old.nabble.com/file/p29224741/20100720120.jpg 20100720120.jpg