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@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@ni-n3xx-318F043:~/build_mpm#
On Mon, Jan 27, 2020 at 2:21 PM Rob Kossler <rkoss...@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.tem...@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.tem...@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 <rkoss...@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.tem...@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@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
>>>>>>
>>>>>>
>>>>>>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
