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

[Josh Blum]

Zohair,

Glad to hear that things are working! (though not perfectly)

I intend to duplicate a 4X setup to verify what you are seeing. In the 
meantime I have a few things you can try:

1)
edit gr-uhd/lib/uhd_mimo_source.h and change the time in the following 
line to something larger, say 50 ms:

stream_cmd.time_spec = get_time_now() + uhd::time_spec_t(0, 0.01); 
//10ms offset in future

it is possible that the time in the stream request has become late when 
board number 4 gets the command issued. 10 ms is an arbitrary time but i 
believe that it is well over 4*RTT so i am not sure why that may be a 
problem, but it is worth trying a greater time value.

2)
run wireshark on all 4 ethernet interfaces to see how many are actually 
streaming when this error occurs. This would tell me if a particular 
board is not streaming or if all are streaming and the timespecs are 
incorrect. You should see traffic from each board with udp source port 
49153 (the data port).

-Josh

On 07/26/2010 04:39 AM, Zohair wrote:
> Dear Josh,
>
> I have sorted out the PPS signal problem. It was the splitter that has the
> problem and now I am able to output 5v signal from it.
>
> I tried to use an array of 2 and 3 usrp2 and it worked fine. However, the
> block still doesn't work for my 4 USRP2. I see this error when I use them
> all:
> *****************************************
> 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)
>   Times set to 0 successfully!<<== note: these are printed if there's
> no time deviation
>   Times set to 0 successfully!
>   Times set to 0 successfully!
> gr_block_executor: source<gr_block uhd mimo source (1)>  produced no output.
> We're marking it DONE.
> ***************************************
>
> Any help, please?
>
> Thanks again,
>
> Zohair
>
>
>
> Josh Blum-2 wrote:
> > 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
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio