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
