Rob, we pushed a fix for the TX spectrum issue to UHD-3.13 and master.
-- M On 08/15/2018 05:24 PM, Michael West wrote: > Hi Rob, > > We have reproduced the TX corruption issue and we are troubleshooting. > In the meantime, you can try using the head of UHD-3.13 with the > force_reinit=1 as Martin suggested. If that doesn't do the trick, we > did find a combination that seems to work: UHD and FPGA image from the > head of UHD-3.13 and MPM from the head of UHD-3.12. Let us know if > either of these helps you work around the issue. We will let you know > as soon as we have a fix. > > Regards, > Michael > > > On Wed, Aug 15, 2018 at 3:52 PM, Martin Braun via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > On 08/09/2018 02:31 PM, Rob Kossler via USRP-users wrote: > > When I first started using MPM 3.13, I was pleased to see the fast > > initialization times compared to previous versions. Now, after > spending > > the better part of a couple of days troubleshooting issues, I am much > > less thrilled with this version. > > > > The two attachments show the resulting spectrum from an external > Tx->Rx > > RF loopback experiment. The only difference between the two > figures is > > the change of MPM from 3.12 to 3.13. The baseband signal consists > of 100 > > equal amplitude tones equally spaced over 80% of the sampling freq > > (31.25e6, in my case). Note that the 3.12 results are as > expected. The > > 3.13 results show energy over the full bandwidth and significant > > variations in tone magnitude. I confirmed with a spectrum > analyzer that > > the trouble was on the Tx side rather than Rx. > > > > I also experienced issues with streaming timeouts occurring on the 2nd > > time I issued a streaming command. However, with all of the > variations > > I have been going through while troubleshooting this issue, I > cannot say > > for certain that this secondary issue is related to the MPM version. > > Presently, I am not seeing these streaming timeouts and I'm not > sure of > > the exact conditions that caused them. > > Rob, > > as Michael West already mentioned, we're checking out these issues and > trying to reproduce. In the meantime, you could try running with > force_reinit=1 as a device arg to force clean-slate initialization (the > way we improved the init time was by skipping certain steps). It'll make > your init times slow again, of course. > > -- M > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/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
