Re: [USRP-users] Problems with MPM 3.13 on N310

[Michael West via USRP-users]

Hi Rob,

Thanks for the update.  We will look into it.

Regards,
Michael

On Fri, Aug 24, 2018 at 10:09 AM, Rob Kossler  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  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 
>> 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  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:

Re: [USRP-users] Problems with MPM 3.13 on N310

[Rob Kossler via USRP-users]

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  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 
> 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  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 

Re: [USRP-users] Problems with MPM 3.13 on N310

[Rob Kossler via USRP-users]

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  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  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
>>> > 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 

Re: [USRP-users] Problems with MPM 3.13 on N310

[Michael West via USRP-users]

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  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
>> > 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 

Re: [USRP-users] Problems with MPM 3.13 on N310

[Rob Kossler via USRP-users]

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
> > 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 
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > 

Re: [USRP-users] Problems with MPM 3.13 on N310

[Martin Braun via USRP-users]

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
> 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 
> 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

Re: [USRP-users] Problems with MPM 3.13 on N310

[Michael West via USRP-users]

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> 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
> 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

Re: [USRP-users] Problems with MPM 3.13 on N310

[Martin Braun via USRP-users]

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
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problems with MPM 3.13 on N310

[Sayyed Dormiani Tabatabaei via USRP-users]

I can't comment on the MPM or images but we had N310 streaming timeout
issues that were recently fixed.

Upgrading from UHD 13 to 13.0.0.1 fixed all our (seemingly randomly
occurring) streaming issues.

On Thu, Aug 9, 2018 at 2:31 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> 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
>
>
> ___
> 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