Hello Michael, Sorry for the long delay of my answer: I just want to confirm that the reported issues are fixed with the N310 and UHD 3.13.1.0.
Thanks! Serge On Fri, 4 Jan 2019 at 16:00, Michael West <michael.w...@ettus.com> wrote: > Hi Serge, > > I have tried to reproduce the issue on an N310 and X310 with no success. > I tried several versions of UHD (including v3.13.1.0-rc1) on both and the > time alignment was always good and the benchmark_rate with the increased > INIT_DEALY always worked as expected. Can you try with the head of the > UHD-3.13 branch and see if you still see the same issues? If so, please > provide the modified tx_timed_samples example you are using along with the > command being issued. A picture of what you are seeing on the scope would > also be helpful. > > Regards, > Michael > > On Mon, Nov 12, 2018 at 9:54 PM Michael West <michael.w...@ettus.com> > wrote: > >> Hi Serge, >> >> Thank you for making us aware of the issues. We are looking into them >> and consider them a priority. We will let you know what we find. >> >> Regards, >> Michael >> >> On Fri, Nov 9, 2018 at 11:04 AM Serge Malo via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hi all, >>> >>> I have made another test today, I want to report the results here. >>> >>> *Issue #1* >>> I have modified the tx_timed_samples example, simply such that it >>> transmits on both channels of the X300. >>> Using a frequency of 1.57542GHz for both channels, I was able to measure >>> on a scope a time offset of 320ns between RF A and RF B. >>> Technically, Ettus R&D should be able to reproduce this offset easily. >>> >>> *Issue #2:* >>> Yesterday, I wrote that "timed commands" seemed to be broken with UHD >>> 3.13.1.0 RC1. Here are more details: >>> "timed samples" do work correctly with the UHD example tx_timed_samples. >>> However, "timed samples" do not work with the UHD example benchmark_rate. >>> You can reproduce the problem this way, on a X300, connected to an >>> Octoclock: >>> 1) Change the value of INIT_DELAY to 5.0s >>> 2) Recompile benchmark_rate, and try this command: >>> ./benchmark_rate --args addr=192.168.40.2 --tx_rate=25000000 >>> --tx_cpu=sc16 --ref=external --pps=external --channels=0,1 >>> >>> You will see that the TX starts immediately, instead of at time 5.0s. >>> >>> Please, let us know if you aware of those issues, and if you need help >>> to reproduce or investigate them. >>> >>> Best regards, >>> Serge >>> >>> >>> On Thu, 8 Nov 2018 at 23:59, Marcus D. Leech via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> On 11/08/2018 03:13 PM, Serge Malo via USRP-users wrote: >>>> >>>> Hi all, >>>> >>>> Thanks for the extra comments Mark. >>>> >>>> Just to be clear: I'm not talking about phase offset between RF >>>> Outputs, but only time offset. >>>> (Once time offset is fixed, we will try to have phase-coherent RF >>>> outputs). >>>> >>>> I have made other measurements today, here are the results. >>>> I'm transmitting a signal at 1.57542GHz, and a second signal at >>>> 1.2276GHz. >>>> Sample Rate on N310: 25.6Msps (MCR of 153.6Mhz) >>>> Sample Rate on X300: 25.0Msps (MCR of 200Mhz) >>>> Using External Clock and External PPS from Octoclock >>>> 1) Using X300 (RF A and RF B) and UHD 3.10.3.0, we see les than 3ns >>>> time offset (See image here: link >>>> <https://drive.google.com/file/d/1FBC3CHOhGO4xLdJU3LhjB0pTjexNpJik/view?usp=sharing> >>>> ) >>>> 2) Using X300 (RF A and RF B) and UHD 3.13.1.0 RC1, we see 7300us time >>>> offset (See image here: link >>>> <https://drive.google.com/file/d/1mV2XrUVz1PC4boi0BzUmxFcWo2b8zj3Y/view?usp=sharing> >>>> ) >>>> 3) Using N310 (RF 0 and RF 2) and UHD 3.13.1.0 RC1, we also see 7300us >>>> time offset. >>>> >>>> Important: the "timed commands" seem to be broken in UHD 3.13.1.0, >>>> either for X300 or N310. >>>> When we change the time_spec of the first "send" call, the time at >>>> which the samples are transmitted does not change. For example, I tried to >>>> set tie_spec to 10s, but the Tx starts right away. This was working >>>> correctly with UHD 3.10.3.0 >>>> >>>> Let me know if you have ideas I could try. >>>> >>>> Best regards, >>>> Serge >>>> >>>> Serge: >>>> >>>> The fact that this affects both X310 and N310 is a bit disturbing--the >>>> device-side codebase is quite different on the two boxes. I'm engaging >>>> Ettus R&D internally to see if this can be reproduced. >>>> >>>> >>>> >>>> >>>> On Thu, 8 Nov 2018 at 14:44, Mark Wagner <m2wag...@eng.ucsd.edu> wrote: >>>> >>>>> Here's a google drive link with images of the phase drift between rx4 >>>>> and tx 1&2, and tx 3&4 >>>>> >>>>> https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH >>>>> >>>>> On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner <m2wag...@eng.ucsd.edu> >>>>> wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> Maybe I could jump in and share some related results. My group has >>>>>> been developing a MIMO system with N310 units. We did a test sounding >>>>>> recently where we sent 4, length 4096, orthogonal multitone signals from >>>>>> the transmitters to the receivers and processed the data by finding the >>>>>> channel response between each transmitter and receiver pair (16 in total) >>>>>> and recording the magnitude and phase of the arrival spikes between each >>>>>> pair. >>>>>> >>>>>> We took several seconds of data and processed it in length 4096 >>>>>> chunks (around 1500 chunks in total) and looked at the phase difference >>>>>> between transmitter pairs as time progressed. Since transmitters 1 and 2 >>>>>> are sharing an LO and our setup was not moved during the sounding we >>>>>> expected to see a constant phase difference between transmitters 1 and 2 >>>>>> and a single receiver (same with tx 3 and 4), but we saw some drift. >>>>>> Worse >>>>>> yet, not all LO sharing pairs drifted in the same way, some didn't drift >>>>>> much at all while some drifted in linear or non-linear patterns. >>>>>> >>>>>> If you're all fine with me breaking the rules I can attach some png >>>>>> images of what we recorded so you can see what it looks like. Later this >>>>>> week we'll repeat the experiment but leave the machines running longer to >>>>>> see if the drift diminishes as the machines run longer. >>>>>> >>>>>> Cheers, >>>>>> -Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>>> Hi Serge, >>>>>>> >>>>>>> Are you measuring the phase offset between the TX0 and TX2 signals >>>>>>> in a steady-state case, or the time difference in the start of those >>>>>>> signals? >>>>>>> >>>>>>> In the former case, your results could be impacted by the lack of >>>>>>> internal LO sharing between daughterboards. I would fully expect an >>>>>>> unknown >>>>>>> phase offset between channels 0 and 2 every time you reconfigure the >>>>>>> device. In the latter case, it sounds like a start trigger mismatch like >>>>>>> Marcus mentioned. >>>>>>> >>>>>>> Can you share more details as to how you're measuring the phase >>>>>>> offset? >>>>>>> >>>>>>> Thanks, >>>>>>> -Daniel >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users < >>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>> >>>>>>>> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system >>>>>>>> image >>>>>>>> >>>>>>>> I can try to use lower tx start times to see if the time offset >>>>>>>> changes with that. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serge >>>>>>>> >>>>>>>> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech < >>>>>>>> patchvonbr...@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 11/07/2018 09:31 PM, Serge Malo wrote: >>>>>>>>> >>>>>>>>> Yes: >>>>>>>>> We only use one streamer for all RF outputs, and send time_spec >>>>>>>>> with each call to the streamer's send method. >>>>>>>>> We reset the internal time with set_time_unkown_pps(0), and >>>>>>>>> program the first samples to be streamed at a time of 0.800s. >>>>>>>>> It is basically the same code we used on the X300/X310. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serge >>>>>>>>> >>>>>>>>> Well, that is quite strange--the magnitude of the time offsets is >>>>>>>>> larger than I would expect. >>>>>>>>> >>>>>>>>> Perhaps someone from the N310 team can comment? >>>>>>>>> >>>>>>>>> Serge, are you using the latest UHD and system image versions for >>>>>>>>> the N310? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users < >>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>> >>>>>>>>>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> We are trying to send 4 synchronous signals from the 4 Tx ports >>>>>>>>>> of the N310. >>>>>>>>>> We are using UHD 3.13.1.0 RC1 under Ubuntu. >>>>>>>>>> Central Freq = 1575.42 GHz and 1227.6 MHz >>>>>>>>>> Master Clock rate = 153.6 MHz >>>>>>>>>> >>>>>>>>>> We would expect to have less than 3ns offset between all TX ports >>>>>>>>>> of the N310, like we do with the X300/X310. However, we have measured >>>>>>>>>> 4700ns between TX RF ports 0 and port 2. >>>>>>>>>> We have tried the next things with no more success: >>>>>>>>>> - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps >>>>>>>>>> - Init with the device options "init_cals=ALL" and >>>>>>>>>> "force_reinit=1" >>>>>>>>>> - Use the internal GPSDO >>>>>>>>>> - Use clock_source=external and time_source=external (from an >>>>>>>>>> Octoclock). >>>>>>>>>> >>>>>>>>>> Can you tell us: >>>>>>>>>> -What time offset between TX RF ports we should expect to achieve? >>>>>>>>>> -Is there anything else we can try to reduce this offset to less >>>>>>>>>> than 3ns? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Serge >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> How are you setting up your TX streamer? Is it time-tagged to >>>>>>>>>> start at a particular device time? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> USRP-users mailing list >>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> USRP-users mailing list >>>>>>>> USRP-users@lists.ettus.com >>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Daniel Jepson >>>>>>> >>>>>>> Digital Hardware Engineer >>>>>>> >>>>>>> National Instruments >>>>>>> >>>>>>> >>>>>>> >>>>>>> O: +1.512.683.6163 >>>>>>> >>>>>>> daniel.jep...@ni.com >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list >>>>>>> USRP-users@lists.ettus.com >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mark Wagner >>>>>> University of California San Diego >>>>>> Electrical and Computer Engineering >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mark Wagner >>>>> University of California San Diego >>>>> Electrical and Computer Engineering >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing >>>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
