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 <rkoss...@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 <rkoss...@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@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
