[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: |
Mon, 26 Jul 2010 10:29:27 -0700 (PDT) |
An extra peice of information is that the block is instable even with 2 and
three USRP2. This means sometimes it works and sometimes it producs no
output.
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
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29268907.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 <=
- 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
- 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