[USRP-users] N310 time offset between TX RF Outputs

Serge Malo serge.malo at skydelsolutions.com
Thu Feb 7 20:54:19 EST 2019


Hello Michael,

Sorry for the long delay of my answer:
I just want to confirm that the reported issues are fixed with the N310 and
UHD 3.13.1.0.

Thanks!
Serge




On Fri, 4 Jan 2019 at 16:00, Michael West <michael.west at ettus.com> wrote:

> Hi Serge,
>
> I have tried to reproduce the issue on an N310 and X310 with no success.
> I tried several versions of UHD (including v3.13.1.0-rc1) on both and the
> time alignment was always good and the benchmark_rate with the increased
> INIT_DEALY always worked as expected.  Can you try with the head of the
> UHD-3.13 branch and see if you still see the same issues?  If so, please
> provide the modified tx_timed_samples example you are using along with the
> command being issued.  A picture of what you are seeing on the scope would
> also be helpful.
>
> Regards,
> Michael
>
> On Mon, Nov 12, 2018 at 9:54 PM Michael West <michael.west at ettus.com>
> wrote:
>
>> Hi Serge,
>>
>> Thank you for making us aware of the issues.  We are looking into them
>> and consider them a priority.  We will let you know what we find.
>>
>> Regards,
>> Michael
>>
>> On Fri, Nov 9, 2018 at 11:04 AM Serge Malo via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I have made another test today, I want to report the results here.
>>>
>>> *Issue #1*
>>> I have modified the tx_timed_samples example, simply such that it
>>> transmits on both channels of the X300.
>>> Using a frequency of 1.57542GHz for both channels, I was able to measure
>>> on a scope a time offset of 320ns between RF A and RF B.
>>> Technically, Ettus R&D should be able to reproduce this offset easily.
>>>
>>> *Issue #2:*
>>> Yesterday, I wrote that "timed commands" seemed to be broken with UHD
>>> 3.13.1.0 RC1. Here are more details:
>>> "timed samples" do work correctly with the UHD example tx_timed_samples.
>>> However, "timed samples" do not work with the UHD example benchmark_rate.
>>> You can reproduce the problem this way, on a X300, connected to an
>>> Octoclock:
>>> 1) Change the value of INIT_DELAY to 5.0s
>>> 2) Recompile benchmark_rate, and try this command:
>>> ./benchmark_rate --args addr=192.168.40.2 --tx_rate=25000000
>>> --tx_cpu=sc16 --ref=external --pps=external --channels=0,1
>>>
>>> You will see that the TX starts immediately, instead of at time 5.0s.
>>>
>>> Please, let us know if you aware of those issues, and if you need help
>>> to reproduce or investigate them.
>>>
>>> Best regards,
>>> Serge
>>>
>>>
>>> On Thu, 8 Nov 2018 at 23:59, Marcus D. Leech via USRP-users <
>>> usrp-users at lists.ettus.com> wrote:
>>>
>>>> On 11/08/2018 03:13 PM, Serge Malo via USRP-users wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Thanks for the extra comments Mark.
>>>>
>>>> Just to be clear: I'm not talking about phase offset between RF
>>>> Outputs, but only time offset.
>>>> (Once time offset is fixed, we will try to have phase-coherent RF
>>>> outputs).
>>>>
>>>> I have made other measurements today, here are the results.
>>>> I'm transmitting a signal at 1.57542GHz, and a second signal at
>>>> 1.2276GHz.
>>>> Sample Rate on N310: 25.6Msps (MCR of 153.6Mhz)
>>>> Sample Rate on X300: 25.0Msps (MCR of 200Mhz)
>>>> Using External Clock and External PPS from Octoclock
>>>> 1) Using X300 (RF A and RF B) and UHD 3.10.3.0, we see les than 3ns
>>>> time offset (See image here: link
>>>> <https://drive.google.com/file/d/1FBC3CHOhGO4xLdJU3LhjB0pTjexNpJik/view?usp=sharing>
>>>> )
>>>> 2) Using X300 (RF A and RF B) and UHD 3.13.1.0 RC1, we see 7300us time
>>>> offset (See image here: link
>>>> <https://drive.google.com/file/d/1mV2XrUVz1PC4boi0BzUmxFcWo2b8zj3Y/view?usp=sharing>
>>>> )
>>>> 3) Using N310 (RF 0 and RF 2) and UHD 3.13.1.0 RC1, we also see 7300us
>>>> time offset.
>>>>
>>>> Important: the "timed commands" seem to be broken in UHD 3.13.1.0,
>>>> either for X300 or N310.
>>>> When we change the time_spec of the first "send" call, the time at
>>>> which the samples are transmitted does not change. For example, I tried to
>>>> set tie_spec to 10s, but the Tx starts right away. This was working
>>>> correctly with UHD 3.10.3.0
>>>>
>>>> Let me know if you have ideas I could try.
>>>>
>>>> Best regards,
>>>> Serge
>>>>
>>>> Serge:
>>>>
>>>> The fact that this affects both X310 and N310 is a bit disturbing--the
>>>> device-side codebase is quite different on the two boxes.  I'm engaging
>>>>   Ettus R&D internally to see if this can be reproduced.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, 8 Nov 2018 at 14:44, Mark Wagner <m2wagner at eng.ucsd.edu> wrote:
>>>>
>>>>> Here's a google drive link with images of the phase drift between rx4
>>>>> and tx 1&2, and tx 3&4
>>>>>
>>>>> https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH
>>>>>
>>>>> On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner <m2wagner at eng.ucsd.edu>
>>>>> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Maybe I could jump in and share some related results. My group has
>>>>>> been developing a MIMO system with N310 units. We did a test sounding
>>>>>> recently where we sent 4, length 4096, orthogonal multitone signals from
>>>>>> the transmitters to the receivers and processed the data by finding the
>>>>>> channel response between each transmitter and receiver pair (16 in total)
>>>>>> and recording the magnitude and phase of the arrival spikes between each
>>>>>> pair.
>>>>>>
>>>>>> We took several seconds of data and processed it in length 4096
>>>>>> chunks (around 1500 chunks in total) and looked at the phase difference
>>>>>> between transmitter pairs as time progressed. Since transmitters 1 and 2
>>>>>> are sharing an LO and our setup was not moved during the sounding we
>>>>>> expected to see a constant phase difference between transmitters 1 and 2
>>>>>> and a single receiver (same with tx 3 and 4), but we saw some drift. Worse
>>>>>> yet, not all LO sharing pairs drifted in the same way, some didn't drift
>>>>>> much at all while some drifted in linear or non-linear patterns.
>>>>>>
>>>>>> If you're all fine with me breaking the rules I can attach some png
>>>>>> images of what we recorded so you can see what it looks like. Later this
>>>>>> week we'll repeat the experiment but leave the machines running longer to
>>>>>> see if the drift diminishes as the machines run longer.
>>>>>>
>>>>>> Cheers,
>>>>>> -Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users <
>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>
>>>>>>> Hi Serge,
>>>>>>>
>>>>>>> Are you measuring the phase offset between the TX0 and TX2 signals
>>>>>>> in a steady-state case, or the time difference in the start of those
>>>>>>> signals?
>>>>>>>
>>>>>>> In the former case, your results could be impacted by the lack of
>>>>>>> internal LO sharing between daughterboards. I would fully expect an unknown
>>>>>>> phase offset between channels 0 and 2 every time you reconfigure the
>>>>>>> device. In the latter case, it sounds like a start trigger mismatch like
>>>>>>> Marcus mentioned.
>>>>>>>
>>>>>>> Can you share more details as to how you're measuring the phase
>>>>>>> offset?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Daniel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users <
>>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>>
>>>>>>>> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system
>>>>>>>> image
>>>>>>>>
>>>>>>>> I can try to use lower tx start times to see if the time offset
>>>>>>>> changes with that.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serge
>>>>>>>>
>>>>>>>> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech <
>>>>>>>> patchvonbraun at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 11/07/2018 09:31 PM, Serge Malo wrote:
>>>>>>>>>
>>>>>>>>> Yes:
>>>>>>>>> We only use one streamer for all RF outputs, and send time_spec
>>>>>>>>> with each call to the streamer's send method.
>>>>>>>>> We reset the internal time with set_time_unkown_pps(0), and
>>>>>>>>> program the first samples to be streamed at a time of 0.800s.
>>>>>>>>> It is basically the same code we used on the X300/X310.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serge
>>>>>>>>>
>>>>>>>>> Well, that is quite strange--the magnitude of the time offsets is
>>>>>>>>> larger than I would expect.
>>>>>>>>>
>>>>>>>>> Perhaps someone from the N310 team can comment?
>>>>>>>>>
>>>>>>>>> Serge, are you using the latest UHD and system image versions for
>>>>>>>>> the N310?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
>>>>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> We are trying to send 4 synchronous signals from the 4 Tx ports
>>>>>>>>>> of the N310.
>>>>>>>>>> We are using UHD 3.13.1.0 RC1 under Ubuntu.
>>>>>>>>>> Central Freq = 1575.42 GHz and 1227.6 MHz
>>>>>>>>>> Master Clock rate = 153.6 MHz
>>>>>>>>>>
>>>>>>>>>> We would expect to have less than 3ns offset between all TX ports
>>>>>>>>>> of the N310, like we do with the X300/X310. However, we have measured
>>>>>>>>>> 4700ns between TX RF ports 0 and port 2.
>>>>>>>>>> We have tried the next things with no more success:
>>>>>>>>>> - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
>>>>>>>>>> - Init with the device options "init_cals=ALL" and
>>>>>>>>>> "force_reinit=1"
>>>>>>>>>> - Use the internal GPSDO
>>>>>>>>>> - Use clock_source=external and time_source=external (from an
>>>>>>>>>> Octoclock).
>>>>>>>>>>
>>>>>>>>>> Can you tell us:
>>>>>>>>>> -What time offset between TX RF ports we should expect to achieve?
>>>>>>>>>> -Is there anything else we can try to reduce this offset to less
>>>>>>>>>> than 3ns?
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Serge
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How are you setting up your TX streamer?   Is it time-tagged to
>>>>>>>>>> start at a particular device time?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Daniel Jepson
>>>>>>>
>>>>>>> Digital Hardware Engineer
>>>>>>>
>>>>>>> National Instruments
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> O: +1.512.683.6163
>>>>>>>
>>>>>>> daniel.jepson at ni.com
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> USRP-users at lists.ettus.com
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mark Wagner
>>>>>> University of California San Diego
>>>>>> Electrical and Computer Engineering
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mark Wagner
>>>>> University of California San Diego
>>>>> Electrical and Computer Engineering
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://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/20190207/a32c4f65/attachment.html>


More information about the USRP-users mailing list