Sure, I understand the comment about the tagged release. And, I don't have a compelling reason why I can't switch from 3.14 to 3.15. I have not switched yet only because I'm being cautious and 3.14 has worked well for me. But, I will plan to switch - at least for now. Rob
On Mon, Jan 27, 2020 at 5:51 PM Nate Temple <nate.tem...@ettus.com> wrote: > 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
