[USRP-users] time sync 2 ettus x310

Sanjoy Basak sanjoybasak14 at gmail.com
Fri Apr 24 08:10:01 EDT 2015


Dear Mr. Michael,
I have a stupid question. I don't really know how to apply the patch files.
I tried different ways to apply, but none of those worked well. I tried
with 'apply patch 'filename'' or git patch 'filename' on terminal; but
could not make it work.
I am actually using python file to operate usrp or simply with grc.
Could you please tell me how to apply the patch file now or what exactly I
need to modify with python? or what exactly I need to do.
Please let me know.

best regards
Sanjoy

On Wed, Apr 22, 2015 at 5:48 PM, Michael West <michael.west at ettus.com>
wrote:

> Hi Sanjoy,
>
> I have attached the UHD patch that changes the ATR settings at the idle
> state to always enable frontend components for SBX and CBX daughter
> boards.  Give it a try and let us know if it works for you.
>
> Regards,
> Michael
>
> On Wed, Apr 22, 2015 at 2:36 AM, Sanjoy Basak <sanjoybasak14 at gmail.com>
> wrote:
>
>> Dear Mr. Michael,
>> Thank you very much for the reply. I am putting all the information here
>> regarding usrp.
>>
>> daughter board: SBX-120
>> UHD version: UHD_003.008.002-80-ge28d7844
>>
>> I am attaching here a pdf which includes all other information of the
>> usrp. Please send me the patch and other instruction and suggestion.
>> Have a nice day.
>>
>> best regards
>> Sanjoy
>>
>>
>> On Wed, Apr 22, 2015 at 2:29 AM, Michael West <michael.west at ettus.com>
>> wrote:
>>
>>> Hi Sanjoy,
>>>
>>> The distortion may be due to the fact that some frontend components are
>>> disabled or powered down while not transmitting or receiving and take a
>>> little time to settle when enabled or powered up.  For the X310, there are
>>> 3 ways around this:
>>>
>>> 1)  Start TX and RX earlier and throw away RX data (as you have done)
>>> 2)  Modify ATR settings dynamically so the frontend components stay
>>> powered on and enabled.  This can be done by using the
>>> multi_usrp::set_gpio_attr() method.  The banks are RX0, RX1, TX0, and TX1.
>>> You can accomplish this by adding the following lines to your code:
>>>     usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>>> "ATR_XX", 0), ~0, 0);
>>>     usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>>> "ATR_XX", 0), ~0, 0);
>>>     usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>>> "ATR_XX", 0), ~0, 0);
>>>     usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>>> "ATR_XX", 0), ~0, 0);
>>>     usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>>> "ATR_XX", 1), ~0, 1);
>>>     usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>>> "ATR_XX", 1), ~0, 1);
>>>     usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>>> "ATR_XX", 1), ~0, 1);
>>>     usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>>> "ATR_XX", 1), ~0, 1);
>>> *Note that changing the antenna or gain settings may overwrite these
>>> values.
>>> 3)  Modify ATR settings in UHD code.  This is done by editing the UHD
>>> code for the specific daughter board to change the ATR settings.
>>>
>>> Option #3 is the one that has worked the best for most users.  If you
>>> let me know what daughter card and UHD version you are using, I may be able
>>> to provide you with a UHD patch.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 1:34 AM, Sanjoy Basak via USRP-users <
>>> usrp-users at lists.ettus.com> wrote:
>>>
>>>> Dear Mr. Martin,
>>>> Thanks for the reply. Yes, right now I am not using octoclock, so the
>>>> problem while using 2 USRPsis understandable.
>>>>
>>>> However, regarding distortion, yes I am having distortion at the
>>>> beginning when I am using one usrp  for SISO case for x310. I found this
>>>> problem even in b210 as well. I wonder why no one discussed or how did they
>>>> actually solved for radar uses. But I hope I would get my solution here.
>>>>
>>>>
>>>> [image: Inline image 1]
>>>> This is a figure of xcorr of rx and tx signal. The red marked
>>>> distortion I am having almost always. I don't know the reason. If I drop
>>>> few bins in my binary file and then start receiving my signal then I am
>>>> getting an undistorted signal looks like the following.( I am transmitting
>>>> and receiving using binary file).
>>>> However, dropping bins is undesirable for radar application.
>>>> [image: Inline image 3]
>>>> If I use the distorted frame, as obvious I get distorted result.
>>>> However, after dropping bins the fresh frame gives me the exact result
>>>> after signal processing in matlab.
>>>> Can you please tell me how to avoid this distortion at the beginning?
>>>>
>>>> best regards
>>>> Sanjoy
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 21, 2015 at 12:10 AM, Martin Braun via USRP-users <
>>>> usrp-users at lists.ettus.com> wrote:
>>>>
>>>>> Sanjoy,
>>>>>
>>>>> if you want to do radar, you need to make sure both devices are
>>>>> connected to the same external reference. For radar, you can't run off
>>>>> of separate clocks.
>>>>>
>>>>> We've confirmed timing accuracy across devices on the nanosecond scale
>>>>> in the past (using OctoClocks for clock distribution).
>>>>>
>>>>> Cheers,
>>>>> M
>>>>>
>>>>> On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
>>>>> > Hi all,
>>>>> > I am trying to sync 2 ettus x310 in time. However, I am always
>>>>> having a
>>>>> > distortion at the beginning after receiving, and there is always a
>>>>> > delay of few microseconds between the tx and rx. I put tx in one x310
>>>>> > and rx in another x310 and its in a wired connection. GPS antenna is
>>>>> > connected to one usrp(with Tx) and another one is on external
>>>>> ref(Rx).
>>>>> >
>>>>> > So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
>>>>> > then I am compensating it making it set_start_time both at for 4s. So
>>>>> > ideally I should get time synced tx and rx signal.
>>>>> >
>>>>> > But I am getting distortion in Rx signal for 2seconds at the
>>>>> beginning;
>>>>> > this is constant for every sampling freq; so if in that region I
>>>>> have my
>>>>> > rx signal I can't retrieve that as the distortion is already
>>>>> introduced
>>>>> > there.
>>>>> > As I am trying to implement radar with x310, this is a serious
>>>>> problem
>>>>> > for me. As within first 2 seconds and few microseconds I can't
>>>>> receive
>>>>> > anything.
>>>>> >
>>>>> > I would really appreciate any kind of suggestion that come through.
>>>>> If
>>>>> > anyone have question regarding setup or python code please ask.
>>>>> > Thanks for reading.
>>>>> >
>>>>> > Best regards
>>>>> > Sanjoy
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > USRP-users mailing list
>>>>> > USRP-users at lists.ettus.com
>>>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>> >
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users at lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users at lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/f90fcbf3/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled2.jpg
Type: image/jpeg
Size: 18723 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/f90fcbf3/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.jpg
Type: image/jpeg
Size: 122891 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/f90fcbf3/attachment-0001.jpg>


More information about the USRP-users mailing list