Hi Rob, Excellent feedback as always. Thank you. We will look into the RX burst behavior using STREAM_MODE_START_CONTINUOUS, but it may take some time. The flush routine should have a timeout for the recv() call and be looking for md.end_of_burst to exit, but I'm sure there is more to the issue than that. BTW, to avoid the overruns at startup, just set a start time a little in the future and minimize the amount of code between the issue_stream_cmd() call and the first recv() call.
Regards, Michael On Thu, Aug 23, 2018 at 11:37 AM, Rob Kossler <rkoss...@nd.edu> wrote: > Martin, Michael, > Sorry for the long delay in responding. I hadn't been monitoring the > user's list this past week and the replies you sent did not come directly > to my inbox. In any event, I compiled the latest MPM and it seems to work > fine. Thank you. > > Now, to the secondary issue I mentioned in the first post of this thread: > rx streaming timeouts. These timeouts intermittently occur in my > application when doing repeated rx captures (i.e., error never occurs on > first capture). I tracked it down today to my application's use of > STREAM_MODE_START_CONTINUOUS rather than STREAM_MODE_NUM_SAMPS_AND_DONE for > the capture. After changing my code to use the latter, it works well with > no timeouts. > > A couple of remarks: > > - I don't know if this is of concern to you or not. Perhaps I should > be using it the new way anyway. A long time ago I had made the decision to > use STREAM_MODE_START_CONTINUOUS because I was getting one or two overflows > right at the start of the capture (B210) and I didn't want the capture to > abort as it did if I used STREAM_MODE_NUM_SAMPS_AND_DONE. > - With other products (B210 & X310), I have been using my application > and STREAM_MODE_START_CONTINUOUS for several years, successfully. (That > said, I do want to mention that I have had occasional issues ever since > Ettus moved away from 3.9 such that I still use 3.9 when I am able to do > so. Perhaps this stream mode change would have fixed such occasional > issues???) > - If you are interested in this issue, I modified the Ettus example > "txrx_loopback_to_file" to add a 'for loop' around the receive captures and > changed the stream mode to always be STREAM_MODE_START_CONTINUOUS. The > changes I made are few and straightforward. If you run compile this > modified example and run with the command line shown in the terminal log > (see attached), you should be able to duplicate this issue. > > Rob > > > On Thu, Aug 16, 2018 at 4:05 PM Martin Braun via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> 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 >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
