Thanks Michael, Are you saying that when running with STREAM_MODE_START_CONTINUOUS, I can expect a "md.end_of_burst==true" shortly after issuing the STREAM_MODE_STOP_CONTINUOUS? If so, that seems like a much better method for flushing all of the samples following the stop command.
In any event, I have no problem switching over to use STREAM_MODE_NUM_SAMPS_AND_DONE. My issue with one or two overruns was several years ago and I believe it was specific to the B210 (and I don't think that increasing start delays helped at that point, but I could be wrong). And in general, I want to decrease rather than increase start delays because my application runs in a fast-as-you-can capture/process/display loop. So, the more I increase the start delay, the slower my loop. Rob On Thu, Aug 23, 2018 at 7:37 PM Michael West <michael.w...@ettus.com> wrote: > 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
