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
