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

[Zohair]

Dear Josh,

It's working now! I changed it to 50ms instead of 10 and added the lines in
the synchronisation for loop in mimo_usrp.cpp to see the amount of deviation
between usrps if they are synchronised:

float diff=(time_i.get_real_secs() - time_0.get_real_secs())*1000;
std::cerr << boost::format("Time was reset successfully for board %d with
deviation: %f ms relative to board 0") 
% i %diff<< std::endl;
 The output is:
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)
Time was reset successfully for board 1 with deviation: 1.095390 ms relative
to board 0
Time was reset successfully for board 2 with deviation: 1.093340 ms relative
to board 0
Time was reset successfully for board 3 with deviation: 1.096530 ms relative
to board 0

However, I still have a few questions:
1-Can't we make the deviation exactly zero? What factors affect this? 

2- In my tries to run the flowgraphs, sometimes I receive these errors:
OError (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:106

you told me before it's save to neglect these errors but when i neglect them
I receive rubbish data not what I am expecting, despite the fact that boards
indeed synchronised. These errors disappear when I power cycle the USRPs. Is
there anything I can do about this?

3- Also, sometimes a number of "O" characters get printed on the screen,
what does this mean?

4- What is the least sampling freq that I can use?

I am so glad that we have got something working now and Thank you very much
indeed.

Zohair




Josh Blum-2 wrote:
> 
> 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
>>>
>>>
>>
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29276686.html
Sent from the GnuRadio mailing list archive at Nabble.com.