[USRP-users] N310 phase jumps with 1 daughterboard

Nate Temple nate.temple at ettus.com
Mon Jan 27 17:53:36 EST 2020


Hi Rob,

Thanks for trying your setup with 3.15.0.0.

I will see what I can do about getting these fixes backported to 3.14, any
changes will need to be on the UHD-3.14 branch (the maint branch for 3.14),
we won't be able to apply these changes to 3.14.1.1, as it's a tagged
release.

Regards,
Nate Temple

On Mon, Jan 27, 2020 at 2:46 PM Rob Kossler <rkossler at nd.edu> wrote:

> Nate,
> After switching to 3.15, I now get consistent results such that the
> relative phase between channels is as follows:
> - chan 0 to chan 1: constant
> - chan 1 to chan 2: constant +/- 180 deg
> - chan 2 to chan 3: constant
>
> So, it seems that the problem was in 3.14.
> Rob
>
> On Mon, Jan 27, 2020 at 3:45 PM Rob Kossler <rkossler at nd.edu> wrote:
>
>> Nate,
>> So, I retested with 3.14.1.1 and got erratic results (same as last
>> week).  Now I am attempting to go to 3.15.0.0.  To make things as painless
>> as possible, I tried to just re-build MPM on the device and then update the
>> other stuff on the host (rather than flashing a new file system).  However,
>> MPM doesn't seem to build (see error below). I'm guessing this error is
>> related to something in the file system that is going to force me to
>> re-flash the file system.  Can you take a look and let me know if there is
>> an easier way.
>> Rob
>>
>> root at ni-n3xx-318F043:~/build_mpm# make -j2
>> [  5%] Built target periphs
>> [ 10%] Built target dboards
>> [ 27%] Built target mykonos
>> [ 32%] Built target spi
>> [ 34%] Building C object lib/i2c/CMakeFiles/i2c.dir/i2cdev.c.o
>> Scanning dependencies of target types
>> [ 36%] Building CXX object lib/types/CMakeFiles/types.dir/lockable.cpp.o
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c: In function 'i2cdev_open':
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c:26:33: error: 'O_LARGEFILE'
>> undeclared (first use in this function); did you mean '__O_LARGEFILE'?
>>      *fd = open(device, O_RDWR | O_LARGEFILE);
>>                                  ^~~~~~~~~~~
>>                                  __O_LARGEFILE
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c:26:33: note: each undeclared
>> identifier is reported only once for each function it appears in
>> make[2]: *** [lib/i2c/CMakeFiles/i2c.dir/build.make:111:
>> lib/i2c/CMakeFiles/i2c.dir/i2cdev.c.o] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:466: lib/i2c/CMakeFiles/i2c.dir/all]
>> Error 2
>> make[1]: *** Waiting for unfinished jobs....
>> [ 38%] Building CXX object lib/types/CMakeFiles/types.dir/log_buf.cpp.o
>> [ 40%] Building CXX object
>> lib/types/CMakeFiles/types.dir/mmap_regs_iface.cpp.o
>> [ 40%] Built target types
>> make: *** [Makefile:141: all] Error 2
>> root at ni-n3xx-318F043:~/build_mpm#
>>
>>
>> On Mon, Jan 27, 2020 at 2:21 PM Rob Kossler <rkossler at nd.edu> wrote:
>>
>>> ok.
>>>
>>> Yes, I always use timed tune commands. If that were not happening
>>> correctly, I don't think I could get consistent results with TwinRx.
>>>
>>> I am presently using 3.14.1.1.  I will complete the testing (using
>>> internal LO) I've already begun with this version and then re-test some/all
>>> using 3.15.  Assuming that the results are different, it would seem that
>>> Ettus should consider applying the fixes to the 3.14 branch.
>>>
>>> Rob
>>>
>>>
>>> On Mon, Jan 27, 2020 at 2:18 PM Nate Temple <nate.temple at ettus.com>
>>> wrote:
>>>
>>>> Hi Rob,
>>>>
>>>> One other thing, if you're not on UHD v3.15.0.0, I'd recommend to
>>>> update to it. There was some phase reset and accumulator fixes with
>>>> 3.15.0.0.
>>>>
>>>> https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/CHANGELOG#L44
>>>>
>>>>
>>>> Regards,
>>>> Nate Temple
>>>>
>>>> On Mon, Jan 27, 2020 at 11:17 AM Nate Temple <nate.temple at ettus.com>
>>>> wrote:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>> You should always use a tune request with a timed command when you
>>>>> want to align channels.
>>>>>
>>>>> One thing you could test is to try using the internal LO and see if
>>>>> you get different results.
>>>>>
>>>>> Also you could try using the integer N tuning mode, but I don't think
>>>>> it will make any difference for this issue. Checkout this great blog post
>>>>> on USRP tuning if you haven't seen it before that covers a few more tips on
>>>>> USRP tuning:
>>>>> http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html
>>>>>
>>>>> Regards,
>>>>> Nate Temple
>>>>>
>>>>> On Mon, Jan 27, 2020 at 9:33 AM Rob Kossler <rkossler at nd.edu> wrote:
>>>>>
>>>>>> Hi Nate,
>>>>>> I changed the subject as to not further hijack the other thread. Of
>>>>>> the 16 captures I collected, some of them included a tuning command (but
>>>>>> using the same timed commands I use for other devices such as TwinRx). But,
>>>>>> others did not.  For example, for the first two data points below (with
>>>>>> measured phase difference of -77 and -19 respectively).  I simply issued
>>>>>> two consecutive timed streaming commands.  So, I was very perplexed by the
>>>>>> results.
>>>>>>
>>>>>> In any event, I plan to re-take the data today both with and without
>>>>>> a DDC.  Hopefully, if I get rid of the DDC, I will see consistent phase
>>>>>> results, but we'll see.  Let me know if you have other ideas.
>>>>>> Rob
>>>>>>
>>>>>> On Mon, Jan 27, 2020 at 12:04 PM Nate Temple <nate.temple at ettus.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> @Rob: With the current init process of the N310, yes it is required
>>>>>>> to first set the external LO to 5 GHz.
>>>>>>>
>>>>>>> With regards to the offsets you're seeing, I believe you should only
>>>>>>> see a possible phase difference of 180* within the two channels on the same
>>>>>>> DB. Are you issuing a tune request at the start of streaming?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nate Temple
>>>>>>>
>>>>>>> On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
>>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>>
>>>>>>>> Robert, Sammy,
>>>>>>>> I am presently running some tests which compare the X310/TwinRx and
>>>>>>>> the N310 with regard to channel-to-channel phase.  In my setup, I have a
>>>>>>>> signal source that is split 8 ways (1:8 splitter) to feed the 4 channels of
>>>>>>>> my TwinRx and 4 channels of my N310. I have seen some strange behavior of
>>>>>>>> the N310 that perhaps Robert has experienced?  Take a look:
>>>>>>>>
>>>>>>>>    - For the TwinRx (for which I am a more experienced user with
>>>>>>>>    LO sharing), I get consistent channel-to-channel phase difference among all
>>>>>>>>    channels. This is true regardless of power cycles, re-starts of UHD, etc.
>>>>>>>>    - For the N310 (for which I am a beginner when it comes to
>>>>>>>>    external LO operation)
>>>>>>>>       - it seems more complex to run in this mode (as compared to
>>>>>>>>       TwinRx).  In order to get it to work, I have had to disable startup QEC
>>>>>>>>       calibration because it seems that the N310 initial cal occurs at 2500 MHz
>>>>>>>>       RF such that I would need to have my external LO at 5000 MHz for startup
>>>>>>>>       (during the UHD deveice 'make') and then later switch my external LO to the
>>>>>>>>       desired RF*2. Is this true?
>>>>>>>>       - when I run with either external LO or internal LO, I see
>>>>>>>>       inconsistent channel-to-channel phase results even between the two channels
>>>>>>>>       of a given daughterboard that share the same LO.  I do not understand how
>>>>>>>>       this is possible.  My results over 16 captures (with some re-starts of UHD,
>>>>>>>>       device reboots, and switching between internal/external LO) show the
>>>>>>>>       following channel-to-channel phase difference between channels 0 and 1
>>>>>>>>       which share the same LO: (values in degrees) -77, -19, -77, -19, -77, -19,
>>>>>>>>       -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are only 3
>>>>>>>>       unique values and the delta happens to be 58 deg, but I don't know what
>>>>>>>>       that implies...
>>>>>>>>
>>>>>>>> Rob
>>>>>>>>
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200127/c3404184/attachment.html>


More information about the USRP-users mailing list