Hi Rob,
Thanks for the update. We will look into it.
Regards,
Michael
On Fri, Aug 24, 2018 at 10:09 AM, Rob Kossler <rkoss...@nd.edu> wrote:
> By the way, I just changed my "flush" sequence to use the end_of_burst
> flag (when streaming with STREAM_MODE_START_CONTINUOUS), but the issue
> still occurs. Attached are the modified source code and the resulting
> console log. The new flush sequence is shown below. Again, this is not an
> issue for me now since I changed to using STREAM_MODE_NUM_SAMPS_AND_DONE,
> but wanted to pass this along.
>
> // Shut down receiver
> stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
> rx_stream->issue_stream_cmd(stream_cmd);
> std::cout << "; Num samples received: " << num_total_samps << std::endl;
>
> while (not md.end_of_burst and md.error_code != uhd::rx_metadata_t::ERROR_
> CODE_TIMEOUT)
> {
> size_t n = rx_stream->recv(buff_ptrs, samps_per_buff, md, timeout);
> std::cout << " flush samples received: " << n << std::endl;
> } // Flush buffers
>
>
> On Thu, Aug 23, 2018 at 8:00 PM Rob Kossler <rkoss...@nd.edu> wrote:
>
>> 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
