[USRP-users] N310 phase jumps with 1 daughterboard

Rob Kossler rkossler at nd.edu
Mon Jan 27 17:46:23 EST 2020


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/01bf6a74/attachment.html>


More information about the USRP-users mailing list