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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> 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 [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
