[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010
From: |
Zohair |
Subject: |
Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010 |
Date: |
Tue, 27 Jul 2010 06:57:07 -0700 (PDT) |
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.
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, (continued)
- RE: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Zohair M. Abu-Shaban, 2010/07/09
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Josh Blum, 2010/07/09
- RE: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Zohair M. Abu Shaban, 2010/07/12
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Josh Blum, 2010/07/12
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Zohair, 2010/07/21
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Josh Blum, 2010/07/21
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Zohair, 2010/07/26
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Zohair, 2010/07/26
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Josh Blum, 2010/07/27
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010,
Zohair <=
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Josh Blum, 2010/07/27
- Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010, Zohair, 2010/07/27