[USRP-users] time sync 2 ettus x310

Michael West michael.west at ettus.com
Wed Apr 22 11:48:08 EDT 2015


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/20150422/41326707/attachment-0002.html>
-------------- 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/20150422/41326707/attachment.jpg>
-------------- 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/20150422/41326707/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbx_cbx_atr.patch
Type: text/x-patch
Size: 1250 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/41326707/attachment.patch>


More information about the USRP-users mailing list